path: root/docs/html-intl/intl/zh-tw/design/patterns/navigation.jd

page.title=使用 [返回] 及 [上一層] 導覽
page.tags="navigation","activity","task","up navigation","back navigation"
page.image=/design/media/navigation_between_siblings_gmail.png
@jd:body

<a class="notice-developers" href="{@docRoot}training/implementing-navigation/index.html">
  <div>
    <h3>開發人員文件</h3>
    <p>實作有效的導覽</p>
  </div>
</a>

<p itemprop="description">一致的導覽是整體使用者體驗的要件。以不一致且非預期方式運作的基本導覽行為最令使用者感到沮喪。
Android 3.0 已將重大變更導入全域的導覽行為中。
仔細遵循以下指導方針原則以設定 [返回] 及 [上一層] 按鈕，讓您的應用程式更可靠且符合預期。
</p>
<p>Android 2.3 及之前版本均使用 [返回]<em></em> 按鈕在應用程式中進行導覽。
在 Android 3.0 導入導覽列功能，使用者有了另一種導覽方式：[上一層]<em></em> 按鈕，由應用程式圖示及左指插入號組成。
</p>

<img src="{@docRoot}design/media/navigation_with_back_and_up.png">

<h2 id="up-vs-back">[返回] 及 [上一層]</h2>

<p>[上一層] 按鈕用於在應用程式中，根據畫面之間的階層關係進行導覽。
例如，如果畫面 A 顯示項目清單，然後選擇其中一個項目導致進入畫面 B (更詳細呈現該項目)，那麼畫面 B 應該提供 [上一層] 按鈕，以便返回畫面 A。

</p>
<p>如果畫面是在應用程式中的最頂端 (亦即應用程式的首頁)，則不應該會有 [上一層] 按鈕。
</p>

<p>系統 [返回] 按鈕用於逆時間順序導覽，透過歷程記錄，可以經歷使用者最近使用過的畫面。
[返回] 通常基於畫面之間的暫時關係，而非應用程式的階層。
</p>

<p>當先前檢視的畫面也是目前畫面的階層父項時，按下 [返回] 按鈕和按下 [上一層] 按鈕效果相同 &mdash; 這是常見的狀況。

然而，與 [上一層] 按鈕不同的是 (該按鈕可以確保使用者仍停留在您的應用程式內)：[返回] 按鈕可以讓使用者返回主螢幕，或甚至是不同的應用程式。
</p>

<img src="{@docRoot}design/media/navigation_up_vs_back_gmail.png">

<p>[返回] 按鈕還支援幾個間接關聯畫面對畫面導覽的行為：
</p>
<ul>
<li>關閉浮動視窗 (對話框、快顯)</li>
<li>關閉內容相關的動作列，並從選取項目移除醒目顯示</li>
<li>隱藏畫面鍵盤 (IME)</li>
</ul>
<h2 id="within-app">在應用程式內導覽</h2>

<h4>導覽至具有多個進入點的畫面</h4>
<p>有時畫面在應用程式中的階層並不明確，可從多個入口點進入畫面 &mdash; 例如，可從應用程式中的任何其他畫面進入的設定畫面。

在這種情況下，應按下 [上一層] 按鈕回到之前的參照畫面，操作方式與 [返回] 按鈕相同。
</p>
<h4>在畫面內變更視圖</h4>
<p>變更畫面的視圖選項並不會變更 [上一層] 或 [返回] 的行為：畫面仍維持在應用程式階層中的相同位置，並不會建立新的導覽歷程記錄。
</p>
<p>這類視圖變更的範例如下：</p>
<ul>
<li>使用標籤和/或左與右滑動來切換視圖</li>
<li>使用下拉清單 (亦即折疊標籤) 切換視圖</li>
<li>篩選清單</li>
<li>對清單排序</li>
<li>變更顯示特性 (如縮放)</li>
</ul>
<h4>在同層級畫面間導覽</h4>
<p>當您的應用程式支援從項目清單導覽至項目之一的詳細視圖時，使用者通常會想使用方向導覽功能，以便從該項目導覽至清單中的前一個或後一個項目。

例如在 Gmail 中，可以很容易從會話群組向左或右滑動，方便檢視相同「收件匣」中的較新或舊會話群組。
就像在一個畫面中變更視圖時，這類導覽不會變更 [上一層] 或 [返回] 的行為。
</p>

