Menu
Flow has a lot of operators, LiveData has only 3 (Transformations). Is there any reason to keep using LiveData except StateFlow is still experimental?
UPD. StateFlow, SharedFlow and corresponding operators are promoted to stable API in kotlinx.coroutines 1.4.0
661
StateFlow requires an initial state to be passed in to the constructor, while LiveData does not. LiveData. observe() automatically unregisters the consumer when the view goes to the STOPPED state, whereas collecting from a StateFlow or any other flow does not stop collecting automatically.
StateFlow and LiveData have similarities. Both are observable data holder classes, and both follow a similar pattern when used in your app architecture. The StateFlow and LiveData do behave differently: StateFlow requires an initial state to be passed into the constructor, while LiveData does not.
Flow is cold!, means it emits data only when it is collected. Also Flow cannot hold data, take it as a pipe in which water is flowing , data in flow only flows , not stored(no . value function). Unlike flow , stateflow and sharedflow are hot streams means they emit data even when there is no collector.
In a ViewModel, you have the same risk of collecting from Flows for no reason. To avoid it, you can use stateIn or shareIn with a WhileSubscribed value. Then it will stop collecting when there is nothing downstream collecting.
Create LiveData objects in the ViewModel and use them to expose state to the UI layer. Activities and fragments should not hold LiveData instances because their role is to display data, not hold state. Also, keeping activities and fragments free from holding data makes it easier to write unit tests.
If your app has MVVM architecture, you normally have a data layer (repository, data source, etc.), ViewModel and view (Fragment or Activity). You would probably be using LiveData for data transfers and transformations between these layers. But what is the main purpose of LiveData? Is it designed to make data transformation?
To understand that, you should be good with the basics. In simple terms, LiveData is an observable data holder class. This means it can hold a set of data that can be observed from other Android components like Activities, Fragments, and Services. It’s lifecycle-aware and mostly used to update UI from the ViewModel in MVVM architecture projects.
Since LiveData is a lifecycle aware component, it is best to use it in view and ViewModel layer. But how about the data layer? I think the biggest problem of using LiveData in the repository level is all data transformation will be done on the main thread unless you start a coroutine and do the work inside.
There is not much reason to use LiveData nowadays. (State)Flow/Coroutines also brings new possibilites via lifecycleScope.launchWhenCreated/Started/Resumed, hard to do with LiveData.
But there is one reason when LiveData is needed - DataBinding. It currently doesn't support observing Flow.
EDIT: there is going to be support for StateFlow in DataBinding in Android Studio 4.3: https://twitter.com/manuelvicnt/status/1314621067831521282
130
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
