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

page.title=Back と Up を使用したナビゲーション
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 では、全体的なナビゲーション動作が大きく変更されました。
注意深く Back と Up のガイドラインに従うことで、アプリのナビゲーションをユーザーにとって予測可能で信頼できるものにすることができます。
</p>
<p>Android 2.3 以前のアプリ内でのナビゲーションはシステムの <em>Back</em> ボタンを使って行われてきました。Android 3.0 よりアクションバーが導入され、第 2 のナビゲーション メカニズムとして <em>Up</em> ボタンが登場しました。このボタンはアプリアイコンと左向きのキャラットで構成されています。

</p>

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

<h2 id="up-vs-back">Up と Back</h2>

<p>Up ボタンは、画面間の階層関係に基づいてアプリ内を移動するために使います。
たとえば、画面 A がアイテムのリストを表示し、アイテムを選択すると（そのアイテムの詳細を表示する）画面 B に移動する場合、画面 B には画面 A に戻るための Up ボタンを用意する必要があります。

</p>
<p>画面がアプリの最上位（つまり、アプリのホーム）であれば、Up ボタンを表示すべきではありません。
</p>

<p>システムの Back ボタンはユーザーが最近使用した画面を、さかのぼって順番に移動する場合に使用されます。
通常このナビゲーションはアプリの階層ではなく、画面を表示した順番に基づいています。
</p>

<p>前に表示していた画面が現在の画面の親階層となる場合は、Back ボタンを押すとUp ボタンを押したときと同じ結果になります &mdash; これはよくある動作です。

ただし、Up ボタンではユーザーが確実にアプリ内に留まるのに対して、Back ボタンを使えばホームスクリーンに、さらには別のアプリに戻ることさえできます。
</p>

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

<p>Back ボタンは、画面間を直接ナビゲーションするだけでなく、次のような動作もサポートします。
</p>
<ul>
<li>フローティング ウィンドウ（ダイアログ、ポップアップ）を閉じる</li>
<li>コンテキスト アクションバーを閉じて、選択したアイテムのハイライト表示を解除する</li>
<li>オンスクリーン キーボード（IME）を非表示にする</li>
</ul>
<h2 id="within-app">アプリ内でのナビゲーション</h2>

<h4>複数のエントリ ポイントのある画面のナビゲーション</h4>
<p>画面にアプリ階層内の正確な位置がなく、アプリ内の他のどの画面からでもアクセスできる設定画面などのように複数のエントリ ポイントからアクセスできる場合があります。この場合、Up ボタンは参照元の画面に戻ることを選択する必要があります。これは Back も同様です。
&mdash;

</p>
<h4>画面内でビューを変更する</h4>
<p>画面のビュー オプションを変更しても Up と Back の動作は変わりません。画面はアプリの階層内の同じ位置に留まり、新しいナビゲーション履歴は作成されません。
</p>
<p>このようなビューの変更には次のようなものがあります。</p>
<ul>
<li>タブや左右のスワイプを使ってビューを切り替える</li>
<li>ドロップダウン（折りたたみタブ）を使ってビューを切り替える</li>
<li>リストにフィルタをかける</li>
<li>リストをソートする</li>
<li>表示の方法を変える（ズームなど）</li>
</ul>
<h4>兄弟画面間のナビゲーション</h4>
<p>アプリでアイテムのリストから 1 つのアイテム詳細画面に移動するとき、そのアイテムからリスト内の前後にある別のアイテムへのナビゲーションをサポートするのが望ましいことがよくあります。

たとえば、Gmail では、スワイプすることで、ある会話から同じ受信トレイの新しいまたは古い会話へ左右に簡単に移動できます。
画面内でビューを変更する場合と同じように、このようなナビゲーションによって Up または Back の動作は変わりません。
</p>

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

<p>しかし、参照リストで結び付けられていない関連詳細ビュー間をブラウジングする場合 &mdash; たとえば Play ストアで同じデベロッパーのアプリや同じアーティストのアルバム間をブラウジング場合、その動作はこれとは明らかに異なります。

