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.
Related
One screen of my Android Compose app contains TextField and the users need that cursor is placed inside this TextField when the screen is shown. And I am seeking the solution that avoids the meddling with the cursors and FocusRequester.
There are questions and answers about the similar situation e.g. Android Compose Jetpack Autofocus on TextField when screen open or programmatically on application requirement and Programmatically click textfield in jetpack compose but the solutions always involve FocusRequesters.
My experience is that the default focus system of Android Compose is pretty good and pretty constrained and that one should not meddle with it. https://medium.com/google-developer-experts/focus-in-jetpack-compose-6584252257fe also suggests not to meddle with:
Even more inadvisably, you can opt to manage focus all by yourself!
This can be a bad idea if you’re not careful enough, as it’s easy to
miss subtleties in how focus traversal is expected to work. If you are
careful enough, you end up re-implementing focus traversal logic
without using focus internals — not fun.
When I am trying to implement the auto-click with the FocusRequester I am experiencing very strange things - once the TextField has requested the focus, it tries to keep indefinitely. E.g. when the component requested the focus and the user clicks outside the TextField, the TextField still shows flickering cursors and opened IME software keyboard and then I am pressed to hack the focus behavior, to put another component to request focus and so on. I.e. when I have started to manage the focus manually then I am pressed to keep going with the manual management and step outside the standard and default behavior.
Actually, the default behavior ir pretty simple - if the user clicks outside the TextField, then the TextField looses everything - cursor, focus and keyboard. This is the right behavior, but once the TextField has requested the focus (with FocuseRequester), then the TextField tries to keep the focus indefinitely, even when users clicks outside the TextField.
So - my question is - how to just simply click inside the TextField programmatically and let the Androdi Compose take care about the focus management itself and automatically? That is I am seeking the solution without manual management of the Focus.
My understanding is that clicking inside the TextField comes before focus as the clicking initiates the whole bunch of things - focus, IME keyboard, maybe the scroll of the page and maybe some rearrangement of the components and space due to IME keyboard.
One suggestion is to use the combination/pair of focusRequster.requestFocus() and focusRequester.freeFocus(), but this is not good either - freeFocus() can remove the greed of the TextField for the keeping the focus indefinitely (that is good and that is part of the solution indeed), but freeFocus() does just that - removes the greed/affinity, but it still requires some other actions that remove the actual focus and that close the IME keyboard.
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.
I have a ListView with EditText views incorporated into the list item views. When the IME pops up it causes the ListView to resize (calling layout()). In the course of the ListView.layout() function running its course, it temporarily removes focus from the selected EditText, and then restores focus to the previously selected EditText.
This much is ok, but when I'm using an IME that includes a predictive text component, the IME will change size again (to add room for the predictive text bar). This causes the EditText to be defocused...which seems to cause the IME to close the predictive text bar...which causes the layout to be repeated again. Once the layout completes and the EditText is focused again, the IME sees the active text and re-asserts the predictive text bar, causing it to resize again, causing the ListView to do another layout pass, causing the EditText to lose focus again, causing the IME to close its predictive text bar and resize, ad infinitem.
There is a timing component to this, and it varies depending on which IME I'm using, but I've seen it with several different IMEs on several different generations of devices (2.2, 2.3, 4.0, 4.1, phones and tablets). Sometimes the problem will cycle a few times and work itself out. Other times it will continue in perpetuity.
Does anyone have a work-around for this?
(I regard it as a bug in ListView and/or the IME architecture, but I obviously have to find a solution other than fixing either of those.)
I've tried switching my soft input mode from adjustResize to viewPan, but that runs into a different (but similar) problem.
(When the choreographer first pans the view it moves the ListView (and associated EditText) a little but not enough. This causes the EditText to lose focus (by the mechanism described above). When it regains focus the choreographer does not re-attempt to bring it into view--it just leaves it hidden behind the IME. I've seen this bug discussed in other SO postings.)
By far the best way to handle layout issues involving an input method is to use adjustResize along with a subclassed top-level view with a custom implementation of fitSystemWindows(..). Instead of relying on any default code for resizing or panning, your implementation of fitSystemWindows(..) can do whatever makes sense for you, and then return true to suppress the default handling.
I have an Android app using PhoneGap 1.6 and Sencha Touch 1.1.1. One view has a text input field which behaves oddly in Android: it duplicates itself and it is very difficult to remove focus.
I have determined that it is a WebTextView coming up over top of the "real" input field. The problem I am having with this is that blurring the text field with screen taps is extremely difficult, and if you scroll the parent container, the WebTextView does not scroll with it, so you can see both at the same time.
The only way to remove focus on the element is to tap furiously all over parts of the screen, much like triggering the frustration detector from Mavis Beacon.
My actual question is: how can I turn off this functionality completely, or at least work around it? It is not reasonable to expect the user to do anything other than single-tap outside of the box, or press the Back button on the device to stop input in the text field. As it is, pressing Back simply stows the soft keyboard and does not give up focus.
These are browser bugs, triggered by some CSS-flags.
To explain the bug:
The device creates some kind of "screenshot" from the web-sites content. All transformations and transitions are made on top of the "screenshots" from the actual page.
If you have input elements, there will be some kind of proxy elements rendered on top of the "screenshot". Sometimes the are these proxy-elements at the wrong position.
This happens, if you trigger the website to be hardware-accelerted. You have to drop some CSS-definitions:
transform(), translate(), transform3d(), translate3d().
The Bad news are:
You cannot solve this problem, because it a bug within the browser.
I have some different android devices, all have different problems, one fix will break another device.
I think the bug will never be solved, because noone cares about the embedded browser since android 4.1 and the chrome.
If you can disble hardware accelertion, this may help.
The good news are:
There are rumors about an embeddable chrome-webview.
I started to write some blogposts about "the new IE":
http://christian-kuetbach.de/blog/post/14
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>)