モダンな Android 開発において、Navigation はもはや単なる「画面の切り替え機」ではありません。

Destinationは、UIの状態やラベル、アイコンといったメタ情報を内包した、純粋な「型」として定義されるべきです。

ここでは、最新の Navigation ライブラリが目指す方向性に沿った、sealed interface による Destination 設計を提案します。

「シンプルさと拡張性」

このトレードオフをどう乗り越えるか、具体的なコード例と共に見ていきましょう。

 

🤔 共通の考え方：Destination = 型 + UIメタ情報

これまでの Navigation では String ベースの Route 管理が主流でしたが、これからの設計は

「型そのものに UI のメタ情報（ラベルやアイコンなど）を持たせる」

のが基本スタイルになります。

 

🤔 パターン 1：ネストする sealed interface

すべての Destination を一つの親インターフェースの中に閉じ込めるスタイルです。

実装イメージ

NavHost では AppDestination.xxx という形で指定します。

特徴

• ◎ 視認性： 全ての画面遷移先が 1 ファイルにまとまっており、全体像を把握しやすい。
• ◎ シンプル： 小〜中規模のアプリであれば、管理コストが最小限で済みます。
• △ 拡張性： 全てが AppDestination に依存するため、機能（Feature）ごとにモジュールを分割しようとすると、循環参照が発生しやすくなります。

 

🤔 パターン 2：ネストしない（トップレベル） sealed interface

インターフェースを定義しつつ、各 Destination は独立したクラスとして定義するスタイルです。

実装イメージ

NavHost での記述はよりフラットになります。

特徴

• ◎ 疎結合： 各 Destination を別ファイルや別モジュールに切り出しやすいため、Feature 単位の分割に強い。
• ◎ 大規模向き： チーム開発でコンフリクトを避けやすく、ビルド速度向上のためのマルチモジュール化にも適しています。
• △ 記述量： クラス名が重複しないよう xxxDestination と命名する必要があり、少し冗長に感じることがあります。

 

🤔 どちらを選ぶべきか？

設計の選択基準は非常にシンプルです。

 

🤔 まとめ

Navigation3 時代の Destination 設計の肝は
「型自体にメタ情報を持たせること」
です。

• とりあえず作り始めるなら「ネスト型」
• 将来的な機能拡張やモジュール化を見越すなら「非ネスト型」

アプリの規模と、将来どこまで成長させるかに合わせて選んでみてください。

Related Categories :  Android・dagger・Developmemt・JetpackCompose・Kotlin・Newbie・Recommended・Tools・Trending