Navigation Compose

Navigation Compose の概念

Navigation Compose は、従来の Android の Navigation Component を Jetpack Compose 向けに最適化した仕組みです。

NavController を使って「どの画面を表示しているか」を管理する。

NavHost の中に複数の「ルート（画面パス）」を登録する。

navController.navigate("memo/123") のようにして画面を切り替える。

バックスタックが管理されるので、戻る操作や状態復元が自動でやりやすい。

つまり、**Composeアプリで公式に推奨されている「画面遷移と状態管理の仕組み」です。

Navigation Compose を導入する場合

メリット
公式推奨・拡張性が高い（複数画面が自然に扱える）。

戻る操作が自動管理される（バックスタック対応）。

引数付きの遷移が自然
（例：memo/{memoId} をルートにして、特定のメモを直接開く）。

他画面との連携が楽
（設定画面、検索画面などを追加する場合も同じ仕組みで統一できる）。

状態復元に強い（画面回転やプロセスキル後も再現しやすい）。

デメリット

学習コストがある
（NavHost・NavController の理解が必要）。

小規模アプリだとややオーバーエンジニアリング気味になる。

依存関係が増える
（androidx.navigation:navigation-compose が必要）。

------------------------------------------------
これに対してNavigation Composeを使わずに、例：MainScreen 内で状態切り替えする場合は、
when (uiState.currentScreen) {
Screen.Tree -> TreeScreen(...)
Screen.Memo -> MemoScreen(...)
}

メリット

シンプル
（追加ライブラリ不要、学習コストも低い）。

小規模アプリ向き
（画面が2〜3枚程度なら十分）。

状態を ViewModel に持たせれば一応問題なく動く。

デメリット

戻る操作を自前で管理する必要がある。

例：BackHandler { uiState.currentScreen = Screen.Tree } を書く。

引数付き遷移が面倒（例：memoId を持ち回る必要あり）。

画面が増えると複雑化しやすい。

バックスタックがないので、履歴的な遷移が必要になると破綻する。

なので

学習用や小規模
→ まずは MainScreen内の状態切り替えで十分。

将来的に画面が増える予定（設定、検索、タグ管理など）
→ 最初から Navigation Compose を導入しておく方が安心。

例えると、
Navigation Composeは「Android公式のしっかりしたルーターシステム」。
MainScreen 内の状態切り替えは「シングルファイルで頑張る簡易ルーター」。

といった感じです。