BackとUpナビゲーション
一貫したナビゲーションは全体的なユーザーエクスペリエンスで重要な要素です。調和せず予測不可能な手法はユーザーをイライラさせます。
Android3.0は全体的な操作に付いて重要な振る舞いの変化をもたらしました。
BackとUpのガイドラインを意識し従う事でアプリの操作をユーザーが予想できて信頼できるようにします。
Android2.3以前はアプリの範囲内での操作においてシステムのBackキーに依存していました。
Android3.0のアクションバーの導入で２つ目の操作の仕組みとしてアプリアイコンと左の印からなるUpボタンが加わりました。
Up vs Back
画面間の階層に基づくアプリ内の操作でUpボタンが使用されます。例えば、画面Aがアイテムのリストを表示し、アイテムを選択する事で（アイテムの詳細を表示する）画面Bに行くならば、その場合画面Bは画面Aに戻るUpボタンを提供する必要があります。
もし、画面がアプリの最上位（すなわちアプリのホーム）であればUpボタンを表示してはいけません。
システムの戻るボタンはユーザーが最近見た画面の順に基づいて操作するために用いられます。
前回見た画面が階層上でも現在の画面の親にあたる時はBackキーを押すのとUpボタンは同じ結果になります。
これはよくある事です。
しかし、Upボタンがアプリ内に留まるのが確実であるのに対して、Backキーはホームスクリーンや異なるアプリにすらも戻す事が出来ます。
Backキーは画面から画面へ直接ナビゲーションするだけでないいくつかの動きもサポートします
・Backはフローティングウィンドウ（ダイアログやポップアップ）を取り除きます。
・Backはコンテキストアクションバーを取り除き、選択されたアイテムからハイライトを外します。
・Backはソフトキーボード(IME)を非表示にします。
あなたのアプリのナビゲーション
複数のエントリーポイントをもつ画面のナビゲーション
まれに、画面がアプリの階層における厳格な位置を持たず、例えば、アプリ内のどの画面からもたどり着ける設定画面のように複数のエントリーポイントから入れる事があります。この場合、Upボタンは参照している画面を選んで戻る必要があります。Backキーと同様の動きです。
画面内でビューをかえる
画面でビューのオプションを変えることはUpとBackに影響しません。画面はアプリ階層において同じ場所にあります。そして新しい操作履歴は作られません。
そのようなビューの変更の例は以下の通りです。
・タブや左右のスワイプを使ったビューの切り替え
・ドロップダウンを使ったビューの切り替え（別名折り畳みタブ）
・リストのフィルター
・リストのソート
・見せ方を変える（例えばズーム）
兄弟画面の間でナビゲーション
アプリがアイテムのリストから１つのアイテム詳細画面へ移動するとき、多くの場合において、リストの前後方向にある別のアイテムへナビゲーションをサポートする事が望ましいです。
例えばGmailはConversationビューで左右にスワイプする事で同じInboxにある会話のより新しいか、古い内容へ簡単に行けます。
ビューを変える時、ナビゲーションはUpまたはBackの動きに作用しません。
しかしながら、注目すべき例外は、 元のリストに結びつかない関連した詳細ビュー間の移動です。
例えば、Marketで同じ開発者のアプリや同じアーティストのアルバムを選んだ場合。
この場合、関連の各スクリーンを辿るたびに履歴を残し、Backボタンで辿る事になります。
Upはこれらの関連したスクリーンは辿らずに、常に最近見たコンテナ画面に移動されなければ行けません。
詳細画面の情報に基づきUpの動きをもっとスマートに出来ます。
Marketのサンプルを拡張するなら、本から映画に関連する詳細ビューに移動した場合を考えてみます。
この場合、ユーザーは辿った事が無いコンテナー（映画）へとUpは戻れます。
アプリ外から辿ってきたとき
深いアプリ階層へアプリ外から辿ってくるのには２つの場合があります。・intentの受け渡しなど等アプリからアプリへのナビゲーション
・通知やホームスクリーンウィジェット等によるシステムからアプリへのナビゲーション
Gmailがこれらの例を示します。
アプリからアプリへのナビゲーションについて、共有intentによって直接Compose画面が開きます。
システムからアプリへのナビゲーションについて、新メッセージの通知とホームスクリーンウィジェットはInboxスクリーンを飛び越えて直接conversation画面へ行きます。
アプリからアプリへのナビゲーション
Intentを通してあるアプリから直接あなたのアプリの深い階層にナビゲーションされたとき、Backは見ているアプリへ戻ります。Upボタンについて：辿り着く画面がアプリ内において典型的な参照元があるなら、Upはその画面へナビゲーションしなければいけません。
そうでなければUpはアプリの一番上（アプリのホーム）画面にナビゲーションしなければ行けません。
例えばMarketのビューにおいて本を共有するを選択するとユーザーは直接Gmailのcompose画面へ進みます。
UpはInbox(偶然ですがこれは典型的な参照元であるとともにアプリの一番上の画面です。)に戻ります。Backはマーケットに戻ります。
システムからアプリへのナビゲーション
通知やホームスクリーンウィジェットによってシステムからアプリに辿り着くなら、Upは上記の「アプリからアプリへのナビゲーション」で説明したのと同様に振る舞います。Backキーでは、アプリの最上位画面への完全なナビゲーションのパスをBack stackに挿入する事でより予測する動きをしなければ行けません。
こうすることで、ユーザーがアプリでどのように辿るか忘れた場合でも、そこから出る前にアプリの一番上のスクリーンへ問題なく操作する事が出来ます。
例えばGmailのホームスクリーンウィジェットは直接compose画面に行くためのボタンがあります。
その経路できたあと、１度目のBackキーはInboxに戻り、続けてホームへと戻ります。
次へ
前へ
目次に戻る
原文
Except as noted, this content is licensed under Creative Commons Attribution 2.5.