Jetpack Composeで無理やりSharedFlowを監視したら失敗だった話【株式会社ライトコード】

はじめに

Jetpack Composeの導入、進んでいますか？

新規プロダクトなら「フルCompose」で気持ちよく開発できますが、歴史あるプロダクトや大規模なアプリでは、まだまだActivityやFragmentの遷移を残しつつ、
Viewの中身だけComposeに置き換えるというハイブリッドな構成で戦っている方も多いのではないでしょうか。

そんなActivity/FragmentとComposeが共存するハイブリッドな開発環境において、
「Activityのコードを減らしたい」「将来の完全Compose移行を考慮したい」という動機から、
SharedFlowをComposable内で処理しようとして
失敗してしまった経験を共有します。

やってしまった失敗実装

ViewModelからのワンショットイベント（SharedFlow）をComposable側で受け取るため、以下のような拡張関数を自作しました。

// Composable

@Composable

@SuppressLint("ComposableNaming")

inline fun  SharedFlow.collectWithLifecycle(

    lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,

    minActiveState: Lifecycle.State = Lifecycle.State.CREATED,

    collector: FlowCollector

) {

    LaunchedEffect(Unit) {

        lifecycleOwner.lifecycle.repeatOnLifecycle(minActiveState) {

            this@collectWithLifecycle.collect(collector)

        }

    }

}

実装イメージ（真似しないで）

これを使えば、Composable関数側でイベントハンドリングが完結するように見えます。

// Composable

@Composable

fun HogeScreen( // ActivityのsetContentで呼び出すComposable関数

    viewModel: HogeViewModel = hiltViewModel(),

    onNavigate: () -> Unit // Activity側ではstartActivityを呼び出す想定

) {

    // ViewModelのイベントを監視

    viewModel.navigateEvent.collectWithLifecycle {

        // イベントが来たらコールバックを実行（Activity遷移など）

        onNavigate()

    }

    

    // ... UIの実装

}

一見、とてもスマートに見えました。Activityのコードは減り、ロジックはComposableに寄る。
しかし、このアプローチは大きな間違いでした。

なぜ失敗だったのか

結論から言うと、SharedFlowだと監視外のイベントが喪失してしまうためです。
SharedFlowは、監視前に発火したイベントを拾えません。
（replayを使えば拾えますが、replay = 1などでキャッシュを持たせると、今度は「画面回転しただけでイベントが発火する」というバグを生み出します。）

なので基本的に
画面遷移直後に「トースト表示イベント」や「画面遷移のイベント」を発火したい。
という要件があっても
ライフサイクルが非アクティブ(Resumedじゃない)状態だとイベントを拾えません。

Android開発公式も「UIレイヤーでのワンショットイベント監視」はアンチパターンとしています。
https://proandroiddev.com/android-one-off-events-approaches-evolution-anti-patterns-add887cd0250
Composeは「宣言的UI」です。「イベントが起きたらどうする」ではなく、
「今の状態（State）はどうあるべきか」を記述するフレームワークです。