この場合、各リンクをたどると履歴が作成され、Back ボタンで以前に表示した各画面に戻ることになります。
Up では常にこれらの関連画面をバイパスして、直前に表示したコンテナ画面に移動します。
</p>

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

<p>Up の動作を詳細ビューの知識に基づいてより使いやすくすることができます。
前述の Play ストアの例で、ユーザーが直前に表示した書籍から映画版の詳細に移動したとします。
その場合、Up でユーザーが前に表示していないコンテナ（映画）に戻ることができます。
</p>

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

<h2 id="into-your-app">ホームスクリーンのウィジェットと通知によるアプリへのナビゲーション</h2>

<p>ホームスクリーンのウィジェットや通知を使ってユーザーがアプリ階層内の深い階層にある画面に直接移動できるようにします。
たとえば、Gmail の受信ボックスのウィジェットと新しいメッセージ通知はどちらも受信トレイ画面をバイパスし、会話ビューを直接表示できます。
</p>

<p>この両方の機能で、Up ボタンを次のように処理します。</p>

<ul>
<li><em>通常アプリ内の特定の画面から移動先画面に移動する場合</em>、Up でその画面に移動します。
</li>
<li><em>それ以外の場合は</em>、Up でアプリの最上位（「ホーム」）画面に移動します。</li>
</ul>

<p>Back ボタンの場合は、アプリの最上位画面への完全な上向きナビゲーション パスをタスクのバックスタックに挿入してナビゲーションをより予測可能なものにする必要があります。
この設定によって、アプリにどのように入ったか忘れたユーザーは、終了前のアプリの最上位画面に移動できます。

</p>

<p>たとえば Gmail のホームスクリーンのウィジェットには、その作成画面に直接移動するボタンがあります。
作成画面の Up または Back で受信トレイが表示され、そこから Back ボタンでホームに移動します。
</p>

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

<h4>間接通知</h4>

<p>アプリで複数のイベントに関する情報を同時に表示する必要がある場合、1 つの通知を使ってユーザーをインタースティシャル画面に導くことができます。
この画面にはこれらのイベントがまとめてあり、アプリのさらに深い階層に移動するためのパスが示されます。このスタイルの通知を<em>間接通知</em>と呼びます。

</p>

<p>標準（直接）通知とは異なり、間接通知のインタースティシャル画面から Back を押すとユーザーは通知がトリガーされた地点に戻ります &mdash; バックスタックには追加の画面は挿入されません。

ユーザーがインタースティシャル画面からアプリに移動すると、Up および Back は前述した標準通知の場合と同様に動作します。つまりインタースティシャル画面に戻るのではなくアプリ内でナビゲーションします。

</p>

<p>たとえば Gmail のユーザーがカレンダーから間接通知を受け取ったとします。この通知をタップするとインタースティシャル画面が開き、複数の異なるイベントに関するリマインダーが表示されます。

インタースティシャル画面で Back をタップすると Gmail に戻ります。特定のイベントをタップすると、インタースティシャル画面から完全なカレンダー アプリに移動し、そのイベントの詳細が表示されます。

イベントの詳細から、Up および Back を使うとカレンダーの最上位ビューが表示されます。</p>

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

<h4>ポップアップ通知</h4>

<p><em>ポップアップ通知</em>は通知ドロワーをバイパスしてユーザーの前に直接表示されます。
ポップアップ通知はめったに使われません。<strong>タイムリーな応答が要求され、ユーザーのコンテキストの中断が必要な場合に使われます</strong>。
たとえばトークでは、このスタイルを使って友人からのビデオチャットへの参加に関する招待状についてユーザーに通知します。というのも、この招待状は数秒後に自動的に期限切れになるからです。

</p>

<p>ナビゲーション動作の点から、ポップアップ通知は間接通知のインタースティシャル画面の動作に厳密に従います。
Back でポップアップ通知は閉じます。ユーザーがポップアップから通知元のアプリに移動すると、Up と Back は標準通知のルールに従い、アプリ内でナビゲーションします。

