diff options
Diffstat (limited to 'docs/html/design/patterns/navigation.jd')
| -rw-r--r-- | docs/html/design/patterns/navigation.jd | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/docs/html/design/patterns/navigation.jd b/docs/html/design/patterns/navigation.jd new file mode 100644 index 0000000..7e288ae --- /dev/null +++ b/docs/html/design/patterns/navigation.jd @@ -0,0 +1,204 @@ +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—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> |