Kotlin Flow を使って、UI State を宣言的に構築する
Jetpack Compose の ViewModel では、UI State を手動で管理し、init から load() を呼び出し、データが変わるたびに複数のプロパティを更新するコードをよく見かけます。
この方法でも問題なく動作します。しかし、アプリが複雑になるにつれて、複数の状態を同期させるためのコードが増え、管理が難しくなっていきます。
Kotlin Flow を使えば、もっと宣言的に UI State を構築できます。
Flow のオペレーターと stateIn を組み合わせることで、UI State がどの入力から、どのように導出されるのかをコードで表現できます。更新のたびに状態を手動で同期する必要はありません。
🤔 手動で UI State を管理するコスト
まずは、よくある ViewModel を見てみましょう。
class MyViewModel(
private val repository: MyRepository
) : ViewModel() {
private val _uiState = MutableStateFlow(UiState())
val uiState = _uiState.asStateFlow()
init {
load()
}
private fun load() {
viewModelScope.launch {
val items = repository.loadItems()
_uiState.update {
it.copy(items = items)
}
}
}
}
これは正当な実装です。一度だけデータを取得するような処理なら、理解しやすく、十分に実用的です。
ただし、ViewModel は次のような責務を担っています。
・ 初回ロードを開始する。
・ データ取得後に UI State を更新する。
・ 変更していないフィールドを保持する。
・ 入力が増えたときも、複数の状態の整合性を維持する。
画面が複雑になるほど、こうした処理が繰り返し必要になります。
では、Repository がすでに Flow でデータを公開している場合はどうでしょうか。Repository の Flow を手動で収集し、その値を別の StateFlow にコピーし続ける必要があるのでしょうか。
多くの場合、その必要はありません。
🤔 そもそも load() を呼ぶ必要はあるのか？
Jetpack Compose では、次のようなコードをよく使います。
LaunchedEffect(Unit) {
viewModel.load()
}
あるいは、ViewModel の init ブロックから呼び出します。
init {
load()
}
どちらも適切な場面があります。ユーザーが明示的に実行する更新処理や、一度だけ行う操作、特定のイベントに応じた処理には、明示的なコマンドが必要です。
しかし、画面が Flow で公開されたデータをそのまま表示するだけなら、手動でロードを開始し、UI State に反映させるための処理は不要かもしれません。
ここで重要なのは、コマンドと状態を区別することです。
・ コマンドは「何を実行するか」を表す。
・ 状態は「現在どうなっているか」を表す。
既存の Flow から UI State を導出できるなら、stateIn を使うことで、命令的な更新処理を減らせます。
🤔 stateIn で Flow を UI State に変換する
Repository が次のような Flow を公開しているとします。
interface MyRepository {
val items: Flow<List<Item>>
}
この場合、ViewModel は UI State を直接導出できます。
class MyViewModel(
repository: MyRepository
) : ViewModel() {
val uiState: StateFlow<UiState> =
repository.items
.map { items ->
UiState(items = items)
}
.stateIn(
scope = viewModelScope,
started = SharingStarted.WhileSubscribed(5_000),
initialValue = UiState()
)
}
何がなくなったでしょうか。
・ 同じ UI State を手動更新するための MutableStateFlow
・ 初回収集を開始するためだけの init ブロック
・ Repository の値をコピーするためだけの load() 呼び出し
・ Repository のデータと UI State を同期させる処理
コードは、データと UI State の関係を直接表現しています。
Repository Flow
|
v
map
|
v
UiState
|
v
stateIn
|
v
StateFlow<UiState>
|
v
Compose UI
Repository が新しいリストを発行すると、それに対応する UiState が生成されます。
stateIn は、上流の Flow をホットな StateFlow に変換し、最新の値を共有するとともに、初期値を提供します。
公式ドキュメントでも、この用途が説明されています。
👉 stateIn – Kotlin Programming Language
👉 StateFlow – Kotlin Programming Language
変更のたびに状態を同期する方法ではなく、状態がどのように導出されるのかをコードで宣言できるのです。
🤔 複数の入力から、一貫した UI State を導出する
このメリットは、画面が複数の入力に依存するときに、さらに明確になります。
例えば、検索機能のあるリスト画面を考えてみましょう。表示するアイテムは、Repository のデータと検索クエリの両方に依存します。
手動で状態を更新する場合、両方の変更を考慮して UI State を更新しなければなりません。
Flow なら、その依存関係を明示できます。
class MyViewModel(
repository: MyRepository
) : ViewModel() {
private val query = MutableStateFlow("")
val uiState: StateFlow<UiState> =
combine(
repository.items,
query
) { items, query ->
UiState(
items = items.filter {
it.matches(query)
},
query = query
)
}.stateIn(
scope = viewModelScope,
started = SharingStarted.WhileSubscribed(5_000),
initialValue = UiState()
)
fun onQueryChanged(query: String) {
this.query.value = query
}
}
ここで注目したいのは、UI アクションが更新するのは query だけだという点です。公開されている uiState を直接変更することはありません。
次のどちらが起きても、UI State は自動的に再計算されます。
・ Repository が新しいアイテムを発行する。
・ ユーザーが検索クエリを変更する。
表示リストを再計算する処理を、変更箇所ごとに書く必要はありません。
依存関係は combine の中で一度だけ定義されています。
Repository.items ──┐
├── combine ──> UiState
query ─────────────┘
|
v
stateIn
|
v
StateFlow<UiState>
この設計では、入力を変更する処理と、その入力から UI State を導出する処理が明確に分離されています。
🤔 コマンドは明示的に、状態は宣言的に
もちろん、すべての操作を Flow で表現すべきという意味ではありません。
フォームの送信、アイテムの削除、ユーザー操作に応じた明示的な再取得などは、ViewModel がコマンドとして処理する必要があるでしょう。
重要なのは、導出できる状態を同期するためだけに、命令的な処理を増やさないことです。
複数の観測可能な入力から UI State が決まるなら、map や combine で依存関係を表現し、UI に StateFlow を公開する必要がある場合は stateIn を使います。
設計上の役割を整理すると、次のようになります。
依存関係がコードに表れるため、状態がどこで、なぜ変わるのかを理解しやすくなります。
🤔 適切な Sharing Strategy を選ぶ
stateIn では、上流の Flow をいつ開始・停止するかを指定します。
よく使われる設定の一つが、次のものです。
SharingStarted.WhileSubscribed(5_000)
これは、最初の購読者が現れたときに上流の収集を開始し、最後の購読者がいなくなってから 5 秒後に収集を停止する設定です。
👉 stateIn – Kotlin Programming Language
5 秒の猶予があることで、画面遷移などによる短時間の購読解除で、上流の収集がすぐに停止・再開するのを避けられます。
ただし、次の2つは同じではありません。
・ Flow の収集が再開されること。
・ ネットワークリクエストが再実行されること。
画面が再表示されたときに API が再度呼び出されるかどうかは、上流の Flow がどのように実装されているかによります。
また、stateIn 自体がデータを取得するわけではありません。上流の Flow が発行した値を共有し、最新の状態として保持する仕組みです。
よく見かける設定をそのまま採用するのではなく、アプリのライフサイクルやデータ取得の要件に合わせて選びましょう。
🤔 MutableStateFlow が必要な場面もある
MutableStateFlow をなくすこと自体が目的ではありません。命令的に変更する必要がある入力には、引き続き有用です。
例えば、ユーザーが操作する検索クエリです。
private val query = MutableStateFlow("")
ユーザーの入力に応じて query を変更するのは自然な設計です。
一方、Repository のデータと検索クエリから導出できる uiState は、別の可変状態として保持する必要がありません。
実践的なルールは次のとおりです。
・ 入力には MutableStateFlow を使う。
・ Flow オペレーターで入力から状態を導出する。
・ stateIn で結果を StateFlow として公開する。
これは可変状態を排除する設計ではありません。可変性が必要な場所にだけ、それを配置する設計です。
🤔 まとめ：stateIn に状態管理を任せよう
stateIn は、Flow を StateFlow に変換するだけの便利なオペレーターではありません。map や combine と組み合わせることで、ViewModel の状態管理を宣言的に設計するための重要な手段になります。
データを手動で収集し、値をコピーし、関連するフィールドを同期する代わりに、入力と UI State の依存関係を直接表現できます。
特に、複数のデータソースから画面の状態が決まる場合に、そのメリットが大きくなります。
コマンドは明示的に。状態は宣言的に。
Flow で依存関係を定義し、適切な場面で stateIn を使って UI State を公開しましょう。