<img src="{@docRoot}design/media/navigation_between_siblings_gmail.png">

<p>然而有一個明顯的例外是，在未與引用清單繫結在一起的相關詳細資料視圖之間瀏覽時 &mdash; 例如在 Play 商店中於相同開發者的不同應用程式之間瀏覽時，或是在相同演出者的專輯間瀏覽時。

在這些情況下，瀏覽每個連結都會產生歷程記錄，這會造成 [返回] 按鈕會經歷每個先前檢視過的畫面。
[上一層] 應該會繼續略過這些相關的畫面，並導覽到最近檢視過的容器畫面。
</p>

<img src="{@docRoot}design/media/navigation_between_siblings_market1.png">

<p>基於您對詳細資料視圖的瞭解，您有能力讓 [上一層] 行為甚至變得更聰明。
再延伸說明之前提及的 Play 商店範例，想像使用者已從最近檢視的「書籍」導覽至「電影」改編的詳細資料。
在這種情況下，[上一層] 可以返回到使用者之前沒有導覽過的上層容器 (電影)。
</p>

<img src="{@docRoot}design/media/navigation_between_siblings_market2.png">

<h2 id="into-your-app">透過「主螢幕小工具」和「通知」，導覽至您的應用程式</h2>

<p>您可以使用主螢幕小工具或通知，協助您直接導覽至深入您應用程式階層中的畫面。
例如，Gmail 的「收件匣」小工具和新郵件通知，都可以略過「收件匣」畫面，將使用者直接帶到會話群組檢視之中。
</p>

<p>針對這兩種情況，可以使用下列方式來處理 [上一層] 按鈕：</p>

<ul>
<li>如果目的地畫面通常是透過您應用程式中的一個特定畫面到達，那麼 [上一層] 應該要導覽至該畫面。<em></em>
</li>
<li>否則<em></em>， [上一層] 應該導覽至您應用程式的最頂端 (「主」) 螢幕。</li>
</ul>

<p>就 [返回] 按鈕而言，您應讓導覽更符合預期，方法是在工作的返回堆疊中，插入前往應用程式最頂端畫面的完整向上導覽路徑。
這可讓忘了如何進入您應用程式的使用者，能在退出之前導覽至應用程式的最頂端畫面。

</p>

<p>舉例來說，Gmail 的主螢幕小工具有一個按鈕，可以直接往下進入撰寫畫面。
來自撰寫畫面的 [上一層] 或 [返回] 按鈕，會將使用者帶到「收件匣」中，而此處的 [返回] 按鈕則可繼續前往至「主螢幕」。
</p>

<img src="{@docRoot}design/media/navigation_from_outside_back.png">

<h4>間接通知</h4>

<p>若應用程式必須同時呈現多個事件，可利用單一通知，引導使用者進入插頁畫面。
插頁畫面會概述所有事件，並提供讓使用者可以深入應用程式之中的路徑。
這種通知方式稱為<em>間接通知</em>。
</p>

<p>與標準 (直接) 通知不同的是，從間接通知的插頁畫面按下 [返回]，會讓使用者返回至通知觸發的起點 &mdash; 無其他畫面會插入至返回堆疊之中。

一旦使用者從插頁畫面繼續進入應用程式之後，[上一層] 與 [返回] 會如上所述，其行為就像針對標準通知一樣：在應用程式內導覽，而非返回插頁畫面。

</p>

<p>例如，假設 Gmail 中的使用者收到來自「行事曆」的間接通知。輕觸這個通知會打開插頁畫面，而此畫面會顯示數個不同事件的提醒。

從插頁畫面輕觸 [返回]，會讓使用者返回至 Gmail。輕觸特定事件會將使用者帶離插頁畫面，並進入完整的「行事曆」應用程式，顯示事件的詳細資料。

從事件詳細資料中，[上一層] 和 [返回] 會導覽至「行事曆」的最頂層視圖。</p>

<img src="{@docRoot}design/media/navigation_indirect_notification.png">

<h4>快顯通知</h4>

<p>快顯通知<em></em>會略過通知匣，直接出現在使用者面前。
這不常使用，<strong>應該要保留在需要適時回應，以及必須中斷使用者前後關聯動作的時候</strong>。
例如，Talk 就使用這種風格，用來提示使用者有朋友邀請加入視訊聊天，而且此邀請會在幾秒之後自動過期。

