Jetpack Compose で開発をしていると、必ず直面する問いがあります。
「これは State として保持すべきか、それとも Effect（副作用）として処理すべきか？」
という問題です。
Compose の宣言的 UI パラダイムにおいて、この境界線を曖昧にすると、画面回転時の二重トーストや、意図しない画面遷移といったバグを招きます。
本記事では、その明確な使い分けと、イベント制御における Kotlin Channel の有効性について解説します。
🧑🏻💻 1. 「状態 (State)」と「副作用 (Effect)」の本質的な違い
使い分けの基準はシンプルです。
「そのデータは、UI のスナップショットの一部か？」
と自問してください。
State：UI の「今」を表すもの
State は、再構成（Recomposition）によって何度読み込まれても同じ結果を示すべきものです。
- 例: テキストフィールドの入力値、読み込み中フラグ、リストデータ
- 性質: 保持（Retention）
Effect：UI の「外」で起きる一回きりのこと
Effect は、Compose のレンダリングサイクルとは独立して実行される処理です。
- 例: ログ出力、アナリティクス送信、タイマーの開始
- 性質: 実行（Execution）
🧑🏻💻 2. ワンショットイベントの罠：StateFlow vs Channel
ここで問題になるのが、トースト表示や画面遷移のような「一度だけ実行したいアクション」です。
これらを StateFlow で管理しようとすると、Android 特有のライフサイクル問題にぶつかります。
StateFlow の限界
StateFlow は常に「最新の状態」を保持します。
1. エラーが発生し、State を ErrorMessage("Failed") に更新。
2. UI がそれを検知してトーストを表示。
3. ここで画面を回転させる。
4. 新しい Activity が StateFlow を購読し、最新の "Failed" を再び受け取ってしまう。
5. トーストが二重に表示される。
これを防ぐために「フラグを戻す」処理を挟むのは、シンプルではありません。
🧑🏻💻 3. Channel は「消費されるイベント」に最適である
そこで登場するのが Channel です。Channel は、「土管」のような振る舞いをします。
- 一度きりの配送: 誰かがイベントを受け取った（消費した）瞬間、そのイベントは Channel から消えます。
- 画面回転に強い: 新しい Activity が再購読しても、古いイベントは既に消費されているため、二重実行は発生しません。
- バッファの活用: Channel.BUFFERED を使うことで、アプリがバックグラウンドにいる間に発生したイベントも、フォアグラウンドに戻った瞬間に安全に処理できます。
🧑🏻💻 4. 実装のベストプラクティス
私のプロジェクトでは、以下のような棲み分けを徹底しています。
// ViewModel
// UI の状態（表示データ）
private val _uiState = MutableStateFlow(UiState())
val uiState = _uiState.asStateFlow()
// UI へのイベント（ワンショット）
private val _eventChannel = Channel<UiEvent>(Channel.BUFFERED)
val events = _eventChannel.receiveAsFlow()
// UI (Compose)
LaunchedEffect(Unit) {
viewModel.events.collect { event ->
when (event) {
is UiEvent.ShowSnackbar -> snackbarHostState.showSnackbar(event.message)
is UiEvent.NavigateToDetail -> navController.navigate("detail")
}
}
}
🧑🏻💻 まとめ
- 永続的な見た目に関わるなら State (StateFlow)。
- 一過性の挙動に関わるなら Effect (Channel)。
複雑なフラグ管理でコードを汚す前に、ツールが持つ「自然な性質」を利用しましょう。
Channel を使うことは、Compose におけるイベントハンドリングを最もシンプルにする考え方の一つです。
