Initially I want to show a composable immediately on top of the Android default keyboard, what slides in if needed on my different screens. Similar like in this example, but I do not want to set WindowCompat.setDecorFitsSystemWindows(window, false), which would be required for this solution.
Therefore, I've set in the manifestv for that Activity:
android:windowSoftInputMode="adjustResize"
And aligned stuff I want to display immediately on top of the keyboard to Alignment.Bottom.
For the very same activity, I also have a use case, where the keyboard slides in, but I do not want to align it on top of the keyboard. it shall remain on the the same position as it was without keyboard.
Can I selectively tell a composable to ignore android:windowSoftInputMode="adjustResize", which was already set for the whole Activity?
Related
I have this code
setContent {
val items = mutableListOf<Int>().apply {
(1..100).forEach { add(it) }
}
LazyColumn {
items(items) { item ->
TextField("$item", {})
}
}
}
With android:windowSoftInputMode="adjustResize" in my AndroidManifest.xml.
If I click on a TextField at the top of the list, I can enter text fine.
If I click on a TextField near the bottom of the screen, the keyboard appears momentarily, then disappears quickly after, and prevents me from entering text.
How can I enter text when the TextField is at the bottom of the screen? Thanks!
Your keyboard disappears after having appeared for a brief, shiny moment. Here's the reason:
You tap the TextField, it calls it's built-in focus requestor, and requests the focus from the OS by calling appropriate (or inappropriate, who's to say) internal methods, as a result of which, the keyboard pops out (again, built-in mechanism.) and you can type all the more you want... AS LONG AS THE FIELD IS VISIBLE; or in Compose terms, long as the Composable holding the requestor, is in composition.
It should be clear, that once the Composable that owns the focus requestor goes off the screen, it is destroyed (well not every time, there are only certain specific cases when it is destroyed..., but yours is one of them), and when the Composable is destroyed, the focus requestor is destroyed. No focus requestor, no focus owner - the keyboard vanishes.
Now this is really important because you are using a LazyColumn, a lazy Composable, infamous for its merciless slaughtering of the Composables that are no longer visible to the user. HENCE, as long as it is the top (or other "visible") textfield that is in concern, it stays and works as expected. However, the bottom textfield, as the keyboard pops up, goes so much out of the visible bounds, that it gets slaughtered (recycled is the technical term, but what fun is that?), taking away the purpose of the keyboard.
Now, the lazy column, like any criminal, left a clue behind, and didn't notice it, which lead us to catch him red-handed. It is quite interesting, really, to see the column in action.
Now, workarounds include using a column, instead of a lazy column; creating your own lazy column using a custom lazy Composable, and manually handling the heap size for the Composable so the final field doesn't go out of composition.
That's it, you're cured.
Just leaving another answer, since OP didn't verify other purpose of him specifying adjustResize,if whether removing or changing it will be fine, but another solution aside from the mentioned comment about different API version is specifying adjustPan, which worked in my case, either
via AndroidManifest
android:windowSoftInputMode="adjustPan"
or programmatically
window.setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN)
Same code base but with adjustPan
This issue is fixed in the current alpha version 1.4.0-alpha05
https://issuetracker.google.com/issues/179203700
I tried and understood what could be the purpose of the accessibilityActivationPoint but in vain.
When a focused accessible element is activated, that property should indicate VoiceOver the specific area it's going to activate when a user double-taps the element (Apple reference) : for me, it's always the selected element itself.
I understood the selected element is considered as a block by VoiceOver, whatever the other elements inside. Once a double tap occurs to activate this block, VoiceOver calls accessibilityActivate to know what to perform (Apple reference).
1/. I've written many tests by creating a custom view including a switch control. Whatever the value of accessibilityActivationPoint inside (or outside on another switch control), the value of the switch control never changes. Is it a proper use case or am I totally wrong ?
2/. When we gather many elements inside one accessible element, how is VoiceOver able to activate one of them while they aren't accessible by definition ? Pointing one of them thanks to the accessibilityActivationPoint should work ?
Personally, I couldn't make it work and think that I'm really confusing accessibilityActivationPoint and accessibilityActivate.
Any help would be appreciated, thanks in advance.
Yes, you have the right idea with accessibilityActivate and accessibilityActivationPoint. Note that, in order for it to work, the accessibilityActivationPoint needs to be a point within the Control that you are trying to activate in on-screen coordinates (use the convert function!).
I think the short answer is "yes" to answer your second question, but, just to clear up confusion about when Accessibility Activation Point is useful, I'll go into more detail about it.
By default (aka, the default behavior for AcessibilityActivate()), when any view is activated by VoiceOver, VoiceOver will send a "tap gesture" to the center of the view. The position of this "tap gesture" can be changed by updating the accessibilityActivationPoint attribute on a view. Below, I have an example for how this property can be used.
Let's say you have a blank button (in the image below, the button is the gray box) next to some text:
For the purpose of accessibility, you may want to make the entire view that holds the button and text an Accessibility Element (so that VoiceOver users can easily understand that the button is associated with the text "Worldspace Attest"). In the image below, I am using Accessibility Inspector to show that the view holding both of these elements is an Accessibility Element.
Notice in these images that the button is not in the center of the view, but rather, it is to the right. When you activate this view using VoiceOver, the view will not select the button; instead, it will send a "tap" to the center of the view (which is the same as tapping the text, which does not do anything). In order to select the button, you have to set the view's accessibilityActivationPoint to be the on-screen coordinates of the button:
view.accessibilityActivationPoint = self.convert(button.center, to: UIApplication.shared.windows.first)
This should make it so that this button is usable by a VoiceOver user.
I hope this information clears up any confusion about the Accessibility Activation Point property. The example I used above can be found in this repository in the "Active Control Name" demo.
I have a Kivy app that uses a slightly modified Settings as a data record editor.
I want to hide or show an item after the setting panel has been created (depending on user interaction with some other setting item).
Is there a simple way of dynamically hiding a setting item, so that it doesn't take up any space?
I can set the opacity to 0 and disabled to True and the items disappears, but still takes space.
Setting the size to (0,0) (to hide) and resetting it to the original value (to show it) corrupts the view.
What is the correct way of doing this?
Removing the SettingItem seems complicated, because the items to hide a somewhere in the middle of the items.
I'm working on an App with Objective-C but I have a problem with my form.
I have several inputs view (UITextField) on it, and one with a particularly behavior.
When I select the checkbox, I prevent the user typing on the view and looks the view as disable( grayed out and without the blue bar flashing blue bar ) and keep the keyboard open.
When I set the UITextField as disable, the keyboard is automatically hidden.
Someone knows how to keep the keyboard open?
I need to something like the image attached, but without the blue bar flashing blue bar.
I did the logic to prevent the the user enter data on the input , but the keyboard is automatically hidden.
If the text field is disabled, the user cannot type into it and the dismissal of the keyboard is correct. You should not try to fight against that. (It sounds like you're trying to disable the keyboard for the wrong reasons anyway.)
In this case, it sounds like your timing is just off. When the user clicks the checkbox, your code responds. What you are doing there is just wrong. You should respond by moving the first responder to the next enabled text field yourself, and then disabling the first text field. That way, you are not disabling the text field while it is first responder; that's your whole mistake right there.
What I'm trying to do is simple: bring a label in front of an image within a subview.
But all of the options for arranging are disabled/un-selectable when my label is selected. I find this happens often.
What could be the reason that I'm almost never allowed to change the z-axis of my objects in the Arrange menu? Is it a better practice to avoid this feature and set the order of views programmatically?
It can depend on how you have selected the label (similar to how the label can only be moved with the keyboard when selected in some ways).
A simple alternative is to look at the list of view in the pane on the left and to drag the views up and down to change the order.
It happens sometimes. In that situation, click the view or image you want to send back then you will see little square box at the edges of image from which you can re size your image, Just click on it once and then go to Editor > Arrange > Choose option according your need.