LiveDataのこれまで
Coroutinesのアップデートが盛んに行われており、昨今のAndroid界隈でLiveDataからFlowへ乗り換える機運が高まっているように感じます。今一度Flowへの乗り換えをスムーズに行うためにもLiveDataが発表された経緯など歴史を振り返りたいと思います。
Architecture components - introduction (Google I/O '17)
Google I/O 17ではArchitecture Componentsが発表された。LifecycleOwner/LiveData/ViewModelあたりのComponentはこの発表が初出。onStartやonStopなどActivity/Fragmentが持つ複雑なライフサイクルに対応すること、複数のライフサイクルでリソースをシェアすることを目的にLifecycle AwareなLiveDataが発表された。 www.youtube.com
Fun with LiveData (Android Dev Summit '18)
LiveDataについてIt's desgined for a very specific use case と言及されている。LiveDataを使わないケースとして以下3つがあげられていた。
1. 多くのオペレータやストリームが必要な場合 => Rx 2. データの操作にUIやlifecycleが絡まない場合 => callback 3. データの更新がないone-shotな操作 => coroutines
Google I/O 17で言及されていた通りでAndroid固有の複雑なライフサイクルに対応するという狭い目的でLiveDataが発表されたことが強調されていた。ストリーム処理の用途でLiveDataを利用したいという要望をよく見かけるがそもそも用途が異なるということがわかる。
またmap/switchMap/MediatorLiveDataあたりはこの発表が初出。
Android Jetpack: What's new in Architecture Components (Google I/O '18)
Android Jetpackが発表された。LiveDataのDataBindingはこの発表が初出。
LiveData with Coroutines and Flow (Android Dev Summit '19)
LiveDataとCoroutineの連携について発表された。主題はFragment,Activity,ViewModel,Applicationそれぞれが持つスコープでいかに操作をキャンセルするかであり、Coroutineのスコープについてがメイントピックになっていた。LiveDataはリアクティブストリームビルダーとして設計されたわけではないとここでも強調されており、 実装についてはViewModel,Repository,DataSourceの3層でLiveData,Flowそれぞれを利用した場合のPro/Conが述べられている。特にデータの操作が複雑になりやすいRepository層DataSource層でCoroutine Flowが有効であり、ViewModel層では画面ロード時に1度だけ呼び出すようなone-shotな操作にはLiveData Builderを用い、複数回データが更新されるような処理の場合はRepository層ではFlowを採用したほうが良いと言われていた。
まとめ
- LiveDataの用途は限定的であり、特徴はLifecycle Awareである
- 複雑なストリーム処理用途ではないためRxにあるようなオペレータは実装されていない
- RxがオーバースペックなアプリではLiveDataで仕様を実現できたが本来Rxを代替するものではない
- Coroutine FlowはRxを代替するものだがLiveDataを代替するものではない
