To the Android Developers: Flow VS LiveData What ...

# coroutines

[Lukas Lechner]

To the Android Developers: Flow VS LiveData

What is the advantage of exposing Flows instead of LiveData from your ViewModel to your Views?

One argument I keep hearing is that you can then use flow operators in your View. However, since Views should actually only render received states to the screen and not have actual logic in them, I don't see any use case where I would need a flow operator there...

I asked this on twitter as well: https://twitter.com/LukasLechnerDev/status/1551584399485026307

[mkrussel]

The main benefits I go with is that it keeps more Android specific classes out of the view model and makes the view model easier to test.

[Adam Powell]

LiveData only exists because at the time, Rx was too large of a library to suggest for basic use cases. Flow has a much gentler onramp for learning and kotlinx.coroutines is much smaller. By comparison to Flow, LiveData has a much more restrictive threading model, the tie to Lifecycle as opposed to the scoping of a suspend call is more complex than needed, and the hand-wavey nullability of LiveData during its initial uninitialized state leads to bugs and poor data modeling. There aren't any reasons to choose LiveData over Flow in new code beyond existing familiarity.

[Robert Williams]

You are correct about not transforming Flows in Views, but if you have Flows coming from upstream it’s a lot simpler to manipulate them to return Flow then trying to do the same in LiveData

[Robert Williams]

Some good examples here: https://medium.com/androiddevelopers/migrating-from-livedata-to-kotlins-flow-379292f419fb