#iOS | #Android Fashion News

Compose と Navigation 3 が変えた ViewModel の役割

長年、Android 開発では一つの考え方が当たり前とされてきました。

画面の状態（State）は ViewModel に持たせる。

これは単なるベストプラクティスではなく、Android アーキテクチャの基本原則の一つでした。

ViewModel は Configuration Changes（画面回転など）でも破棄されず、さらに SavedStateHandle を使えば Process Death 後の状態復元もできます。

そのおかげで Activity や Fragment は UI を表示することに専念でき、画面の状態はすべて ViewModel が管理する、という設計が一般的になりました。

しかしここ数年で、この考え方は少しずつ変わり始めています。

Compose も Navigation 3 も ViewModel を不要にしたわけではありません。

代わりに、それぞれが 「本来その State を持つべき場所」 を用意するようになりました。

そこで、こんな疑問が生まれます。

Navigation 3 の時代でも、ViewModel は State Holder であるべきなのでしょうか？

 

🤔 以前の ViewModel は画面の State をすべて抱えていた

Compose が登場する以前は、多くの ViewModel が画面に関するほぼすべての状態を保持していました。

ViewModel
├── UI State
│   ├── text
│   ├── scrollPosition
│   ├── selectedTab
│   └── dialogState
│
├── Navigation State
│   └── screen arguments
│
└── Presentation Logic

この構成には多くのメリットがありました。

- Configuration Changes に強い
- Process Death 後も状態を復元できる
- Activity / Fragment をシンプルに保てる
- UI とビジネスロジックを分離できる

そのため、新しい State が増えたら、

とりあえず ViewModel に置く

という設計が自然になっていました。

 

🤔 Compose は UI State を UI に戻した

Jetpack Compose は、この考え方を少し変えました。

すべての UI State を ViewModel に持たせる必要はなく、Composable 自身が State を持てるようになったのです。

例えば検索文字列なら、

var query by remember {
    mutableStateOf("")
}

だけで十分です。

さらに Configuration Changes や Process Death を越えて保持したいなら、

var query by rememberSaveable {
    mutableStateOf("")
}

を使えます。

例えば次のような State は、

- TextField の入力内容
- 選択中のタブ
- 展開状態
- ダイアログの表示状態
- スクロール位置

どれも 純粋な UI State です。

ビジネスロジックではありません。

そのため、実際に使っている Composable の中に置く方が責務も分かりやすくなります。

Compose はまず、

「UI State は UI が持つ」

という考え方を広めました。

 

🤔 Navigation 3 はさらに一歩進めた

Navigation 3 は、この流れをさらに推し進めています。

まず、画面引数を SavedStateHandle 経由で受け渡す必要がなくなりました。

各画面は自分専用の NavKey を持ちます。

data class UserDetail(
    val userId: Long
) : NavKey

さらに Navigation 3 では rememberSerializable が追加されました。

rememberSaveable が Android の保存・復元機構を利用するのに対し、

rememberSerializable は NavEntry 単位 で UI State を保持します。

つまり、UI State は Navigation の Back Stack と一緒に移動するようになります。

画面ごとの State を ViewModel に保存する必要はなく、

各画面自身が UI State を持つ

という構造になります。

役割を整理すると次のようになります。

UI State
    │
rememberSerializable
    │
Composable


Navigation State
    │
NavKey


Presentation Logic
    │
ViewModel

UI State は UI のもの。

Navigation State は Navigation のもの。

どちらも、もう ViewModel が管理すべき State ではありません。

 

🤔 では ViewModel には何が残るのか？

UI State も Navigation State も ViewModel の役割ではなくなったとしたら、

ViewModel は何を担当するのでしょうか？

実は、やることはまだたくさんあります。

ViewModel
├── Repository の調整
├── ビジネスロジック
├── Flow の変換
├── Paging
├── Retry
└── viewModelScope

ここで面白いことがあります。

この中には、

State そのものはほとんどありません。

あるのは責務です。

ViewModel は

- Repository からデータを取得し
- ユーザー操作に応答し
- ビジネスロジックを実行し
- UI が描画しやすい形へ加工する

という役割を担います。

 

🤔 ViewModel は「State Holder」ではなく「State Producer」へ

例えば次のような ViewModel を考えてみます。

val uiState = combine(
    userRepository.users,
    settingsRepository.settings
) { users, settings ->
    HomeUiState(
        users = users,
        darkMode = settings.darkMode
    )
}.stateIn(...)

ここで実際の State はどこにあるでしょうか。

ViewModel ではありません。

データの正しい管理場所（Single Source of Truth）は Repository にあります。

ViewModel は、それらを UI 用に変換しているだけです。

つまり ViewModel は

State を保持する存在ではなく、State を生成する存在

になりつつあります。

一見小さな違いに思えますが、

Presentation Layer の考え方を大きく変える変化です。

 

🤔 State を持つ責任は、それぞれのレイヤーへ

Compose より前は、

ViewModel
├── UI State
├── Navigation State
└── Presentation Logic

という構成が一般的でした。

Navigation 3 では、

rememberSerializable
└── UI State

NavKey
└── Navigation State

ViewModel
└── Presentation Logic

へと役割が整理されます。

Compose は UI State を UI に戻しました。

Navigation 3 は Navigation State を NavKey に任せ、

UI State を NavEntry ごとに保持できるようにしました。

ViewModel が不要になったわけではありません。

責務がより明確になった のです。

 

🤔 よりシンプルなアーキテクチャ

その結果、アーキテクチャは次のように整理できます。

