| page.title=Navigation with Back and Up |
| page.tags=navigation,activity,task,up navigation,back navigation |
| @jd:body |
| |
| <a class="notice-developers" href="{@docRoot}training/implementing-navigation/index.html"> |
| <div> |
| <h3>Developer Docs</h3> |
| <p>Implementing Effective Navigation</p> |
| </div> |
| </a> |
| |
| <p itemprop="description">Consistent navigation is an essential component of the overall user experience. Few things frustrate |
| users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 |
| introduced significant changes to the global navigation behavior. Thoughtfully following the |
| guidelines for Back and Up will make your app's navigation predictable and reliable for your users.</p> |
| <p>Android 2.3 and earlier relied upon the system <em>Back</em> button for supporting navigation within an |
| app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: |
| the <em>Up</em> button, consisting of the app icon and a left-point caret.</p> |
| |
| <img src="{@docRoot}design/media/navigation_with_back_and_up.png"> |
| |
| <h2 id="up-vs-back">Up vs. Back</h2> |
| |
| <p>The Up button is used to navigate within an app based on the hierarchical relationships |
| between screens. For instance, if screen A displays a list of items, and selecting an item leads to |
| screen B (which presents that item in more detail), then screen B should offer an Up button that |
| returns to screen A.</p> |
| <p>If a screen is the topmost one in an app (that is, the app's home), it should not present an Up |
| button.</p> |
| |
| <p>The system Back button is used to navigate, in reverse chronological order, through the history |
| of screens the user has recently worked with. It is generally based on the temporal relationships |
| between screens, rather than the app's hierarchy.</p> |
| |
| <p>When the previously viewed screen is also the hierarchical parent of the current screen, pressing |
| the Back button has the same result as pressing an Up button—this is a common |
| occurrence. However, unlike the Up button, which ensures the user remains within your app, the Back |
| button can return the user to the Home screen, or even to a different app.</p> |
| |
| <img src="{@docRoot}design/media/navigation_up_vs_back_gmail.png"> |
| |
| <p>The Back button also supports a few behaviors not directly tied to screen-to-screen navigation: |
| </p> |
| <ul> |
| <li>Dismisses floating windows (dialogs, popups)</li> |
| <li>Dismisses contextual action bars, and removes the highlight from the selected items</li> |
| <li>Hides the onscreen keyboard (IME)</li> |
| </ul> |
| <h2 id="within-app">Navigation Within Your App</h2> |
| |
| <h4>Navigating to screens with multiple entry points</h4> |
| <p>Sometimes a screen doesn't have a strict position within the app's hierarchy, and can be reached |
| from multiple entry points—such as a settings screen that can be reached from any other screen |
| in your app. In this case, the Up button should choose to return to the referring screen, behaving |
| identically to Back.</p> |
| <h4>Changing view within a screen</h4> |
| <p>Changing view options for a screen does not change the behavior of Up or Back: the screen is still |
| in the same place within the app's hierarchy, and no new navigation history is created.</p> |
| <p>Examples of such view changes are:</p> |
| <ul> |
| <li>Switching views using tabs and/or left-and-right swipes</li> |
| <li>Switching views using a dropdown (aka collapsed tabs)</li> |
| <li>Filtering a list</li> |
| <li>Sorting a list</li> |
| <li>Changing display characteristics (such as zooming)</li> |
| </ul> |
| <h4>Navigating between sibling screens</h4> |
| <p>When your app supports navigation from a list of items to a detail view of one of those items, it's |
| often desirable to support direction navigation from that item to another one which precedes or |
| follows it in the list. For example, in Gmail, it's easy to swipe left or right from a conversation |
| to view a newer or older one in the same Inbox. Just as when changing view within a screen, such |
| navigation does not change the behavior of Up or Back.</p> |
| |
| <img src="{@docRoot}design/media/navigation_between_siblings_gmail.png"> |
| |
| <p>However, a notable exception to this occurs when browsing between related detail views not tied |
| together by the referring list—for example, when browsing in the Play Store between apps from |
| the same developer, or albums by the same artist. In these cases, following each link does create |
| history, causing the Back button to step through each previously viewed screen. Up should continue |
| to bypass these related screens and navigate to the most recently viewed container screen.</p> |
| |
| <img src="{@docRoot}design/media/navigation_between_siblings_market1.png"> |
| |
| <p>You have the ability to make the Up behavior even smarter based on your knowledge of detail |
| view. Extending the Play Store example from above, imagine the user has navigated from the last |
| Book viewed to the details for the Movie adaptation. In that case, Up can return to a container |
| (Movies) which the user hasn't previously navigated through.</p> |
| |
| <img src="{@docRoot}design/media/navigation_between_siblings_market2.png"> |
| |
| <h2 id="into-your-app">Navigation into Your App via Home Screen Widgets and Notifications</h2> |
| |
| <p>You can use Home screen widgets or notifications to help your users navigate directly to screens |
| deep within your app's hierarchy. For example, Gmail's Inbox widget and new message notification can |
| both bypass the Inbox screen, taking the user directly to a conversation view.</p> |
| |
| <p>For both of these cases, handle the Up button as follows:</p> |
| |
| <ul> |
| <li><em>If the destination screen is typically reached from one particular screen within your |
| app</em>, Up should navigate to that screen.</li> |
| <li><em>Otherwise</em>, Up should navigate to the topmost ("Home") screen of your app.</li> |
| </ul> |
| |
| <p>In the case of the Back button, you should make navigation more predictable by inserting into the |
| task's back stack the complete upward navigation path to the app's topmost screen. This allows users |
| who've forgotten how they entered your app to navigate to the app's topmost screen before |
| exiting.</p> |
| |
| <p>As an example, Gmail's Home screen widget has a button for diving directly to its compose |
| screen. Up or Back from the compose screen would take the user to the Inbox, and from there the |
| Back button continues to Home.</p> |
| |
| <img src="{@docRoot}design/media/navigation_from_outside_back.png"> |
| |
| <h4>Indirect notifications</h4> |
| |
| <p>When your app needs to present information about multiple events simultaneously, it can use a |
| single notification that directs the user to an interstitial screen. This screen summarizes these |
| events, and provides paths for the user to dive deeply into the app. Notifications of this style are |
| called <em>indirect notifications</em>.</p> |
| |
| <p>Unlike standard (direct) notifications, pressing Back from an indirect notification's |
| interstitial screen returns the user to the point the notification was triggered from—no |
| additional screens are inserted into the back stack. Once the user proceeds into the app from its |
| interstitial screen, Up and Back behave as for standard notifications, as described above: |
| navigating within the app rather than returning to the interstitial.</p> |
| |
| <p>For example, suppose a user in Gmail receives an indirect notification from Calendar. Touching |
| this notification opens the interstitial screen, which displays reminders for several different |
| events. Touching Back from the interstitial returns the user to Gmail. Touching on a particular |
| event takes the user away from the interstitial and into the full Calendar app to display details of |
| the event. From the event details, Up and Back navigate to the top-level view of Calendar.</p> |
| |
| <img src="{@docRoot}design/media/navigation_indirect_notification.png"> |
| |
| <h4>Pop-up notifications</h4> |
| |
| <p><em>Pop-up notifications</em> bypass the notification drawer, instead appearing directly in |
| front of the user. They are rarely used, and <strong>should be reserved for occasions where a timely |
| response is required and the interruption of the user's context is necessary</strong>. For example, |
| Talk uses this style to alert the user of an invitation from a friend to join a video chat, as this |
| invitation will automatically expire after a few seconds.</p> |
| |
| <p>In terms of navigation behavior, pop-up notifications closely follow the behavior of an indirect |
| notification's interstitial screen. Back dismisses the pop-up notification. If the user navigates |
| from the pop-up into the notifying app, Up and Back follow the rules for standard notifications, |
| navigating within the app.</p> |
| |
| <img src="{@docRoot}design/media/navigation_popup_notification.png"> |
| |
| <h2 id="between-apps">Navigation Between Apps</h2> |
| |
| <p>One of the fundamental strengths of the Android system is the ability for apps to activate each |
| other, giving the user the ability to navigate directly from one app into another. For example, an |
| app that needs to capture a photo can activate the Camera app, which will return the photo |
| to the referring app. This is a tremendous benefit to both the developer, who can easily leverage |
| code from other apps, and the user, who enjoys a consistent experience for commonly performed |
| actions.</p> |
| |
| <p>To understand app-to-app navigation, it's important to understand the Android framework behavior |
| discussed below.</p> |
| |
| <h4>Activities, tasks, and intents</h4> |
| |
| <p>In Android, an <strong>activity</strong> is an application component that defines a screen of |
| information and all of the associated actions the user can perform. Your app is a collection of |
| activities, consisting of both the activities you create and those you re-use from other apps.</p> |
| |
| <p>A <strong>task</strong> is the sequence of activities a user follows to accomplish a goal. A |
| single task can make use of activities from just one app, or may draw on activities from a number |
| of different apps.</p> |
| |
| <p>An <strong>intent</strong> is a mechanism for one app to signal it would like another |
| app's assistance in performing an action. An app's activities can indicate which intents |
| they can respond to. For common intents such as "Share", the user may have many apps installed |
| that can fulfill that request.</p> |
| |
| <h4>Example: navigating between apps to support sharing</h4> |
| |
| <p>To understand how activities, tasks, and intents work together, consider how one app allows users |
| to share content by using another app. For example, launching the Play Store app from Home begins |
| new Task A (see figure below). After navigating through the Play Store and touching a promoted book |
| to see its details, the user remains in the same task, extending it by adding activities. Triggering |
| the Share action prompts the user with a dialog listing each of the activities (from different apps) |
| which have registered to handle the Share intent.</p> |
| |
| <img src="{@docRoot}design/media/navigation_between_apps_inward.png"> |
| |
| <p>When the user elects to share via Gmail, Gmail's compose activity is added as a continuation of |
| Task A—no new task is created. If Gmail had its own task running in the background, it would |
| be unaffected.</p> |
| |
| <p>From the compose activity, sending the message or touching the Back button returns the user to |
| the book details activity. Subsequent touches of Back continue to navigate back through the Play |
| Store, ultimately arriving at Home.</p> |
| |
| <img src="{@docRoot}design/media/navigation_between_apps_back.png"> |
| |
| <p>However, by touching Up from the compose activity, the user indicates a desire to remain within |
| Gmail. Gmail's conversation list activity appears, and a new Task B is created for it. New tasks are |
| always rooted to Home, so touching Back from the conversation list returns there.</p> |
| |
| <img src="{@docRoot}design/media/navigation_between_apps_up.png"> |
| |
| <p>Task A persists in the background, and the user may return to it later (for example, via the |
| Recents screen). If Gmail already had its own task running in the background, it would be replaced |
| with Task B—the prior context is abandoned in favor of the user's new goal.</p> |
| |
| <p>When your app registers to handle intents with an activity deep within the app's hierarchy, |
| refer to <a href="#into-your-app">Navigation into Your App via Home Screen Widgets and |
| Notifications</a> for guidance on how to specify Up navigation.</p> |