The use case in my mind would be to ensure the UI ...
# android-architecture
d
The use case in my mind would be to ensure the UI receives all it's states upon starting so I can do animations, or am I cray cray?
g
Could you explain what do you mean?
In general I would avoid mixing LiveData with Flow, same way I would avoid to do that with Channels or Observables, I really don’t see good use cases except adapters to work with some existing component
m
LiveData’s
postValue
does not guarantee that you’ll receive every emitted value
g
The same with ConflatedBroadcastChannel (which is most probably should be used as adapter for LiveData)
d
Yes, agreed.
You don't have to use
postValue
, you can launch a main thread coroutine and use
setValue
.
m
You can do that indeed, but remember switching context comes with a cost too, also will make getting results back blocking. Using a standard channel for example, would be much more suitable compared to LiveData
d
The cost is a fine price to pay if you are using something like MVI. The boundary is crossed only when setting the entire UI's state.
Depends on the app I guess but I have not noticed any problems.
Modern phones are so damn powerful anyway.
a
d
@Ahmed Adel Thanks but I am purposely trying to avoid RxJava
a
I'm interested in this - I have no experience with
Flow
, so forgive me if I'm missing the point. Is the question about whether it makes sense to use both
LiveData
and
Flow
in a single app?
g
Yes, correct
d
Correct
a
I use RxJava and LiveData in a single app, which feels like a similar question
I've found the benefits to be easy testability (since LiveDatas API is so trivial) and reduced possibility for scope creep on my view objects. I've actually come to really love the simplicity that LiveData brings in the View <> Presenter/ViewModel layer.