https://kotlinlang.org logo
Title
r

Remy Benza

02/06/2020, 8:00 AM
what are the benefits for using Flow from a Room query in Android as oppose to using Livedata?
m

Mark McCormick

02/06/2020, 8:40 AM
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

tseisel

02/06/2020, 8:43 AM
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

Remy Benza

02/06/2020, 11:13 AM
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
so this would be the ideal patern right?
👍 2
s

Shmuel Rosansky [G]

02/06/2020, 12:01 PM
Flows can be lifecycle aware also, provided that you use a lifecycle scope when consuming them
m

Mark Murphy

02/06/2020, 12:12 PM
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

Remy Benza

02/06/2020, 12:19 PM
And this green outlined text kind of suprised me. Observing Livedata in your viewmodel from your Activity or Fragment is like super standard?
s

streetsofboston

02/06/2020, 12:24 PM
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

Brian

02/06/2020, 12:58 PM
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

Remy Benza

02/06/2020, 1:00 PM
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

Mark Murphy

02/06/2020, 1:02 PM
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

Remy Benza

02/06/2020, 1:02 PM
ok good to know
b

bdawg.io

02/06/2020, 4:55 PM
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

zak.taccardi

02/06/2020, 5:30 PM
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>