</p>

<p>就導覽行為而言，快顯通知緊接著間接通知插頁畫面的行為。
[返回] 會關閉快顯通知。如果使用者從快顯導覽進入通知應用程式，[上一層] 和 [返回] 會遵循標準通知的規則，只在應用程式內導覽。

</p>

<img src="{@docRoot}design/media/navigation_popup_notification.png">

<h2 id="between-apps">在應用程式間導覽</h2>

<p>Android 系統的主要優勢在於應用程式之間可彼此互連，使用者可從一個應用程式中直接導覽至另一個應用程式。
舉例來說，需要拍攝相片的的應用程式，可開啟「相機」應用程式，然後再返回原始參照應用程式中。

這項功能不僅使開發人員可輕鬆地利用其他應用程式的程式碼，還可讓使用者透過一致的作業方式享受常用功能。

</p>

<p>欲了解應用程式對應用程式的導覽行為，必須先了解以下介紹的 Android 架構行為。
</p>

<h4>Activity、工作和意圖</h4>

<p>在 Android 中，<strong>Activity</strong> 是一個應用程式元件，定義了資訊畫面，以及使用者可以執行的所有關聯動作。
您的應用程式是個 Activity 的集合，包括您可以建立及您能從其他應用程式重複使用的 Activity。
</p>

<p><strong>工作</strong>是使用者遵循以達到目標的一系列 Activity。單一工作可以利用來自單一應用程式的 Activity，或是汲取數個不同應用程式的 Activity。

</p>

<p><strong>意圖</strong>是指應用程式所發出想要另一套應用程式協助執行某動作訊號的機制。
應用程式的 Activity 可指示其可回應哪些意圖。
針對如「共用」等常見意圖，使用者可能已安裝許多可以滿足此要求的應用程式。
</p>

<h4>例如：在多個應用程式中導覽以支援共用功能</h4>

<p>要了解使用活動、工作和意圖如何相互作用，必須先考慮一個應用程式如何讓使用者利用另一個應用程式共用內容。
例如，在首頁中開啟 Play 商店應用程式，並開始工作 A (如下所示)。
使用者在 Play 商店應用程式中結束導覽後，輕觸促銷的書籍以查看細節，這時仍會停留在相同的工作中，同時新增活動以延伸功能。
觸發「共用」動作會提示使用者一個對話框，列出已註冊可用來處理「共用」意圖的每個 Activity (來自不同的應用程式)。

</p>

<img src="{@docRoot}design/media/navigation_between_apps_inward.png">

<p>當使用者選擇透過 Gmail 共用，Gmail 的撰寫 Activity 會被新增為工作 A 的延續 &mdash; 而不會建立新工作。
如果 Gmail 有本身的工作正在背景執行，這並不會影響該工作。
</p>

<p>從撰寫 Activity 中，傳送訊息或輕觸 [返回] 按鈕，會讓使用者返回至書籍詳細資料的 Activity。
繼續輕觸 [返回] 則會經由 Play 商店往回導覽，最終到達「主螢幕」。
</p>

<img src="{@docRoot}design/media/navigation_between_apps_back.png">

<p>然而，透過輕觸撰寫 Activity 的 [上一層]，代表使用者指明停留在 Gmail 的意願。
Gmail 的會話群組清單 Activity 會隨即出現，並針對該 Activity 建立一個新的工作 B。新工作的最後根源都是「主螢幕」，所以從會話群組輕觸 [返回] 會返回至該處。
</p>

<img src="{@docRoot}design/media/navigation_between_apps_up.png">

<p>工作 A 仍然存在背景之中，而使用者可能會在稍後返回 (例如，透過「最近使用記錄」畫面)。
如果 Gmail 在背景正在執行自己的工作，則其會被工作 B 取代 &mdash; 並捨棄之前的前後關係，而就使用者的新目標。
</p>

<p>當您的應用程式註冊來處理具有深入應用程式階層 Activity 的意圖時，請參考<a href="#into-your-app">透過主螢幕小工具和通知，導覽至您的應用程式</a>，取得如何指定 [上一層] 導覽的指導方針。

</p>