I have a very simple UI that has one entry control to enter phone number and a button. The entry control has a handler for removing border around it. When the entry control got focus, keyboard pops up. But when I try to tap outside the entry control such as on the screen empty area, the keyboard does not dismiss and the entry control does not lose focus. Also since the button is at the bottom of the screen, therefore, the soft keyboard hides it and there is no way to tap the button. The button can only be tapped if I press the Android device back button.
At present, I have not checked this behavior on an iOS device.
This was not a problem in Xamarin Forms though. I searched a lot on Internet and found that it is currently a bug in MAUI.
I tried to attach a tap gesture on the parent layout control and invoked platform-specific code to hide the keyboard but it seems the entry does not lose focus and in turn the tap gesture event is never called.
However, the entry control should lose focus automatically when I tap outside the entry control (such as on the screen) and the soft keyboard should automatically dismiss.
Please provide a workaround if there is any.
Known bug. Removing the focus sometimes helps. Sometimes you need to do Disable/Enable in sequence. (I go with the second).
If you want, you can read this for example:
https://github.com/dotnet/maui/issues/12002
(Most disturbing part, considering this is know bug for half year+)
We can leave the behavior how this is for now in NET7 and provide an
API in NET8 that lets users toggle this behavior on/off for iOS and
Android
Related
Is there any way to enable onFocus, onBlur etc. on Touchable-Elements on non-TVs devices?
The touchable elements event is not triggered, but the default feedback is visible when I use the physical keyboard.
I need simple dialogs on a Zebra mc3300. This device has a physical keyboard and when I show a dialog with a yes/no question, one button should have focus when the dialog becomes visible.
I'm not sure, maybe ref.current?.focus() works, when I press enter the key onPress is triggered, but i don't get any visible feedback which key has the focus. Only when I use the hardware button to switch to the next element and back again, the button became a different opacity.
Many thanks to you.
I have a custom android keyboard. On long press popup keyboard is shown how it should. The problem is, when it pops up, the keyboard behind is darkenes.
How can i disable this, except overriding the default KeyboardView onDraw?
One more thing: how can I make the poped up keyboard buttons selected without pressing on them? In Google keyboard, when you press on a "." key, you just keep moving your finger and it selects the key on the popup. But on the default implementation of KeyboardView, you have to press on the key.
This has been bugging me for a month, hope you can help!
Solution: don't use KeyboardView. Its meant for quick prototyping, when you need a basic keyboard and are working on other things like autocorrect algorithms. No serious keyboard actually uses it, and it isn't required (you can return any view from onCreateInputView). As you ramp up UI complexity, it just quickly becomes unable to deal
In the context of an Android app, I have a handful of EditText's as part of a fairly typical "enter registration details" form.
If I specify android:imeOptions="actionDone" on them, the user gets 'done' option on their soft keyboard which immediately hides the keyboard, which I feel is analogous to hitting the enter key.
If I just leave them as-is, the option defaults to 'next' (until the last EditText) and shifts focus to the next widget without hiding the keyboard, analogous to hitting the tab key.
On a desktop environment I would fully expect my final action on each field to be 'tab', but I also don't have a keyboard covering up half of the form. I find that on this activity, my co-workers and I usually prefer to hide the keyboard before focusing on the rest of the form, and the back key is not an muscle-memory action for most (lots of designers and devs using other platforms).
From a UX perspective, which is the better option?
Giving the user control is almost always the best option, in my opinion.
Setting the button behavior to "done" replicates the functionality of the back soft key, and prevents the user from quickly and easily moving to the next field. The "next" option means that closing the keyboard and jumping to the next field are just a single tap away.
Additionally, leaving the default behavior in place means that your app is consistent with virtually everything else out there, for Android or iOS, which is definitely good for muscle memory.
I'm looking at the Support4Demos from the Android SDK and I'm not sure if this is working as intended. Specifically, I'm referring to accessibility focus when using the Widget > Explore by Touch Helper demo. If I tap on one of the blue regions to give it accessibility focus then tap on the on-screen home button focus will switch to the home button. But if I tap on the same blue region as before nothing happens (but if I tap on the other blue region focus transfers from the home button). I'm testing this on a Kindle with on-screen navigation buttons.
Am I correct in assuming that focus should transfer back to the blue region? If so, what is the proper way to handle this? Presumably there would be a way to know that the user tapped on something outside of the app and in response to this I could clear state in the ExploreByTouchHelper but I'm not sure how I would go about that.
Most of the time (but not always), when I finish typing in a or and the soft keyboard hides, the view area is left raised with a black space on the bottom. Clicking, tilting or otherwise engaging the phone corrects the screen. However, user's first motion is usually pressing , but if you click submit it jumps down and you actually just click on the text area again. How do you stop this and get the screen to reset after the keyboard closes.
Take a look at you AndroidManifest.xml
http://developer.android.com/guide/topics/manifest/activity-element.html
I think you need to change android:configChanges.
I have the exact same problem what i did was handle hidekeyboard even in javascript and do something like window.scrollTo(0,0) or $("input[type=text],textarea").blur();
This will cause the the screen to get back to normal position
But there is just one problem when click from input field of type = text to a input field password it internally hide the keyboard which causes the hidekeyboard event to fire and scrolls the screen to top. This is the only side effect of this
Let me know if you find the solution for this