Android touch mode

Most Android devices use touch screens, but Android devices also support keyboard operations, allowing navigation, clicking, and inputting through the keyboard.

When a user uses a keyboard (or trackball), it is necessary to focus on the UI elements currently accepted, for example, highlighting a button, let the user know which UI element is being operated.

However, when a user uses a touch screen to interact with a device, it is unnecessary and ugly to focus on the current UI element. The user clicks which element is the current element, no need to highlight the logo. In addition, when you use a touch screen to interact with a device, clicking a UI element does not cause the element to focus. At this time, the highlighted effect is completed by the pressed state. That is to say, in touch mode, UI elements do not enter the focus state, even if requestfocus is called.

Then, how does Android differentiate these two situations?

The answer is touch mode. When the user starts to interact with the device through the keyboard, the device will exit the touch mode. When the user starts to interact with the device through the touch screen, the device will enter the touch mode. You can call isintouchmode of view to determine whether the device is in touch mode.

However, there are exceptions. Some UI elements, even in the touch mode status, need to obtain the focus, which is typically edittext. So what should we do with this situation?

The answer is special processing. Android requires that some elements can get focus even in touch mode. Call the setfocusableintouchmode (true) of the view so that the view can still obtain the focus in touch mode (for example, edittext sets this attribute internally ), call isfocusableintouchmode to determine whether the view can be focused in touch mode.