</p>

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

<h2 id="between-apps">アプリ間のナビゲーション</h2>

<p>Android システムの基本的な利点の 1 つにアプリ同士がそれぞれをアクティブにできる機能があります。これによりユーザーは特定のアプリから別のアプリへ直接移動できます。
たとえば写真を撮影する必要があるアプリでは、カメラアプリをアクティブにすることができます。カメラアプリは写真を参照元のアプリに戻します。これはデベロッパーにとっては他のアプリのコードを簡単に利用できるという点で、またユーザーにとっては通常実行するアクションに対して一貫した操作を実行できるという点で大きなメリットです。



</p>

<p>アプリ間のナビゲーションを理解するには、次に説明する Android フレームワークの動作を理解することが重要です。
</p>

<h4>アクティビティ、タスク、インテント</h4>

<p>Android における<strong>アクティビティ</strong>とは情報の画面と、ユーザーが実行できるすべての関連アクションを定義するアプリケーション コンポーネントです。
アプリはアクティビティのコレクションで、作成したアクティビティと他のアプリから再利用するアクティビティの両方で構成されています。
</p>

<p><strong>タスク</strong>とは目標を実現するためにユーザーが従う一連のアクティビティです。1 つのタスクで 1 つのアプリだけのアクティビティを利用することも、複数のアプリのアクティビティを利用することもできます。

</p>

<p><strong>インテント</strong>とは、あるアプリがアクションの実行に関して別のアプリのサポートが必要であることを示すメカニズムです。
アプリのアクティビティでそれらのアプリが対応できるインテントを示すことができます。
「共有」などの一般的なインテントの場合、ユーザーはその要求を実現できる多くのアプリをインストールしている場合があります。
</p>

<h4>例: 共有をサポートするアプリ間のナビゲーション</h4>

<p>アクティビティ、タスク、インテントの連携を理解するには、1 つのアプリが別のアプリを使ってユーザーによるコンテンツの共有を可能にする仕組みを知る必要があります。たとえばホームから Play ストアのアプリを起動すると、新しいタスク A が開始されるとします（以下の図を参照）。

Play ストア内をナビゲートし、プロンプトで表示された書籍をタップしてその詳細を表示した後もユーザーは同じタスク内に留まり、アクティビティを追加するとタスクは拡張されます。
「共有」アクションをトリガーすると、共有インテントを処理するよう登録されている（さまざまなアプリの）各アクティビティを示すダイアログがユーザー表示されます。

</p>

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

<p>ユーザーが Gmail 経由で共有することを選択すると、Gmail の作成アクティビティがタスク A の続きとして追加されます &mdash; 新しいタスクは作成されません。
Gmail にバックグラウンドで実行中の独自のタスクがある場合、そのタスクは影響を受けません。
</p>

<p>作成アクティビティからメッセージを送信するか、Back ボタンをタップするとユーザーは書籍の詳細アクティビティに戻ります。
Back を連続してタップすると Play ストアに戻り、最終的にはホームが表示されます。
</p>

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

<p>ただし、作成アクティビティから Up をタップすると、ユーザーは Gmail 内に留まる意思を示すことになります。
Gmail の会話リストのアクティビティが表示され、新しいタスク B が作成されます。新しいタスクは常にホームをルートとしているため、会話リストからBack をタップするとホームに戻ります。
</p>

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

<p>タスク A はバックグラウンドで維持され、ユーザー後から（たとえば [最近使ったアプリ] 画面経由で）このタスクに戻ることができます。
Gmail にバックグラウンドで実行中の独自のタスクが既にある場合、そのタスクはタスク B に置き換えられます &mdash; 前のコンテキストはユーザーの新しい目標の導入より破棄されます。
</p>

<p>アプリがアプリ階層内の深い階層にあるアクティビティでインテントを処理するように登録されている場合は、Up ナビゲーションの指定方法について<a href="#into-your-app">ホームスクリーンのウィジェットと通知によるアプリへのナビゲーション</a>をご覧ください。

</p>