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">[上一層] vs.[返回]</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>活動、工作和意圖</h4>

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

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

</p>

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

<h4>範例：在應用程式間導覽，以支援共用</h4>

<p>要理解活動、工作和意向如何攜手合作，請思考應用程式如何讓使用者使用另一套應用程式來共用內容。例如，從「主」畫面啟動 Play 商店應用程式，開始新工作 A (見下圖)。

在導覽經歷 Play 商店，並輕觸一本促銷的書籍以查看詳細資料後，使用者仍會停留在相同工作中，並透過新增行為延伸工作。
觸發「共用」動作會提示使用者一個對話框，列出已註冊可用來處理「共用」意向的每個活動 (來自不同的應用程式)。

</p>

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

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

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

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

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

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

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

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

</p>