https://kotlinlang.org logo
Join Slack
Powered by
what are the benefits for using Flow from a Room q...
# coroutines
r
what are the benefits for using Flow from a Room query in Android as oppose to using Livedata?
m
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.
t
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()
).
r
Ok so Flow gives me more flexibility with operators and more Dispatchers(IO/Default)
But Livedata is Lifecycle aware right and integrates with data binding nicely
message has been deleted
so this would be the ideal patern right?
👍 2
s
Flows can be lifecycle aware also, provided that you use a lifecycle scope when consuming them
m
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.
➕ 2
r
And this green outlined text kind of suprised me. Observing Livedata in your viewmodel from your Activity or Fragment is like super standard?
s
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.
b
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
r
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'.
it's obserable and the observing UI element will receives data changes
m
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
.
r
ok good to know
b
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)?
z
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)
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
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>
6 Views
Open in Slack
PreviousNext
Powered by