what are the benefits for using Flow from a Room query in Android as oppose to using Livedata?

# coroutines

[Remy Benza]

what are the benefits for using Flow from a Room query in Android as oppose to using Livedata?

[Mark McCormick]

I would say that Flow has numerous operators you can apply to the stream in comparison with LiveData which have almost none. That might be considered as an advantage.

[tseisel]

Flow has way more operators.
Also, LiveData is only consumed from the Main thread, while Flow could be consumed from any context (using flowOn operator).
But LiveData has the advantage of saving the latest received value (liveData.getValue()).

[tseisel]

More answers here : https://stackoverflow.com/questions/58890105/kotlin-flow-vs-livedata

[Remy Benza]

Ok so Flow gives me more flexibility with operators and more Dispatchers(IO/Default)

[Remy Benza]

But Livedata is Lifecycle aware right and integrates with data binding nicely

[Remy Benza]

message has been deleted

[Remy Benza]

so this would be the ideal patern right?

[Shmuel Rosansky [G]]

Flows can be lifecycle aware also, provided that you use a lifecycle scope when consuming them

[Mark Murphy]

Also, there is an asLiveData() extension function on Flow to wrap it in a LiveData. So, your diagram a couple of comments earlier in this thread is fairly easy to implement.

[Remy Benza]

So i'm following this advance Google Code lab: https://codelabs.developers.google.com/codelabs/advanced-kotlin-coroutines/?authuser=0#13

[Remy Benza]

And this green outlined text kind of suprised me. Observing Livedata in your viewmodel from your Activity or Fragment is like super standard?

[streetsofboston]

We use LiveData only as properties in ViewModels for Activities/Fragments to observe. All the other stream types are either Flows or Rx Observables.

The Flow.asLiveData() has some issues with its pausing dispatcher and we don't yet use it.

[Brian]

And this green outlined text kind of suprised me. Observe Livedata in your viewmodel from your Activity or Fragment is like super standard?

i think the text in your screenshot happens to be awkwardly worded, what it means is don’t have your ViewModel observe a LiveData property, observing a LiveData property in your ViewModel with an Activity or Fragment is super standard, as you say

[Remy Benza]

We use LiveData only as properties in ViewModels for Activities/Fragments to observe. All the other stream types are either Flows or Rx Observables. The Flow.asLiveData() has some issues with its pausing dispatcher and we don't yet use it.

But would you consider Livedata a 'steam' type? Since it returns a whole list like 'listOf(1, 2, 3)' instead of a flow of items in the list '1, 2, and 3'.

[Remy Benza]

it's obserable and the observing UI element will receives data changes

[Mark Murphy]

Flow can emit List<Int> and LiveData can emit Int. The type of what is being emitted to observers is independent of whether it is Flow or LiveData.

[Remy Benza]

ok good to know

[bdawg.io]

Isn't LiveData meant to represent a single value that changes over time (ie, a user's first name) whereas Flow is just a stream of one or more values over time (ie, click events of a button)?

[zak.taccardi]

do not use LiveData<T> anywhere except in a ViewModel to expose a T to a UI component (such as an Activity or Fragment). Flow<T> should be preferred everywhere else (and I prefer it at the ViewModel level too because it avoids the main thread limitation)

[zak.taccardi]

LiveData<T> is analogous to a Flow<T> backed by a ConflatedBroadcastChannel<T> (or a StateFlow<T> in the next release of Kotlin Coroutines).

This means that the T is replayed to new subscribers on initial subscription

[zak.taccardi]

LiveData<T> has a specific behavior (replaying latest value on subscription) that certain implementations Flow<T> support. Flow<T> is the more flexible type, which can cause some confusion because how the T emits from can differ from Flow<T> to Flow<T>