現在、新しいAndroidナビゲーションアーキテクチャコンポーネント( https://developer.Android.com/topic/libraries/architecture/navigation / )。
私はその動機と概念とちょっと混乱しています、ここに私の不確実性があります:
質問2のシナリオ例:
理論的には、ナビゲーションライブラリは、使用する可能性のあるすべてのアーキテクチャをサポートします。箱から出して、アクティビティとフラグメントをナビゲーション先として処理できますが、独自のソリューションを 独自のナビゲーターを実装する でプラグインできます(例として、 この記事 を参照) 。
ただし、引用-から引用 ナビゲーションに関するGoogle I/Oトーク :
私のアクティビティは実際に何をするつもりですか?
現在、一部のアプリはアクティビティが非常に多いか、フラグメントが多いか、完全に別のシステムにあります。アクティビティは、アプリのコンテンツの所有者ではなく、アプリへの単なるエントリポイントであるモデルに向かっています。実際には、ナビゲーションドロワーやボトムバーなどのグローバルナビゲーションなど、グローバルな状態を保存するだけです。
したがって、Googleはアプリのアクティビティを2つだけにすることをお勧めします。これは、エントリポイントとして機能するために必要なアクティビティだけだからです。たとえば、ランチャーから開くものとディープリンクから開くものを用意できます。その後、アプリが起動すると、Fragmentsを使用してアプリ内の他のすべてを実行できます。
2つの質問を要約して直接回答するには:
ナビゲーションアーキテクチャコンポーネントは、それ自体「複数のアクティビティを使用する必要性を排除するように設計されている」わけではありませんが、それを使用するときにGoogleが推奨することです。
複数のアクティビティと複数のフラグメントを組み合わせて使用することもできます。必要に応じて、純粋にビューベースのナビゲーションで単一のアクティビティを使用することもできます。それはすべてあなた次第です。アプリの設計方法と組み合わせてナビゲーションライブラリが役立つ場合は、それを使用してください。
ライブラリのツールはカスタムの宛先にはそれほど優れていない場合があります(たとえば、ビジュアルエディターはおそらく当面はアクティビティとフラグメントのみをサポートするでしょう)、コードから好きなように使用できます。