android_frameworks_base/docs/html/design/patterns/navigation.jd

page.title=Navigation with Back and Up
@jd:body

<p>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&mdash;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&mdash;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&mdash;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&mdash;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&mdash;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&mdash;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>