Compose State を Flow に変換する唯一の方法、それが snapshotFlow

snapshotFlow がなぜCompose専用に用意されているのか、その仕組みと実践的な使い方を紹介します。

Jetpack ComposeにはFlowを扱う機会が数多くあります。

Repositoryからデータを受け取るために Flow を collect したり、ViewModel が公開する StateFlowcollectAsState() したりすることは、すでに日常的なパターンになっています。

一方で、Compose State を逆に Flow へ変換したいと思ったことはないでしょうか。

例えば、

- スクロール位置を監視したい。
- 選択中のタブが変わったことを Analytics へ送信したい。
- TextField の入力を debounce() したい。
- Compose State を Flow の演算子で加工したい。

このような場面で登場するのが snapshotFlow です。

そして実は、Compose StateをFlowへ変換するCompose専用のAPIは snapshotFlow だけです。

 

🧑🏻‍💻 なぜflow {}ではダメなのか

最初に思い付くのは、普通の flow ではないでしょうか。


flow {
    emit(state.value)
}

もちろんこれは動きます。

しかし、一度値を送信するだけです。

その後 state.value が変化しても、新しい値は流れません。

なぜなら、flow {} はCompose Stateの変更を監視する仕組みを持っていないからです。

 

🧑🏻‍💻 snapshotFlow は Compose Snapshot を監視する

snapshotFlow は Compose の Snapshot システムと統合されています。


LaunchedEffect(Unit) {
    snapshotFlow {
        listState.firstVisibleItemIndex
    }.collect { index ->
        println(index)
    }
}

ラムダ内で読み取った Compose State を Compose 自身が監視し、

値が変化すると新しい値を Flow へ流します。

つまり、自分で emit() を書く必要はありません。

 

🧑🏻‍💻 イメージするとこうなる


Compose State
     │
     ▼
Compose Snapshot
     │
     ▼
snapshotFlow
     │
     ▼
  Kotlin Flow
     │
     ▼
map / filter / debounce / collect

Compose の世界と Flow の世界をつないでいるのが snapshotFlow です。

 

🧑🏻‍💻 Cold Flowであることも重要

snapshotFlow は Cold Flow です。

つまり、


val flow = snapshotFlow {
    state.value
}

これだけでは監視は始まりません。

実際に監視が始まるのは collect() された瞬間です。


LaunchedEffect(Unit) {
    snapshotFlow {
        state.value
    }.collect {
        // Side Effect
    }
}

そのため、Compose では LaunchedEffect と組み合わせて使うのが一般的です。

 

🧑🏻‍💻 実践例① スクロール位置を監視する

最もよく使われる例です。


LaunchedEffect(Unit) {
    snapshotFlow {
        listState.firstVisibleItemIndex
    }.collect(viewModel::onScrollChanged)
}

例えば、

- Toolbarの表示・非表示
- FABの表示切り替え
- Analytics送信

などに利用できます。

 

🧑🏻‍💻 実践例② Analyticsを送信する

Compose State の変化をイベントとして扱えます。


LaunchedEffect(Unit) {
    snapshotFlow {
        selectedTab
    }.collect(analytics::logTabSelected)
}

UIロジックを汚さず、副作用だけを分離できます。

 

🧑🏻‍💻 実践例③ Flow演算子を組み合わせる

snapshotFlow は通常の Flow なので、そのまま演算子を利用できます。


LaunchedEffect(Unit) {
    snapshotFlow {
        query
    }
        .debounce(300)
        .distinctUntilChanged()
        .collect(viewModel::search)
}

Compose Stateを、そのままリアクティブな Flow パイプラインへ接続できます。

 

🧑🏻‍💻 snapshotFlow が監視するのは Compose State だけ

重要なのは、監視対象はラムダ内で読み取ったCompose Stateだけという点です。


snapshotFlow {
    listState.firstVisibleItemIndex
}

このようなCompose Stateは監視できます。

一方、


var count = 0

snapshotFlow {
    count
}

通常の変数は Compose Snapshot が管理していないため、変更しても Flow は新しい値を流しません。

 

🧑🏻‍💻 まとめ

Compose にはさまざまな Flow API があります。

しかし、Compose State を Flow へ変換するために設計された Compose 専用 API は snapshotFlow だけです。

その役割は単に State を Flow へ変換することではありません。

Compose Snapshot とKotlin Flow を橋渡しし、

- スクロール監視
- Analytics
- TextField の入力監視
- Flow 演算子との連携

など、Compose で副作用を書くための基盤となるAPIです。

snapshotFlow を理解すると、「Compose State を Flowとして扱う」という考え方が自然になり、Composeらしい副作用の書き方が身に付くはずです。


