As many do , I ran into the problem of the softinput covering my send buttons so I did some searching and found the accepted way of fixing this issue is "android:windowSoftInputMode="stateAlwaysHidden|adjustPan"
and this works great on my device, but when I try it on my girlfriends phone it doesnt work. I see the dialog lift a little before the input shows up on screen , but not much and the send button is still covered. Why would this work on some devices , but not all?
Messing with the onscreen keyboard is difficult at best because on the one hand:
It's supposed to be where it is, that way users expect it, it's consistent, very important in UI design
BUT
It can get in the way.
The solution (based on the Android design guidelines, experience and feedback and so forth) is not to faff with it too much, you can have basically the following kinds of behavior:
*Pops up when activity starts (which happens if the activity has an input)
*Doesn't pop up when activity starts (despite the first input having focus <-- good) but will when the user taps.
It's good to dismiss the keyboard when the user is done, that is have the "enter button" take them to the next entry, if there's none left, hide it, if it's some sort of data capture form that validate as they go along, if not don't do this because they might press back in an attempt to get it up.
Addendum I
"adjustResize"
The activity's main window is always resized to make room for the soft keyboard on screen.
"adjustPan"
The activity's main window is not resized to make room for the soft keyboard. Rather, the contents of the window are automatically panned so that the current focus is never obscured by the keyboard and users can always see what they are typing. This is generally less desirable than resizing, because the user may need to close the soft keyboard to get at and interact with obscured parts of the window.
From the documentation here: http://developer.android.com/guide/topics/manifest/activity-element.html
Difference between adjustResize and adjustPan in android?
See there for more.
It's difficult to pan correctly because the layout of the activity can be many things, it could scroll to the left, it could all be relative, it's not one strip where it need only jump up and down, some things also have more than one solution, more than one way to pan so it is visible. You haven't really described what doesn't work btw. I'm trying to explain the issues of what I think you want.
Does this help?
Suddenly got here. You shouldn't mix several values inside android:windowSoftInputMode="" attribute. So, you can preserve android:windowSoftInputMode="adjustPan" and hide a keyboard with hideKeyboard() (look for this method in the Net). Probably you can add listeners to hide it everywhere inside the activity.
Related
I tried my app in Android O and came up with a strange issue. I have a RecipientEditTextView which extends the AutoCompeteTextView, and after mismatch happens, the focus is still on the textview and cursor still flashing, however, the bottom buttons are pushed down and soft keyboard is still shown, when you try to type the soft keyboard, you just interact with the components beneath the keyboard. Since the code is quite complex I really cannot post code here. So my question is when can a soft keyboard be shown while cannot be typed.
This is a long standing bug. Keyboards are bound to views. You can get into a situation where the keyboard is bound to the wrong view. In that case, the typing will go to the view its bound to, and not to the one you expect. This is especially likely after a crash, you may see DeadObjectExceptions in the log.
I have a problem with the animation of the soft-keyboard since ICS. I got an activity for data entry using the soft-keyboard. The window is set to "adjustResize" in order to fit all Views into the screen above the soft-keyboard.
Since Android 4 the fancy animation of opening the keyboard, let's the views on my screen "bounce".
It seems, as if the view is layouted, then the keyboard opens and after this the screen is relayouted, leading to kind of a jumpy UX.
There was a similar question:
( How to show/hide the soft keyboard without any animation (e.g. fade) in Java? )
However, the solution over there does not work for me. (tested on 4.2.1)
I would be glad, if anyone has some clues on achieving one of the following solutions:
Disable the animation of the soft-keyboard for an activity
Retrieve the size of the soft-keyboard in order to set the size of the screen manually
Cheers,
Florian
You can't get the height of soft-keyboard. I don't think there is a need to do so, you can achieve the same use-case by trying different approach.
If you don't want to re-layout screen, you can use android:windowSoftInputMode attribute in-order to have some more control over the screen rendering when soft-keyboard appears.
For Example : If you don't want to resize the view, you can put the following line in manifest file. This will simply display the keyboard on top of the activity.
<activity android:windowSoftInputMode="adjustPan">
You can check other options for desired functionality.
For better understanding and more controls, you can refer this tutorial.
Hope, this will give you some hint about implementing your use-case.
First of all, I am aware of about 1000 other questions regarding the android keyboard... I am aware I can manually hide keyboard from window or control, and pass in any number of flags that are supposed to control where and when keyboard pops up.
Basically, I aim to have PREDICTABLE keyboard handling in my app... that is that unless explicitly told to focus this control, and popup keyboard, it'll only pop up when a user taps a text edit.
This app is extensive, and manually attempting to hide keyboard from even just the focused control (vs explicitly hiding each and every edit field).
I am also aware I can avoid the popup up keyboard when you dont want it there, by setting focus on a non text editable field, however, that seems like more of a hack than anything else.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide? If I want this text field to et focus on new dialog, I'll manually handle those cases. In addition, any way to automatically handle keyboard dissapear when the previously focused control dissapears?
I just dont get logic there... if I step back and think about this, I'd only want keyboard popping up if I wanted to go type something. As far as keyboard popping up immediately when new dialog opens... seems like the exceptional case (there may be a couple times I'd want to do that).
I dont mind building a manager or something that keeps track of the state of keyboard, however i dont know if I can get at the information I'd need to make it work in a remotely intuitive manner, efficiently.
Any pointers or ideas would be greatly appreciated... because I am at my whits end with this... and I can assure you I've spent a good deal of time researching this and attempting fixes.
Note: Sorry about the title or hostility... I've fought this for quite some time, and been generally infuriated with how bizarre dealing with the keyboard can be.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide?
No.
But you can use:
this.getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN);
On each activity.
Ok, I think I get what you're asking. Have a look at the second answer here:
Stop EditText from gaining focus at Activity startup
You can specify in your AndroidManifest.xml whether or not the softkeyboard should be hidden by adding this android:windowSoftInputMode="stateHidden" to the beginning of your activities tag (<activity>)
I have an app that runs fullscreen by using:
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN);
Because of this the layout, android:windowSoftInputMode="adjustResize" is not working properly, i.e. it dose not resize.
Is there any way to get over the problem?
FYI: This is an existing AOSP (Android Open Source Project) bug: http://code.google.com/p/android/issues/detail?id=5497
Ideally this bug would be fixed, but until then here are a couple thoughts of how it could be worked around. Since I have no idea what application scenario this pertains to, these may not be very applicable.
In agreement with my best interpretation of the previous answer, design your layout so that adjustPan works ok with it. The first thing I can think of here is not having any headers or footers that are intended to remain on screen when the keyboard is up.
Don't use FLAG_FULLSCREEN with a layout that can accept text input. Possibly it wouldn't be a big deal to show the status bar when accepting input. However, for something that views content with embedded input fields (like a web browser) that has a fullscreen mode, this doesn't make much sense at all.
Implement adjustResize-like behavior of your own. I'm not sure how well this would work, but possibly you could write a subclass of whichever class is causing the keyboard to be shown (ex: EditText) where you either track when the keyboard is shown or take over the calls to show and hide the keyboard (overriding at least onKeyUp and onTouchEvent). When shown, resize your content - possibly with a best guess of the softinput height, since users can install different soft input methods. I believe this would be technically difficult and not reasonable to attempt without extreme need.
Instead of android:windowSoftInputMode="adjustResize" you can try with android:windowSoftInputMode="adjustPan"
I want to develop a replacement keyboard, but I am afraid that Android assumes the general keyboard 'area' will be a single rectangular shape that sits at the bottom of the screen.
What if I want my keyboard to consist of multiple shapes that don't just sit at the bottom of the screen? Am I doomed from the start, or is it possible to do what I want to do?
On a related note, what if I only want my keyboard to appear when the phone is in a certain orientation but when the phone is held at a different orientation, the normal soft keyboard is used? Again, out of luck or possible?
cheers!
The IME is just a window. It is positioned relative to the bottom of the screen, so you can't really control that. But you can draw whatever you want in it, or not for places you want to be transparent. You can control how much applications move up away from your IME with this: http://developer.android.com/reference/android/inputmethodservice/InputMethodService.html#onComputeInsets(android.inputmethodservice.InputMethodService.Insets)
Android doesn't let windows decide one at a time whether events will be handled by them or dispatched to the window behind them; the only control you have to keep events from being consumed by your entire window is the Insets.touchableInsets constants to tell the window manager to allow events outside of the given insets to go through to what is behind it.
Presumably you could create a rectangle where ever you want and make bits of it transparent. Not sure how to pass UI events to the activity below your keyboard though.
Anyway, there's a softkeyboard sample that will probably be Quite Helpful.
As I see it there are two ways you might handle the UI Thing.
- Pass events off to the underlying activity when they "should go through"... As your softkeyboard may have its own process, this could get a bit thorny.
- Make your keyboard up of more than one rectangular region, such that the UI events pass through Naturally. I'm not sure if that's even possible. I'm still fairly new to Android development myself.