+----------------------+
|      Composable      |
|----------------------|
| UI State             |
| rememberSerializable |
+----------+-----------+
           |
           v
+----------------------+
|      ViewModel       |
|----------------------|
| Presentation Logic   |
| Flow Transformation  |
| Repository Calls     |
+----------+-----------+
           |
           v
+----------------------+
|      Repository      |
|----------------------|
| Persistent Data      |
| DataStore / Database |
+----------------------+

各レイヤーが、それぞれ最も適した責務を持ちます。

- Composable は UI State
- NavKey は Navigation State
- Repository は永続データ
- ViewModel は Presentation Logic

責務が自然に分離された構造です。

 

🧑🏻‍💻 まとめ

Navigation 3 が登場しても、ViewModel が不要になるわけではありません。

ViewModel はこれまでどおり、

- ビジネスロジック
- Repository の調整
- Flow の変換
- Paging
- 長時間動作する Coroutine

などを担当する最適な場所です。

一方で、Compose は rememberSaveable を導入し、UI State を UI に持たせやすくしました。

さらに Navigation 3 は rememberSerializable を追加し、UI State を NavEntry ごとに保持できるようにしました。また、Navigation State は NavKey が担当します。

その結果、「とりあえず ViewModel に State を置く」という設計は、必ずしも最適ではなくなりました。

これからは、

この State を ViewModel に保存するにはどうすればいいか？

ではなく、

そもそも、この State は ViewModel が持つべきものなのか？

と考える方が自然でしょう。

ViewModel は今でも欠かせない存在です。

しかし Navigation 3 の時代における主な役割は、State Holder ではなく Presentation Logic を担うことへと変化しつつあります。

なお、UI State を ViewModel の外へ移したからといって、Configuration Changes や Process Death に弱くなるわけではありません。

- UI State は rememberSaveable や rememberSerializable
- Navigation State は NavKey
- 永続データは Repository

というように、それぞれのレイヤーが適切な仕組みを使えば、Configuration Changes と Process Death の両方に対応した堅牢なアプリケーションを構築できます。

重要なのは State を保存することではなく、

「その State を最も自然に所有すべきレイヤーが管理すること」なのです。

 

🧑🏻‍💻 参考

Android アプリでボタンを素早く連打すると、同じ画面が何度も積み重なってしまうことがあります。

Home
  ↓
Detail
  ↓
Detail
  ↓
Detail

この問題を防ぐために debounce や throttle を使うケースは少なくありません。

しかし、Navigation 3 が提供する dropUnlessResumed は考え方がまったく異なります。

これは「一定時間タップを無視する」のではなく、画面が遷移できる状態かどうかを見てイベントを受け付ける API です。

 

🤔 debounce との違い

一見すると似ていますが、見ているものが違います。

つまり、

debounce
    ↓
「まだ500ms経ってないから無視」

dropUnlessResumed
    ↓
「この画面はもう操作できないから無視」

という違いがあります。

 

🤔 Navigationでは「時間」より「状態」が重要

画面遷移が始まると、現在の画面はすぐに RESUMED ではなくなります。

RESUMED
    │
ボタン押下
    │
navigate()
    │
STARTED
    │
STOPPED

この間にもう一度クリックされても、

dropUnlessResumed {
    navController.navigate(...)
}

であれば実行されません。

つまり、

クリック1回目
    ↓
navigate()

クリック2回目
    ↓
画面はもう RESUMED じゃない
    ↓
無視

となります。

 

🤔 なぜ debounce より自然なのか

例えば画面遷移アニメーションが長くなったとします。

debounce は

500ms待つ

という固定時間なので、

- アニメーションが300ms
- アニメーションが700ms

どちらにも最適とは限りません。

一方 dropUnlessResumed は

画面が操作可能
      ↓
受け付ける

画面遷移中
      ↓
受け付けない

戻ってきた
      ↓
再び受け付ける

と、Lifecycle に合わせて自動的に動作します。

 

🤔 内部では何をしているの？

実装は驚くほどシンプルです。

概念的には次のような処理です。

if (lifecycle.currentState == Lifecycle.State.RESUMED) {
    block()
}

つまり、

- 現在の Lifecycle を確認する
- RESUMED のときだけラムダを実行する

それだけです。

タイマーも、Coroutine も、待ち時間もありません。

 

🤔 Navigation 3 での使い方

Compose ではクリックイベントをそのまま包むだけです。

val onClick = dropUnlessResumed {
    navController.navigate(Detail)
}

Button(
    onClick = onClick
) {
    Text("Open")
}

これだけで、

- 二重 Push
- 二重画面生成
- 連打による BackStack の重複

を簡単に防げます。

 

🤔 debounce を使うべき場面

もちろん debounce が不要になったわけではありません。

例えば

- 検索ボックス
- API リクエスト
- テキスト入力
- リアルタイム検索

のように「連続イベントを間引く」目的なら debounce が適しています。

一方、

- Navigation
- Dialog を開く
- BottomSheet を表示する

など Lifecycle に依存する UI 操作では dropUnlessResumed の方が自然です。

 

🤔 まとめ

dropUnlessResumed は debounce の代替ではありません。

見る対象が時間ではなく Lifecycle だからです。

Navigation では「今この画面は操作可能か」が最も重要になります。

そのため Navigation 3 では、時間ベースの制御ではなく Lifecycle ベースの制御で二重遷移を防ぐ設計になっています。

一度仕組みを理解すると、「なぜ Navigation 用に専用 API が用意されているのか」がよく分かるはずです。

 

🤔 参考