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