Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 1 | page.title=Navigation with Back and Up |
Scott Main | e04c454 | 2013-06-18 21:16:25 -0700 | [diff] [blame] | 2 | page.tags="navigation","activity","task","up navigation","back navigation" |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 3 | @jd:body |
| 4 | |
Scott Main | cbcd17d | 2013-05-14 08:46:55 -0700 | [diff] [blame] | 5 | <a class="notice-developers" href="{@docRoot}training/implementing-navigation/index.html"> |
| 6 | <div> |
| 7 | <h3>Developer Docs</h3> |
| 8 | <p>Implementing Effective Navigation</p> |
| 9 | </div> |
| 10 | </a> |
| 11 | |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 12 | <p>Consistent navigation is an essential component of the overall user experience. Few things frustrate |
| 13 | users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 |
| 14 | introduced significant changes to the global navigation behavior. Thoughtfully following the |
| 15 | guidelines for Back and Up will make your app's navigation predictable and reliable for your users.</p> |
| 16 | <p>Android 2.3 and earlier relied upon the system <em>Back</em> button for supporting navigation within an |
| 17 | app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: |
| 18 | the <em>Up</em> button, consisting of the app icon and a left-point caret.</p> |
| 19 | |
| 20 | <img src="{@docRoot}design/media/navigation_with_back_and_up.png"> |
| 21 | |
| 22 | <h2 id="up-vs-back">Up vs. Back</h2> |
| 23 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 24 | <p>The Up button is used to navigate within an app based on the hierarchical relationships |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 25 | between screens. For instance, if screen A displays a list of items, and selecting an item leads to |
| 26 | screen B (which presents that item in more detail), then screen B should offer an Up button that |
| 27 | returns to screen A.</p> |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 28 | <p>If a screen is the topmost one in an app (that is, the app's home), it should not present an Up |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 29 | button.</p> |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 30 | |
| 31 | <p>The system Back button is used to navigate, in reverse chronological order, through the history |
| 32 | of screens the user has recently worked with. It is generally based on the temporal relationships |
| 33 | between screens, rather than the app's hierarchy.</p> |
| 34 | |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 35 | <p>When the previously viewed screen is also the hierarchical parent of the current screen, pressing |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 36 | the Back button has the same result as pressing an Up button—this is a common |
| 37 | occurrence. However, unlike the Up button, which ensures the user remains within your app, the Back |
| 38 | button can return the user to the Home screen, or even to a different app.</p> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 39 | |
| 40 | <img src="{@docRoot}design/media/navigation_up_vs_back_gmail.png"> |
| 41 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 42 | <p>The Back button also supports a few behaviors not directly tied to screen-to-screen navigation: |
| 43 | </p> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 44 | <ul> |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 45 | <li>Dismisses floating windows (dialogs, popups)</li> |
| 46 | <li>Dismisses contextual action bars, and removes the highlight from the selected items</li> |
| 47 | <li>Hides the onscreen keyboard (IME)</li> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 48 | </ul> |
| 49 | <h2 id="within-app">Navigation Within Your App</h2> |
| 50 | |
| 51 | <h4>Navigating to screens with multiple entry points</h4> |
| 52 | <p>Sometimes a screen doesn't have a strict position within the app's hierarchy, and can be reached |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 53 | from multiple entry points—such as a settings screen that can be reached from any other screen |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 54 | in your app. In this case, the Up button should choose to return to the referring screen, behaving |
| 55 | identically to Back.</p> |
| 56 | <h4>Changing view within a screen</h4> |
| 57 | <p>Changing view options for a screen does not change the behavior of Up or Back: the screen is still |
| 58 | in the same place within the app's hierarchy, and no new navigation history is created.</p> |
| 59 | <p>Examples of such view changes are:</p> |
| 60 | <ul> |
| 61 | <li>Switching views using tabs and/or left-and-right swipes</li> |
| 62 | <li>Switching views using a dropdown (aka collapsed tabs)</li> |
| 63 | <li>Filtering a list</li> |
| 64 | <li>Sorting a list</li> |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 65 | <li>Changing display characteristics (such as zooming)</li> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 66 | </ul> |
| 67 | <h4>Navigating between sibling screens</h4> |
| 68 | <p>When your app supports navigation from a list of items to a detail view of one of those items, it's |
| 69 | often desirable to support direction navigation from that item to another one which precedes or |
| 70 | follows it in the list. For example, in Gmail, it's easy to swipe left or right from a conversation |
| 71 | to view a newer or older one in the same Inbox. Just as when changing view within a screen, such |
| 72 | navigation does not change the behavior of Up or Back.</p> |
| 73 | |
| 74 | <img src="{@docRoot}design/media/navigation_between_siblings_gmail.png"> |
| 75 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 76 | <p>However, a notable exception to this occurs when browsing between related detail views not tied |
| 77 | together by the referring list—for example, when browsing in the Play Store between apps from |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 78 | the same developer, or albums by the same artist. In these cases, following each link does create |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 79 | history, causing the Back button to step through each previously viewed screen. Up should continue |
| 80 | to bypass these related screens and navigate to the most recently viewed container screen.</p> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 81 | |
| 82 | <img src="{@docRoot}design/media/navigation_between_siblings_market1.png"> |
| 83 | |
| 84 | <p>You have the ability to make the Up behavior even smarter based on your knowledge of detail |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 85 | view. Extending the Play Store example from above, imagine the user has navigated from the last |
| 86 | Book viewed to the details for the Movie adaptation. In that case, Up can return to a container |
| 87 | (Movies) which the user hasn't previously navigated through.</p> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 88 | |
| 89 | <img src="{@docRoot}design/media/navigation_between_siblings_market2.png"> |
| 90 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 91 | <h2 id="into-your-app">Navigation into Your App via Home Screen Widgets and Notifications</h2> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 92 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 93 | <p>You can use Home screen widgets or notifications to help your users navigate directly to screens |
| 94 | deep within your app's hierarchy. For example, Gmail's Inbox widget and new message notification can |
| 95 | both bypass the Inbox screen, taking the user directly to a conversation view.</p> |
| 96 | |
| 97 | <p>For both of these cases, handle the Up button as follows:</p> |
| 98 | |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 99 | <ul> |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 100 | <li><em>If the destination screen is typically reached from one particular screen within your |
| 101 | app</em>, Up should navigate to that screen.</li> |
| 102 | <li><em>Otherwise</em>, Up should navigate to the topmost ("Home") screen of your app.</li> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 103 | </ul> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 104 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 105 | <p>In the case of the Back button, you should make navigation more predictable by inserting into the |
| 106 | task's back stack the complete upward navigation path to the app's topmost screen. This allows users |
| 107 | who've forgotten how they entered your app to navigate to the app's topmost screen before |
| 108 | exiting.</p> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 109 | |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 110 | <p>As an example, Gmail's Home screen widget has a button for diving directly to its compose |
| 111 | screen. Up or Back from the compose screen would take the user to the Inbox, and from there the |
| 112 | Back button continues to Home.</p> |
Roman Nurik | b99ae73 | 2012-03-06 12:26:15 -0800 | [diff] [blame] | 113 | |
| 114 | <img src="{@docRoot}design/media/navigation_from_outside_back.png"> |
Roman Nurik | b20f120 | 2012-03-29 13:28:13 -0700 | [diff] [blame] | 115 | |
| 116 | <h4>Indirect notifications</h4> |
| 117 | |
| 118 | <p>When your app needs to present information about multiple events simultaneously, it can use a |
| 119 | single notification that directs the user to an interstitial screen. This screen summarizes these |
| 120 | events, and provides paths for the user to dive deeply into the app. Notifications of this style are |
| 121 | called <em>indirect notifications</em>.</p> |
| 122 | |
| 123 | <p>Unlike standard (direct) notifications, pressing Back from an indirect notification's |
| 124 | interstitial screen returns the user to the point the notification was triggered from—no |
| 125 | additional screens are inserted into the back stack. Once the user proceeds into the app from its |
| 126 | interstitial screen, Up and Back behave as for standard notifications, as described above: |
| 127 | navigating within the app rather than returning to the interstitial.</p> |
| 128 | |
| 129 | <p>For example, suppose a user in Gmail receives an indirect notification from Calendar. Touching |
| 130 | this notification opens the interstitial screen, which displays reminders for several different |
| 131 | events. Touching Back from the interstitial returns the user to Gmail. Touching on a particular |
| 132 | event takes the user away from the interstitial and into the full Calendar app to display details of |
| 133 | the event. From the event details, Up and Back navigate to the top-level view of Calendar.</p> |
| 134 | |
| 135 | <img src="{@docRoot}design/media/navigation_indirect_notification.png"> |
| 136 | |
| 137 | <h4>Pop-up notifications</h4> |
| 138 | |
| 139 | <p><em>Pop-up notifications</em> bypass the notification drawer, instead appearing directly in |
| 140 | front of the user. They are rarely used, and <strong>should be reserved for occasions where a timely |
| 141 | response is required and the interruption of the user's context is necessary</strong>. For example, |
| 142 | Talk uses this style to alert the user of an invitation from a friend to join a video chat, as this |
| 143 | invitation will automatically expire after a few seconds.</p> |
| 144 | |
| 145 | <p>In terms of navigation behavior, pop-up notifications closely follow the behavior of an indirect |
| 146 | notification's interstitial screen. Back dismisses the pop-up notification. If the user navigates |
| 147 | from the pop-up into the notifying app, Up and Back follow the rules for standard notifications, |
| 148 | navigating within the app.</p> |
| 149 | |
| 150 | <img src="{@docRoot}design/media/navigation_popup_notification.png"> |
| 151 | |
| 152 | <h2 id="between-apps">Navigation Between Apps</h2> |
| 153 | |
| 154 | <p>One of the fundamental strengths of the Android system is the ability for apps to activate each |
| 155 | other, giving the user the ability to navigate directly from one app into another. For example, an |
| 156 | app that needs to capture a photo can activate the Camera app, which will return the photo |
| 157 | to the referring app. This is a tremendous benefit to both the developer, who can easily leverage |
| 158 | code from other apps, and the user, who enjoys a consistent experience for commonly performed |
| 159 | actions.</p> |
| 160 | |
| 161 | <p>To understand app-to-app navigation, it's important to understand the Android framework behavior |
| 162 | discussed below.</p> |
| 163 | |
| 164 | <h4>Activities, tasks, and intents</h4> |
| 165 | |
| 166 | <p>In Android, an <strong>activity</strong> is an application component that defines a screen of |
| 167 | information and all of the associated actions the user can perform. Your app is a collection of |
| 168 | activities, consisting of both the activities you create and those you re-use from other apps.</p> |
| 169 | |
| 170 | <p>A <strong>task</strong> is the sequence of activities a user follows to accomplish a goal. A |
| 171 | single task can make use of activities from just one app, or may draw on activities from a number |
| 172 | of different apps.</p> |
| 173 | |
| 174 | <p>An <strong>intent</strong> is a mechanism for one app to signal it would like another |
| 175 | app's assistance in performing an action. An app's activities can indicate which intents |
| 176 | they can respond to. For common intents such as "Share", the user may have many apps installed |
| 177 | that can fulfill that request.</p> |
| 178 | |
| 179 | <h4>Example: navigating between apps to support sharing</h4> |
| 180 | |
| 181 | <p>To understand how activities, tasks, and intents work together, consider how one app allows users |
| 182 | to share content by using another app. For example, launching the Play Store app from Home begins |
| 183 | new Task A (see figure below). After navigating through the Play Store and touching a promoted book |
| 184 | to see its details, the user remains in the same task, extending it by adding activities. Triggering |
| 185 | the Share action prompts the user with a dialog listing each of the activities (from different apps) |
| 186 | which have registered to handle the Share intent.</p> |
| 187 | |
| 188 | <img src="{@docRoot}design/media/navigation_between_apps_inward.png"> |
| 189 | |
| 190 | <p>When the user elects to share via Gmail, Gmail's compose activity is added as a continuation of |
| 191 | Task A—no new task is created. If Gmail had its own task running in the background, it would |
| 192 | be unaffected.</p> |
| 193 | |
| 194 | <p>From the compose activity, sending the message or touching the Back button returns the user to |
| 195 | the book details activity. Subsequent touches of Back continue to navigate back through the Play |
| 196 | Store, ultimately arriving at Home.</p> |
| 197 | |
| 198 | <img src="{@docRoot}design/media/navigation_between_apps_back.png"> |
| 199 | |
| 200 | <p>However, by touching Up from the compose activity, the user indicates a desire to remain within |
| 201 | Gmail. Gmail's conversation list activity appears, and a new Task B is created for it. New tasks are |
| 202 | always rooted to Home, so touching Back from the conversation list returns there.</p> |
| 203 | |
| 204 | <img src="{@docRoot}design/media/navigation_between_apps_up.png"> |
| 205 | |
| 206 | <p>Task A persists in the background, and the user may return to it later (for example, via the |
| 207 | Recents screen). If Gmail already had its own task running in the background, it would be replaced |
| 208 | with Task B—the prior context is abandoned in favor of the user's new goal.</p> |
| 209 | |
| 210 | <p>When your app registers to handle intents with an activity deep within the app's hierarchy, |
| 211 | refer to <a href="#into-your-app">Navigation into Your App via Home Screen Widgets and |
| 212 | Notifications</a> for guidance on how to specify Up navigation.</p> |