When the software keyboard shows, it resizes my layout and thus squeezes the background image together. My question is basically a duplicate of this question, which is explained in a very good way:
Software keyboard resizes background image on Android
However, that question was closed when they found a hack to solve it. I cannot use this hack. My entire layout is inside a ScrollView, and I need to be able to use this scrollview properly at all times. By using android:windowSoftInputMode="stateVisible|adjustPan" the user will not be able to scroll down and see the bottom of the screen while the keyboard is showing, since the layout will partly exist behind the keyboard. Thus the solution is unacceptable to me. Are there any better solutions out there?
Cheers,
I actually ran into a similar problem not too long ago. I stumbled upon the correct answer with a bit of work, though.
In your android manifest for this project, attached to the specific activity that you are using, use the line
android:windowSoftInputMode="adjustPan|stateVisible"
in the activity tag.adjustPan
basically means that your activity will not resize itself to fit the soft keyboard, and stateVisible means that the soft keyboard will show when requested (this can bestateAlwaysVisible
, etc if necessary)source : Android Dev for Activity tags
After a lot of time searching...
Put
android:windowSoftInputMode="adjustPan|stateVisible"
in each ActivitysI was googling for a solution to this exact problem when I came across this, and after doing some research I found a solution I think is slightly better. Instead of hacking with a ImageView you can use this from your activity:
Hope it helps anyone else searching for a solution for this.
After days of hardcore hacking I finally managed to construct a solution so advanced it might actually hurt to read it. I place an ImageView with the background behind the scrollview, and set scaleType="matrix" so it does not shrink when the keyboard is shown.
How about a solution where the 'background' is a Layout. Can we inflate a layout, make it the entire window size, then insert it as a window background?
I can't comment on your answer but I'd like to add something.
I understand your dilemma and why the solution you linked to isn't a complete solution for your situation (since you can't scroll to the bottom of the view). I have a similar situation with a large scrollable EditText box. When the soft keyboard pops up I don't like my background getting squished.
I have tried your solution and while at first glance it appears to work, there are some situations where it might not be ideal:
Basically it seems that when you set the
scaleType
tomatrix
you're telling Android to draw the background 1:1 and not to scale. So what's happening when you open the soft keyboard using your solution is, yourscrollView
andimageView
are all getting resized as usual, but the image src you set remains 1:1 thus continues showing the same area.So if for example your background image was set to a specific size (e.g. 480 x 800) and it perfectly fills your Nexus One, the moment you rotate to landscape you will have a black area along the right.
This is moot, of course, if your background is simply a repeating pattern, in which case you can make it extremely large and hopefully compensate for various screens (maybe even tablets).
Or you can also supply different backgrounds for different screen sizes/densities/orientations, but this still doesn't account for scaling.
In a vain effort to try and solve this, I stumbled upon a
View
attribute calledandroid:isScrollContainer
. This attribute tells certain views whether or not they are allowed to resize upon display of the soft keyboard. This is also mentioned by someone in your linked solution. I have tried setting this (to false) on theViewGroup
containing my background, but any child element that scrolls seems override it causing the squishing again.As of right now I don't think there is a complete solution for our situation. Your's definitely works in some instances and I thank you for the effort. Hopefully Google will offer a solution in the future, but I don't think they would consider this a problem/priority.