Jetpack Composeで snapshotFlow の使いどころ

Jetpack Composeにおいて、Composeの「状態(State)」と「非ComposeのAPI(Flowなど)」を連携させたい場合に snapshotFlow が非常に有効です。

具体的には、以下のようなケースで使用します。

 

🧑🏻‍💻 1. Composeの状態変化をFlowとして監視したいとき

Composeの State オブジェクトの値が変化したタイミングで、何らかの副作用(Side-effect)を起こしたい場合に使用します。

コード例:TextFieldの入力値を監視して検索APIを呼ぶ


LaunchedEffect(textState) {
    snapshotFlow { textState.value }
        .debounce(300L) // 300ms入力が止まったら処理
        .distinctUntilChanged()
        .collect { query ->
            viewModel.search(query)
        }
}

 

🧑🏻‍💻 2. 非ComposeのAPIと値を同期させたいとき

Composeの管理外にあるライブラリやシステムAPIに対し、Compose側の状態の変化を伝えたい場合です。

コード例:スクロール位置をトラッキングツールへ送信


LaunchedEffect(listState) {
    snapshotFlow { listState.firstVisibleItemIndex }
        .filter { it > 0 }
        .collect { index ->
            Analytics.log("ScrollPosition", index)
        }
}

 

🧑🏻‍💻 3. 複雑な条件で「状態の変化」をトリガーにしたいとき

LaunchedEffect は状態が更新されるたびに毎回実行されますが、snapshotFlow を使うと、

Flowの演算子(filter, distinctUntilChanged など)を組み合わせる

ことで、「特定の値になったときだけ」といった細かい条件付けが容易になります。

 

🧑🏻‍💻 注意点:使うべきではないケース

すべての状態監視に snapshotFlow を使う必要はありません。

- 単純なUIの更新: 単にComposeのUIを再描画したいだけであれば、snapshotFlow を使わず、Composeの State をそのまま読み取ってUIを構成するのが最も効率的です。

- 計算処理: 高負荷な計算をFlowの中で行う場合は、適切なスレッド(Dispatchers.Defaultなど)で処理を行うよう注意が必要です。

 

🧑🏻‍💻 まとめ

snapshotFlow は、

「Composeのリアクティブな状態」を「Kotlin Flowの強力な演算子」とブリッジさせるためのツール

です。

「状態が変化した時に、何か別のアクション(通信、ログ記録、画面遷移など)を発生させたい」と考えたときが、この機能の使いどころです。

 

🧑🏻‍💻 参考


Jetpack Compose Navigation3 複数 NavBackStack 超シンプル実装

公式サンプルは複雑すぎない?

と思ったので。

 

🤔 実際のアプリはボトムナビゲーションをどう扱っているか

実装に入る前に、主要アプリの挙動を見てみましょう。

ほとんどのアプリは以下のどれかです:

- タブごとに独立した BackStack(最も一般的)
- 1つの共有 BackStack(最もシンプル)
- タブ切り替え時にリセット(常にルートに戻る)

 

🤔 バックボタンの挙動


タブ内の履歴

  ↓

タブのルート

  ↓

アプリ終了

- タブの切り替えは手動(バックボタンでは行わない)
- 各タブは独自の履歴を持つ
- 履歴が空になったらアプリを終了
- 同じタブを再度タップ → そのタブをルートにリセット
- タブ数は固定

 

🤔 考え方

タブをキーとした BackStack の Map を使う

これだけです。複雑な状態ホルダーは一切不要です。

 

🤔 主要コンポーネント

- NavKey
- NavBackStack
- NavigationBar / NavigationBarItem
- NavDisplay

 

🤔 ナビゲーションモデル


NavKey
└── TabRoot (エントリポイント)
     ├── Home
     ├── Search
     │    ├── Result (検索結果画面)
     │    └── Detail (検索詳細画面)
     └── Profile



@Serializable
sealed interface TabRoot : NavKey {
    val label: String
    val selectedIcon: ImageVector
    val unselectedIcon: ImageVector

    companion object {
        val entries = listOf(Home, Search, Profile)
    }
}

@Serializable
data object Home : TabRoot {
    override val label = "Home"
    override val selectedIcon = Icons.Filled.Home
    override val unselectedIcon = Icons.Outlined.Home
}

@Serializable
data object Search : TabRoot { ... }

@Serializable
data object Profile : TabRoot { ... }

@Serializable
data class Result(val keyword: String) : NavKey

@Serializable
data class Detail(val id: String) : NavKey

なぜこれがうまくいくか

