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

【祝！50回】Shibuya.apk #50
https://shibuya-apk.connpass.com/event/336398/

Transcript

1. イベントをどう管理するか Shibuya.apk #50 mikan(一瀬喜弘)
2. 自己紹介 object Mikan { val name = 一瀬喜弘 val from = 長崎 val company = カラビナテクノロジー株式会社 val work = Engineer.Android val volunteer = DroidKaigi val hobby = listOf( "漫画", "アニメ", "ゲーム", "折り紙", "OSS開発・コントリビュート", ) }
3. 今日お話しする内容
4. Channel vs. SharedFlow vs. StateFlow エラーや​ 通信結果などの​ イベントを​ どこで​ 管理するのか
5. 結論 エラーや​ 通信結果などの​ イベントを​ どこで​ 管理すべきか？
6. それぞれの​ メリデメを​ 把握したうえで​ 適当な​ ものを​ 選んでください
7. どれを​ 使うかは​ 所詮手段でしかないです 取り扱おうと​ している​ イベントの​ 重要度だったり、​ どう​ ハンドリングされるかを​ きちんと​ 把握しないと​ 適切な​ ホルダーは​ 選べません
8. これから​ メリデメを​ 紹介するので、​ 適した​ 手段を​ 検討できるようになって​ もらえれば​ 幸いです
9. イベントとは
10. イベントとは ユーザー操作によってUI側から発生し、ViewModelに 伝達したい情報
12. けど​ ViewModelから​ UIに​ イベントを​ 送信したい​ ときも​ ありますよね
13. ex. 1. 通信が完了したら画面遷移する 2. 通信が失敗したらエラーダイアログを表示する 3. SharedPreferencesからデータを削除したらトーストを表示す る
15. ViewModelから​ UIに​ イベントを​ 伝達する​ ためにはなにかしら​ データホルダーが​ 必要に​ なる
16. Channel? SharedFlow? StateFlow? 戦争が始まる
17. それぞれについて実装方法をみ ていきます
18. Channel データの持ち方 イベントの発火 // ViewModel private val _message = Channel<String>() val message = _message.receiveAsFlow() viewModelScope.launch { _message.send("message...") }
19. Channel イベントの消費 // Fragment viewLifecycleOwner.lifecycleScope.launch { viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { showSnackBar(it) } } }
20. Channel イベントの消費 // Compose val lifecycle = LocalLifecycleOwner.current.lifecycle LaunchedEffect(Unit) { lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { showSnackBar(it) } } }
21. Channel メリット collectorがいない間に発生したイベントをバッファリングできる(demo) デメリット イベントの​ 消費中に​ coroutine が​ キャンセルされたら​ どうしますか？​ (demo)
22. Channel メリット collectorがいない間に発生したイベントをバッファリングできる(demo) デメリット イベントの​ 消費中に​ coroutine が​ キャンセルされたら​ どうしますか？​ (demo) → バッファリングの挙動とバックグラウンド時のキャンセルが絡み合うとイベン トハンドリングの振る舞いがどんどん予測困難になる
23. SharedFlow データの持ち方 イベントの発火 // ViewModel private val _message = MutableSharedFlow<String>() val message = _message.asSharedFlow() viewModelScope.launch { _message.emit("message...") }
24. SharedFlow イベントの消費 Channelのときと同じ // Fragment viewLifecycleOwner.lifecycleScope.launch { viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { showSnackBar(it) } } }
25. SharedFlow イベントの消費 Channelのときと同じ // Compose val lifecycle = LocalLifecycleOwner.current.lifecycle LaunchedEffect(Unit) { lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.message.collect { showSnackBar(it) } } }
26. SharedFlow メリット デメリットに目を瞑れば、シンプルにイベントを実装できる デメリット collectorがいないとイベントは垂れ流されてロストする(demo) ex. 構成変更が発生するとUIが再構成されるので一瞬collectorがいなくなっ て、その間に発生したイベントはロストする イベントを発火するときに、subscriptionCountが1以上になっていること をチェックすることで回避可能だが。 。 replayCacheをいくらか設けて回避するという手もある
27. SharedFlow メリットともデメリットとも取れる collectorが複数いた場合に、1つのイベントが同時に複数回消費されることに なる(demo) ハンドリングが同じ場合は期待しない挙動になる可能性がある ハンドリングが異なる場合は有用な可能性がある このことを考慮して設計してあるならヨシ → Channelだと複数のcollectorに同じ情報を伝達できない
28. StateFlow データの持ち方 イベントの発火 // ViewModel // 初期値が必要だがイベントに初期値などないのでnullで表現する private val _message = MutableStateFlow<String?>(null) val message = _message.asStateFlow() _message.value = "message..."
29. 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 }
30. StateFlow // Compose val message by viewModel.message.collectAsStateWithLifecycle() LaunchedEffect(message) { message?.let { onMessageReceive(it) viewModel.consumeMessage() } }
31. StateFlow メリット イベント処理中にcollectorがキャンセルされてたとしても、復帰後に最新のイ ベントは残っているので再ハンドリング可能 デメリット イベントの消費をプログラミングしないといけない 明示的にイベントを消し込み イベントを消費したとは？ 論理的には消費したが、物理的に消費してない状態が成立する(demo)
32. まとめ Channel ⭕ トーストにメッセージを表示するなどの単純なイベントに向いている ⭕ collect前にイベントが発火する可能性がある場合に向いている ❌ イベントが消失する可能性があるので、重要なイベントには向いてない SharedFlow ⭕ トーストにメッセージを表示するなどの単純なイベントに向いている ⭕ バッファリングとか考えなくてよいのでシンプル ❌ イベントが消失する可能性があるので、重要なイベントには向いてない StateFlow ❌ 単純なイベントについては過度 ⭕ イベントの処理を保証しないといけない場合は向いている ⭕ 重要なイベントに向いている
33. ご清聴ありがとうございました