I am new to android development. Please help me out and if possible let me know, what is clipChildren, baseAligned, baseAlignedChildrenIndex. These are the things, in which, I have doubts in creating an application.
The touch mode is something very easy to understand as it simply indicates whether the last user interaction was performed with the touch screen. For example, if you are using a G1 phone, selecting a widget with the trackball will take you out of touch mode;
In touch mode, there is no focus and no selection. Any selected item in a list of in a grid becomes unselected as soon as the user enters touch mode. Similarly, any focused widgets become unfocused when the user enters touch mode.
Now that you know focus doesn't exist in touch mode, I must explain that it's not entirely true. Focus can exist in touch mode but in a very special way we call focusable in touch mode. This special mode was created for widgets that receive text input, like EditText or, when filtering is enabled, ListView.
Focusable in touch mode is a property that you can set yourself either from code or XML. However, it should be used sparingly and only in very specific situations as it breaks consistency with Android normal behavior. A game is a good example of an application that can make good use of the focusable in touch mode property. MapView, if used in fullscreen as in Google Maps, is another good example of where you can use focusable in touch mode correctly.
for mor Detail see Developer Blog http://android-developers.blogspot.co.at/2008/12/touch-mode.html
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.
I have a floating app which works perfectly.
I am using OnTouchListener to catch events since I need to use the GestureDetector for swipes etc.
My only problem is that sometimes I wish to ignore certain events on the view.
In this case the view is invisible but not "gone" because I need it to accept certain gestures but not others.
I can't seem to be able to do that.
Returning false from "onTouch" simply doesn't work.
I checked that by experiment by disabling the GestureDetector and simply always returning false just to see what would happen. Result was nothing going through.
Is it even possible to pass a click through to a covered app?
Due to security reasons it's not possible to record and pass a click below (essentially allows building a keylogger).
Best you can do is have your floating window small enough to start the touch but not cover too much of the screen below.
Please tell me why is the following XML attribute used ?
I looked up the documentation on developer.android.com but could not understand anything.
android:focusableInTouchMode
This blog post can help you to understand the meaning of touch mode.
The most relevant part :
The touch mode is a state of the view hierarchy that depends solely on the user interaction with the phone. By itself, the touch mode is something very easy to understand as it simply indicates whether the last user interaction was performed with the touch screen. For example, if you are using a G1 phone, selecting a widget with the trackball will take you out of touch mode; however, if you touch a button on the screen with your finger, you will enter touch mode. When the user is not in touch mode, we talk about the trackball mode, navigation mode or keyboard navigation, so do not be surprised if you encounter these terms. Finally, there is only one API directly related to touch mode, View.isInTouchMode().
So android:focusableInTouchMode="true" means that the view can get the focus when the phone is in touch mode.
Typically an EditText is generally focusable in touch mode and on the other hand a Button is generally not focusable in touch mode.
Happened to me when I didn't have the correct number of items in getItemCount().
Double check that you have the right number of items!
The buttons in my app immediately display their state_pressed drawable when I tap them quickly, but only after about 300ms when I touch and hold them. I'm using a drawerlayout, and have noticed the same behavior in other apps with the drawerlayout. Other apps, eg, the calculator, display their state_pressed drawable immediately. Where is this determined?
I suspect it has to do with detecting longclicks or flings, possibly to enable opening the navigation drawer.
I'm only interested in increasing the responsiveness of the visual feedback when touching and holding a button, not its function. So it seems like the simplest solution might be to somehow manually display the drawable immediately, even though the system is still waiting to see what kind of gesture it is.
Thanks!
(Edit) Figured it out:
public boolean shouldDelayChildPressedState ()
Added in API level 14
Return true if the pressed state should be delayed for children or descendants of this ViewGroup. Generally, this should be done for containers that can scroll, such as a List. This prevents the pressed state from appearing when the user is actually trying to scroll the content. The default implementation returns true for compatibility reasons. Subclasses that do not scroll should generally override this method and return false.
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.