- 単一の型安全なナビゲーションモデル
- タブと画面が同じシステムを共有
- @Serializable で状態復元が可能
- sealed + object でコンパイル時安全性

 

🤔 状態管理

1. 選択中のタブ


var currentTab by rememberSerializable {
    mutableStateOf<TabRoot>(Home)
}


var currentTab by rememberSerializable {
    mutableStateOf<TabRoot>(Home)
}

2. 複数の NavBackStack


val stacks = TabRoot.entries.associateWith { root ->
    rememberNavBackStack(root)
}

重要なポイント
- Map は再コンポーズごとに再作成されが生成コストは小さい
- しかし各 NavBackStack 維持されて再作成されない

これで安全かつシンプルに実現できます。

3. 現在の NavBackStack


val currentStack = stacks[currentTab]!!

Compose では currentTab が変わると自動的に更新されます。

4. タブ切り替え


onClick = {
    currentTab = root
}

これだけです。

5. 画面遷移(Push)kotlin


onClick = {
    currentStack.add(Result(keyword))
}

6. 戻る操作(Pop)


NavDisplay(
    onBack = {
        currentStack.removeAt(currentStack.lastIndex)
    }
)

- ルートを削除しようとしたらアプリ終了(Android 標準挙動)

7. 同じタブを再度タップしたときのリセット


if (selected) {
    currentStack.clear()
    currentStack.add(root)
}

- Instagram や Twitter(X)と同じ挙動になります。

 

🧑🏻‍💻 最終的な最小パターン


var currentTab by rememberSerializable {
    mutableStateOf<TabRoot>(Home)
}

val stacks = TabRoot.entries.associateWith { root ->
    rememberNavBackStack(root)
}

val currentStack = stacks[currentTab]!!

 

🚀 このアプローチが優れている理由

- コード量が最小
- 実際のアプリ挙動にマッチ
- 完全に Compose ネイティブ
- 将来的に拡張しやすい
- Process Death 後も完全な状態復元が可能

というかんじでどうでしょうか。

 

🚗💨 参考


Jetpack Compose のワンタイムイベントで SharedFlow をやめて Channel にした理由

Jetpack Compose で Snackbar、Navigation、Toast のような「一度だけ処理したいイベント」をどう扱うかは、多くの Android エンジニアが一度は悩むポイントです。

私も長い間 SharedFlow を使っていました。

しかし最終的には、Compose の UI イベント用途では Channel を使うようになりました。

この記事では、

- なぜ SharedFlow で問題が起きやすいのか
- なぜ Channel の方が自然だったのか
- Compose のライフサイクルと何が噛み合わないのか

を整理してみます。

 

🧑🏻‍💻 One-Time Event とは?

まず前提として、Compose には大きく 2 種類のデータがあります。


State
└─ 画面が「今どういう状態か」

Event
└─ 一度だけ実行したいもの

例えば:

State は「現在値」が重要です。

しかし Event は違います。

「発生した」という事実だけ重要

つまり:

- 1回だけ消費したい
- 再購読時に再実行したくない
- 画面回転で再発火したくない

という特徴があります。

 

🧑🏻‍💻 SharedFlow を使っていた頃

最初は多くのサンプルと同じように SharedFlow を使っていました。


private val _event = MutableSharedFlow<UiEvent>()
val event = _event.asSharedFlow()

UI 側では:


LaunchedEffect(Unit) {
    viewModel.event.collect { event ->
        when (event) {
            is UiEvent.ShowSnackbar -> {
                snackbarHostState.showSnackbar(event.message)
            }
        }
    }
}

一見すると問題なさそうです。

しかし実運用では、徐々に違和感が出てきました。

 

🧑🏻‍💻 Collector がいないとイベントが消える

SharedFlow(replay = 0) は、

購読者がいない時のイベントを保持しません

つまり:


ViewModel emits event
        ↓
Compose がまだ collect 開始していない
        ↓
イベント消失

が起きます。

特に Compose では:

- 画面遷移直後
- Lifecycle 切り替え
- BackStack 復帰
- 一時的な recomposition

などで collector の開始タイミングがズレやすいです。

 

🧑🏻‍💻 replay = 1 にすると今度は別問題

では replay = 1 にすれば良いのでしょうか?


MutableSharedFlow(
    replay = 1
)

これは確かにイベント消失を防ぎます。

しかし次は:

画面回転したら
昔のイベントが再配信される問題が発生します。

例えば:


Snackbar 表示
↓
画面回転
↓
Snackbar 再表示

これは UX 的にかなり不自然です。

Navigation だとさらに危険です。

画面回転しただけで
再度 navigate される

ことがあります。

 

🧑🏻‍💻 SharedFlow は「共有ストリーム」

