イベントをどう管理するか

イベントをどう管理するか Shibuya.apk #50 mikan(一瀬喜弘)

自己紹介 object Mikan { val name = 一瀬喜弘 val from
= 長崎 val company = カラビナテクノロジー株式会社 val work = Engineer.Android val volunteer = DroidKaigi val hobby = listOf( "漫画", "アニメ", "ゲーム", "折り紙", "OSS開発・コントリビュート", ) }

今日お話しする内容

Channel vs. SharedFlow vs. StateFlow エラーや通信結果などのイベントをどこで管理するのか

結論エラーや通信結果などのイベントをどこで管理すべきか？

それぞれのメリデメを把握したうえで適当なものを選んでください

どれを使うかは所詮手段でしかないです取り扱おうとしているイベントの重要度だったり、どうハンドリングされるかをきちんと
把握しないと適切なホルダーは選べません

これからメリデメを紹介するので、適した手段を検討できるようになってもらえれば幸いです

イベントとは

イベントとはユーザー操作によってUI側から発生し、ViewModelに伝達したい情報

けど ViewModelから UIにイベントを送信したいときもありますよね

ex. 1. 通信が完了したら画面遷移する 2. 通信が失敗したらエラーダイアログを表示する 3. SharedPreferencesからデータを削除したらトーストを表示する

ViewModelから UIにイベントを伝達するためにはなにかしらデータホルダーが必要になる

Channel? SharedFlow? StateFlow? 戦争が始まる

それぞれについて実装方法をみていきます

Channel データの持ち方イベントの発火 // ViewModel private val _message = Channel<String>()
val message = _message.receiveAsFlow() viewModelScope.launch { _message.send("message...") }

Channel イベントの消費 // Fragment viewLifecycleOwner.lifecycleScope.launch { viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect {
showSnackBar(it) } } }

Channel イベントの消費 // Compose val lifecycle = LocalLifecycleOwner.current.lifecycle LaunchedEffect(Unit) {
lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { showSnackBar(it) } } }

Channel メリット collectorがいない間に発生したイベントをバッファリングできる(demo) デメリットイベントの消費中に coroutine がキャンセルされたらどうしますか？
(demo)

Channel メリット collectorがいない間に発生したイベントをバッファリングできる(demo) デメリットイベントの消費中に coroutine がキャンセルされたらどうしますか？
(demo) → バッファリングの挙動とバックグラウンド時のキャンセルが絡み合うとイベントハンドリングの振る舞いがどんどん予測困難になる

SharedFlow データの持ち方イベントの発火 // ViewModel private val _message = MutableSharedFlow<String>()
val message = _message.asSharedFlow() viewModelScope.launch { _message.emit("message...") }

SharedFlow イベントの消費 Channelのときと同じ // Fragment viewLifecycleOwner.lifecycleScope.launch { viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect
{ showSnackBar(it) } } }

SharedFlow イベントの消費 Channelのときと同じ // Compose val lifecycle = LocalLifecycleOwner.current.lifecycle LaunchedEffect(Unit)
{ lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { showSnackBar(it) } } }

SharedFlow メリットデメリットに目を瞑れば、シンプルにイベントを実装できるデメリット collectorがいないとイベントは垂れ流されてロストする(demo) ex. 構成変更が発生するとUIが再構成されるので一瞬collectorがいなくなって、その間に発生したイベントはロストするイベントを発火するときに、subscriptionCountが1以上になっていることをチェックすることで回避可能だが。
。 replayCacheをいくらか設けて回避するという手もある

SharedFlow メリットともデメリットとも取れる collectorが複数いた場合に、1つのイベントが同時に複数回消費されることになる(demo) ハンドリングが同じ場合は期待しない挙動になる可能性があるハンドリングが異なる場合は有用な可能性があるこのことを考慮して設計してあるならヨシ → Channelだと複数のcollectorに同じ情報を伝達できない

StateFlow データの持ち方イベントの発火 // ViewModel // 初期値が必要だがイベントに初期値などないのでnullで表現する private val _message
= MutableStateFlow<String?>(null) val message = _message.asStateFlow() _message.value = "message..."

StateFlow // Fragment viewLifecycleOwner.lifecycleScope.launch { viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { if
(it != null) { showSnackBar(it) // イベントをハンドリングしたあとは明示的に消費する viewModel.consumeMessage() } } } } // ViewModel fun consumeMessage() { _message.value = null }

StateFlow // Compose val message by viewModel.message.collectAsStateWithLifecycle() LaunchedEffect(message) { message?.let
{ onMessageReceive(it) viewModel.consumeMessage() } }

StateFlow メリットイベント処理中にcollectorがキャンセルされてたとしても、復帰後に最新のイベントは残っているので再ハンドリング可能デメリットイベントの消費をプログラミングしないといけない明示的にイベントを消し込みイベントを消費したとは？論理的には消費したが、物理的に消費してない状態が成立する(demo)

まとめ Channel ⭕ トーストにメッセージを表示するなどの単純なイベントに向いている ⭕ collect前にイベントが発火する可能性がある場合に向いている ❌ イベントが消失する可能性があるので、重要なイベントには向いてない SharedFlow ⭕
トーストにメッセージを表示するなどの単純なイベントに向いている ⭕ バッファリングとか考えなくてよいのでシンプル ❌ イベントが消失する可能性があるので、重要なイベントには向いてない StateFlow ❌ 単純なイベントについては過度 ⭕ イベントの処理を保証しないといけない場合は向いている ⭕ 重要なイベントに向いている

ご清聴ありがとうございました

イベントをどう管理するか

イベントをどう管理するか

mikan

More Decks by mikan

Other Decks in Technology

Featured

Transcript