はじめに
Principles of Navigation(Navigationの原則)を一度読んでみたほうが良さそうと思って読んでみた時のメモというか翻訳です。
Principles of Navigation(Navigationの原則)
アプリ内ナビゲーションの目標は、ユーザーに一貫した予測可能なエクスペリエンスを提供することです。この目標を達成するために、ナビゲーションアーキテクチャコンポーネントは、以下の各ナビゲーション原則に準拠したアプリを構築するのに役立ちます。
アプリは決まった最初の遷移先がある
アプリにはユーザーがランチャーからアプリを起動したときに見る決まった遷移先の画面があります。この遷移先は、戻るボタンを押した後、ランチャーに戻るときの最後に表示される画面になるはずです。
注意: アプリに1回限りの設定や一連のログイン画面がある可能性があります。これらの条件付き画面は、アプリの最初の遷移先とみなすべきではありません。
スタックは、アプリの「ナビゲーション状態」を表すために使用
アプリのナビゲーション状態は、LIFO(後入れ先出し構造)で表される必要があります。 この「ナビゲーションスタック」は、スタックの一番下にアプリの最初の遷移先があり、スタックの一番上に現在の遷移先があるはずです。
ナビゲーションスタックを変更する操作は、新しい遷移先をスタックの先頭に「プッシュ」するか、最上部の遷移先をスタックから「ポップ」することによって、常にナビゲーションスタックの一番上で操作する必要があります。
Upボタンはアプリを終了させない
ユーザーが最初の遷移先にいる場合は、Upボタンを表示すべきではありません。他のアプリのタスク上でディープリンクを使用してアプリを起動すると、Upボタンは階層的に親の遷移先に戻り、他のアプリに戻るべきではありません。
UpボタンとBackボタンはアプリのタスク内で同等
自分のアプリのタスク上にいて最初の遷移先にいないときのような、システムのバックボタンがアプリを終了しない場合、Upボタンはシステムのバックボタンと同等に機能すべきです。
ディープリンクで遷移する場合や通所の遷移で同じ同じ遷移先への遷移する場合、同じスタック状態となるべき
ユーザーは最初の遷移先でアプリに入って、別の遷移先に遷移します。また同じ遷移先に遷移するために、可能ならディープリンクも使います。 両方のケースで、ナビゲーションスタックは遷移先が同じスタック状態になるべきです。 特に、ユーザーは、どのように遷移先に到達したかにかかわらず、バックボタンやUpボタンを使って、最初の遷移先まで戻れるべきです。 既存のナビゲーションスタックは削除され、ディープリンクのナビゲーションスタックに置き換えられます。
翻訳について
- Destination
- 遷移先
- ※DestinationはNavigationにおいて、画面の意味があるので、
遷移先の画面
としてしまおうかと思ったり、Destination
のままにしようかと悩みましたが、遷移先
に統一しました。
- ※DestinationはNavigationにおいて、画面の意味があるので、
- 遷移先
- start destination
- 最初の遷移先
- ※Navigationにおいて、アプリ起動時の画面を意味しています。また
開始先
のような訳も考えましたが、上記Destinationを遷移先
としたので、最初の遷移先
としました。
- ※Navigationにおいて、アプリ起動時の画面を意味しています。また
- 最初の遷移先
- navigation stack
- ナビゲーションスタック
- Previous
GitHub PagesのカスタムドメインがHTTPSをサポートしたのでメモ - Next
Google I/O 2018 に初めて行ってきた。(2018/05/04pst日本からSan Franciscoへ)