ここで改めて考えると、SharedFlow は本来:

複数 collector に
同じデータを共有する

ための仕組みです。

つまり設計思想としては:

- 状態通知
- Broadcast
- Hot stream

寄りです。

一方 One-Time Event は:

- 1回だけ消費したい

なので、実は思想が少しズレています。

 

🧑🏻‍💻 Channel に変えた

そこで最終的にこうなりました。


private val _event = Channel<UiEvent>(
    capacity = Channel.BUFFERED
)

val event = _event.receiveAsFlow()

送信:


viewModelScope.launch {
    _event.send(
        UiEvent.ShowSnackbar("Saved")
    )
}

受信:


LaunchedEffect(Unit) {
    viewModel.event.collect { event ->
        when (event) {
            is UiEvent.ShowSnackbar -> {
                snackbarHostState.showSnackbar(event.message)
            }
        }
    }
}

 

🧑🏻‍💻 なぜ Channel の方が自然だったのか

Channel は:

Queue

です。

つまり:


送る
↓
溜まる
↓
1個ずつ消費

になります。

これは One-Time Event の性質にかなり近いです。

特に:

- Snackbar
- Navigation
- Dialog
- Toast

のような

順番に1回だけ処理したい

イベントと相性が良いです。

 

🧑🏻‍💻 BUFFERED が重要

Compose では collector が少し遅れて開始することがあります。

そのため:

Channel.BUFFERED

を使うことで、

collector 開始前のイベント

もある程度保持できます。

これは SharedFlow(replay = 0) よりかなり扱いやすく感じました。

 

🧑🏻‍💻 ただし Channel にも注意点はある

もちろん Channel が万能ではありません。

特に重要なのは:

基本的に single consumer 前提

である点です。

つまり:

複数 collector が同時に collect

すると、どこが消費するか不定になります。

そのため:

UI Event 専用

として割り切るのが重要です。

 

🧑🏻‍💻 個人的な使い分け

現在は大体こう整理しています。

かなり安定しました。

 

🧑🏻‍💻 Compose では「State」と「Event」を分けるのが重要

Compose は State 管理が非常に強力です。

しかしその反面、

Event を State と同じ感覚で扱う

と事故りやすいです。

特に:

- Snackbar
- Navigation
- Dialog
- Permission request

などは:

状態ではなく副作用

として考えた方が整理しやすいです。

 

🧑🏻‍💻 まとめ

SharedFlow は優秀ですが、

One-Time Event に完全最適

とは限りません。

Compose のライフサイクルと組み合わさると:

- イベント消失
- replay 問題
- collector timing 問題

に遭遇しやすいです。

一方 Channel は:

FIFO queue

として動作するため、

- 一度だけ処理したい
- 順番保証したい
- 再配信したくない

という UI Event とかなり自然に噛み合いました。

最近は:

State は StateFlow
Event は Channel

という形に落ち着いています。

 

🤔 参考


Androidアーキテクチャの現状:GoogleのUDFと現実世界の「MVI風MVVM」の比較

現代のAndroid開発においてどのアーキテクチャを採用するかを議論する際、議論はほぼ常にMVVM対MVIのどちらにするかという点に集約されます。

しかし、近年の傾向を見ると、この2つは対立する力ではなく、収束しつつあることは明らかです。

 

🧑🏻‍💻 Googleの立場:特定のパターン名よりもUDFを優先

Googleの公式「アプリアーキテクチャガイド」を詳しく見てみると、「MVI」という用語はほとんど出てこないことに気づくでしょう。その代わりに、Googleは一貫してUDF(単方向データフロー)という概念を推奨しています。

Googleは、コミュニティに既に馴染みのある「MVI」ではなく、なぜ抽象的な用語である「UDF」を使用するのでしょうか?

その理由は、Googleが柔軟性を重視していることにあり、彼らの哲学は次のようなものと思われます。

「MVIのような厳格な命名規則にとらわれすぎないでください。アーキテクチャの本質である一方向のデータフローが維持されるようにするだけで十分です。」

Reduxのような厳密な状態管理ライブラリを使用する場合でも、シンプルなViewModelで実装する場合でも、Googleが重視するのは「状態は下へ流れ、イベントは上へ流れる」という基本原則に従うことです。

 

🧑🏻‍💻 現代の標準:MVI風MVVMの実装

現場では、Googleが推奨するUDFに対する最も一般的なアプローチは、私が「MVI風味のMVVM」と呼ぶもので、MVIルールをMVVMコンテナに詰め込むものです。これには、状態、意図、効果という3つのコア要素が含まれます。

実際には以下のようになります。