Dirk Dougherty | 22558d0 | 2009-12-10 16:25:06 -0800 | [diff] [blame] | 1 | page.title=Touch Mode |
Scott Main | 796ce77 | 2011-02-16 10:04:45 -0800 | [diff] [blame] | 2 | parent.title=Articles |
| 3 | parent.link=../browser.html?tag=article |
Dirk Dougherty | 22558d0 | 2009-12-10 16:25:06 -0800 | [diff] [blame] | 4 | @jd:body |
| 5 | |
| 6 | <p>This article explains the <em>touch mode</em>, one of the most |
| 7 | important principles of Android's UI toolkit.</p> |
| 8 | |
| 9 | <p>The touch mode is a state of the view hierarchy that depends solely on the |
| 10 | user interaction with the phone. By itself, the touch mode is something very |
| 11 | easy to understand as it simply indicates whether the last user interaction was |
| 12 | performed with the touch screen. For example, if you are using an |
| 13 | Android-powered device, selecting a widget with the trackball will take you out |
| 14 | of touch mode; however, if you touch a button on the screen with your finger, |
| 15 | you will enter touch mode. When the user is not in touch mode, we talk about the |
| 16 | trackball mode, navigation mode or keyboard navigation, so do not be surprised |
| 17 | if you encounter these terms. </p> |
| 18 | |
| 19 | <p>There is only one API directly related to touch mode, |
| 20 | {@link android.view.View#isInTouchMode() View.isInTouchMode()}.</p> |
| 21 | |
| 22 | <p>Sounds easy enough, right? Oddly enough, touch mode is deceivingly simple and |
| 23 | the consequences of entering touch mode are far greater than you might |
| 24 | think. Let's look at some of the reasons why.</p> |
| 25 | |
| 26 | <h4>Touch Mode, Selection, and Focus</h4> |
| 27 | |
| 28 | <p>Designing a UI toolkit for mobile devices is difficult because of the various |
| 29 | interaction mechanisms they provide. Some devices offer only 12 keys, some have |
| 30 | a touch screen, some require a stylus, some have both a touch screen and a |
| 31 | keyboard. Based on the hardware capabilities of the he user can interact with |
| 32 | your application using different mechanisms, so we had to think very hard about |
| 33 | all the possible issues that could arise. One issue led us to create the touch |
| 34 | mode.</p> |
| 35 | |
| 36 | <p>Imagine a simple application, <a href="{@docRoot}resources/samples/index.html">ApiDemos</a> |
| 37 | for example, that shows a list of text items. The user can freely |
| 38 | navigate through the list using the trackball but also, alternatively, scroll |
| 39 | and fling the list using the touch screen. The issue in this scenario is |
| 40 | how to handle the selection properly when the user manipulates the list |
| 41 | through the touch screen. </p> |
| 42 | |
| 43 | <p>In this case, if the user selects an item at the top of the list and then |
| 44 | flings the list towards the bottom, what should happen to the selection? Should |
| 45 | it remain on the item and scroll off the screen? What should happen if the user |
| 46 | then decided to move the selection with the trackball? Or worse, what should |
| 47 | happen if the user presses the trackball to act upon the currently selected |
| 48 | item, which is not shown on screen anymore? </p> |
| 49 | |
| 50 | <p>After careful consideration, we decided to remove the selection altogether, |
| 51 | when the user manipulates the UI through the touch screen.</p> |
| 52 | |
| 53 | <p>In touch mode, there is no focus and no selection. Any selected item in a |
| 54 | list of in a grid becomes unselected as soon as the user enters touch |
| 55 | mode. Similarly, any focused widgets become unfocused when the user |
| 56 | enters touch mode. The image below illustrates what happens when the |
| 57 | user touches a list after selecting an item with the trackball.</p> |
| 58 | |
| 59 | <img style="margin: 0px 7px;" src="images/list02.png" alt="" id="BLOGGER_PHOTO_ID_5272753165743060962" border="0"> |
| 60 | <img style="margin: 0px 7px;" src="images/list01.png" alt="" id="BLOGGER_PHOTO_ID_5272753357441963442" border="0"> |
| 61 | |
| 62 | <p>To |
| 63 | make things more natural for the user, the framework knows how to |
| 64 | resurrect the selection/focus whenever the user leaves touch mode. For |
| 65 | instance, in the example above, if the user were to use the trackball |
| 66 | again, the selection would reappear on the previously-selected item. |
| 67 | This is why some developers are confused when they create a custom view |
| 68 | and start receiving key events only after moving the trackball once: |
| 69 | their application is in touch mode, and they need to use the trackball |
| 70 | to exit touch mode and resurrect the focus.</p> |
| 71 | |
| 72 | <p>The relationship between touch mode, selection, and focus means you must not |
| 73 | rely on selection and/or focus to exist in your application. A very common |
| 74 | problem with new Android developers is to rely on |
| 75 | {@link android.widget.AdapterView#getSelectedItemPosition() ListView.getSelectedItemPosition()}. |
| 76 | In touch mode, this method will return |
| 77 | {@link android.widget.AdapterView#INVALID_POSITION INVALID_POSITION}. |
| 78 | You should instead use click listeners (see |
| 79 | {@link android.widget.AdapterView#setOnItemClickListener(android.widget.AdapterView.OnItemClickListener)}) |
| 80 | or the choice mode (see |
| 81 | {@link android.widget.ListView#setChoiceMode(int)}).</p> |
| 82 | |
| 83 | <h4>Focusable in Touch Mode</h4> |
| 84 | |
| 85 | <p>In general, focus doesn't exist in touch mode. However, focus can exist in |
| 86 | touch mode in a very special way called <em>focusable</em>. This special mode |
| 87 | was created for widgets that receive text input, such as |
| 88 | {@link android.widget.EditText} or, when filtering is enabled, |
| 89 | {@link android.widget.ListView}. The focusable mode is what lets the user enter text |
| 90 | inside a text field on the screen, without first selecting it with the trackball |
| 91 | or their finger.</p> |
| 92 | |
| 93 | <p>When a user |
| 94 | touches the screen, the application will enter touch mode if it wasn't |
| 95 | in touch mode already. What happens during the transition to |
| 96 | touch mode depends on what the user touched, and what currently has |
| 97 | focus. If the user touches a widget that is focusable in touch |
| 98 | mode, that widget will receive focus. Otherwise, any currently |
| 99 | focused widget will not retain focus unless it is focusable in touch |
| 100 | mode. For instance, in the picture below, when the user touches |
| 101 | the screen, the input text field receives the focus.</p> |
| 102 | |
| 103 | <img style="margin: 0px 7px;" src="images/text_field.png" alt="" id="BLOGGER_PHOTO_ID_5272755475757779154" border="0"> |
| 104 | |
| 105 | <p>Fousable in touch mode (see |
| 106 | {@link android.view.View#setFocusableInTouchMode(boolean) View.setFocusableInTouchMode}) |
| 107 | is a property that you can set yourself, either from code or from XML. |
| 108 | However, you should use it sparingly and only in very specific situations, |
| 109 | because it breaks consistency with the normal behavior of the Android UI. A game |
| 110 | is a good example of an application that could make good use of the focusable in |
| 111 | touch mode property. MapView, if used in fullscreen as in Google Maps, is |
| 112 | another good example of where you can use focusable in touch mode correctly.</p> |
| 113 | |
| 114 | <p>Below is another example of a focusable in touch mode widget. When the user |
| 115 | taps an <code>AutoCompleteTextView</code> suggestion with his finger, the focus |
| 116 | remains on the input text field:</p> |
| 117 | |
| 118 | <img style="margin: 0px 7px;" src="images/search01.png" alt="" id="BLOGGER_PHOTO_ID_5272756689821626962" border="0"> |
| 119 | <img style="margin: 0px 7px;" src="images/search02.png" alt="" id="BLOGGER_PHOTO_ID_5272756246104676754" border="0"> |
| 120 | |
| 121 | <p>Developers new to Android often think that focusable in touch mode is the |
| 122 | solution they need to "fix" the problem of "disappearing" selection/focus. We |
| 123 | really encourage you to think very hard before using it. If used incorrectly, it |
| 124 | can make your application behave differently from the rest of the system and |
| 125 | simply throw off the user's habits. The Android framework contains all the tools |
| 126 | you need to handle user interactions without using focusable in touch mode. For |
| 127 | example, instead of trying to make <code>ListView</code> always keep its |
| 128 | selection, simply use the appropriate choice mode, as shown in |
| 129 | {@link android.widget.ListView#setChoiceMode(int)}. |
| 130 | |
| 131 | <h4>Touch Mode Cheat Sheet</h4> |
| 132 | |
| 133 | <p>Do:</p> |
| 134 | <ul> |
| 135 | <li>Remain consistent with the core applications</li><li>Use the appropriate feature if you need persistent selection (radio button, check box, the <code>ListView</code> choice mode, etc.)</li> |
| 136 | <li>Use focusable in touch mode if you write a game</li> |
| 137 | </ul> |
| 138 | |
| 139 | <p>Don't:</p> |
| 140 | <ul><li>Do not try to keep the focus or selection in touch mode</li></ul> |