Hey guys! I'm using Flow to emit data from Reposit...

# android-architecture

[Paolo Rotolo]

Hey guys! I'm using Flow to emit data from Repositories all the way up to Viewmodels.
I've watched some talks at Dev Summit and now it's suggested to switch to LiveData to expose data to activities views. My question is: is it really necessary and what are the differences between exposing as LiveData or collecting values directly from Flow in view's lifecycleScope?

[rkeazor]

You dont have to use LiveData. But there benefits to using livedata. Livedata builder is pretty powerful and has built in coroutines support . And it can become lifecycle aware, so you dont have to worry about managing the lifecycle so you dont have to worry about managing the coroutine lifecycle on your own

[tschuchort]

Usually when Google devs recommend something it is best to ignore them and do the exact opposite.

[tschuchort]

To maybe give a more useful answer: stay with flow. Is livedata a bit easier to use? Maybe. But flow is much more flexible, it can grow with you. Also livedata is one more technology that your team has to know and maintain code for. Google devs simply don't understand the difference between easy and simple. Which is why we always get stuff that is easy to use for the trivial case but blows up on you as soon as you want to do something more custom. Rx or flow is harder at first, but scales with more complicated use cases.

[rkeazor]

Most of the api you develop with are made by Google devs. The thing is you can use LiveData with flow or coroutines. It doesnt have to be one or the other. Depends on your actual usecase. You can also achieve the same thing with flow or callback flow by itself. But you will handle lifecycle on your own.

[rkeazor]

Look at this way,the way you interact with your repository class is the same. Either with flow or suspend.. now how you want to interact with it , is up to you. You can use viewmodelscope, or your own coroutine scope. . Th

[tschuchort]

Most of the APIs I use are terrible. I can count on one hand the Android SDK classes that aren't crap. In fact LiveData and ViewModel exist only to work around other terrible design decisions of the Android API in the past. If you already use Flow or Rx then there's no point to LiveData. It does pretty much the same thing but worse. It's only useful for people who never adopted either and are for some reason stuck to whatever is endorsed by Google.

[rkeazor]

I think its just a matter of opinion. For me there is benefits to live data. One it works seamlessly with data-binding, and life-cycle owner.

[Paolo Rotolo]

Yeah, thanks guys. Right now both are lifecycle aware (LiveData with lifecycleowner and Flow with lifecycleScope). @yigit was talking about "caching behaviour" embedded in LiveData, that's why I wanted to know more about it.

[rkeazor]

Ahh I see. So for LiveData value is only queried when there is a active observer if not it will be cached until it become reactive. So that means if you use your fragment , or activity as its lifecycle owner, it will only emit while your active or fragment is in some kind of active state, if not it will just cache the last value you set

[ghedeon]

So, the real question is how to make Flow behave like LiveData (some cache operator?), so you can finally ditch and forget LiveData, like we usually do with google stuff 🙂?

[ghedeon]

I mean, I don't need ten Rx frameworks in my app and convertors between them, and obviously Flow is superior.

[rkeazor]

Here comes the hate train lol. Live data and Flow, are fundamentally different and can work in parallel . there was a whole google talk about using Flow with LiveData...

[ghedeon]

Yeah, critical thinking is called "hate" nowadays :). Thankfully, it's not a VICE comment section, lol. That talk makes sense, because it's logical for Google to talk about their libraries. That explains nothing. LiveData, Flow, RxJava are fundamentally the same thing — Observable. How do I know? Well, Rx was used instead of LiveData for years. Where is Google's recommendation to use LiveData in Repositories now? Why Room supports Flow and Rx and before it was LiveData? Why SqlDelight supposrts Flow and Rx? It's so fundamentally different that it's interchangeable in the bat of an eye? 🙂 What a paradox.

[rkeazor]

Bruh , they are fundamentally different. I feel like I tell you this all the time. LiveData, is a data holder. Nothing more nothing less. Flow fundamentally was ment to handle cold streams of data , which is opposite of channels that handle hot streams of data. Rx was both cold and hot . Like you can actually use all these technologies in parallel if you really wanted to. Ahh so what if Room supported those types , it also supported Deferred<T> to. Will you now say Deferred and Flow are the same thing now lol. The only similarity is they can hold data, but the way data is transmitted is completely different for each. There are things that livedata shines at. Being that appcompact activity and fragment now extend lifecycle owner, livedata can integrate with the android lifecycle right out of the box. Since it was built to work with it. And it works better with databinding.Sure you can achieve the same thing with flow but not right out the box, there are some considerations that have to be made. If you want to use livedata in your repos you can, you just have to use Transformations.. But it wasnt built for asynchronous operations that's why they integrated it with coroutines, so it makes sense to use flow or suspend in the repo level since you normally do asynchronous stuff in the repo level... Its ok to be a anti google protester, but atleast give a fair assertion about there APIs lol.

[rkeazor]

This is sorta of how people started protesting agianst Rx Java , when Kotlin coroutines reach stable. Even tho the lead developer for coroutines in Jetbrains said they are fundamentally different... But people didnt care, there where whole talks about RxJava vs Coroutines , which made absolutely no sense lol. It would have been better if they did a talk about Coroutines vs threads or other concurrency models. But to them Rx java sucked and should have never existed in a world where coroutines where born

[rkeazor]

And I'm not saying livedata is perfect , all I'm saying is given the current state of the framework, there are def usecases for it. Perhaps if jetpack compose becomes the new way to Android probably livedata wont be as useful. But currently, it works well with the framework minus the fact it cant handle one off events . And I believe that's fair to say

[Anastasia Finogenova]

@rkeazor I agree 💯 with what you are saying , I don't understand why people are torturing themselves though, if you feel things you work with suck (Andoroid apis) just move on to something that will bring you pleasure. What is the point of saying I hate Andoroid sdk and work with it everyday. Or if you don't hate it as much...just stop seeking attention with this loud statements (I do the opposite of what Google says etc)

We use livedata + databinding in the presentation layer (viewmodel -> view ) and it works best and for handling streams and async operations use coroutines why do you want to pick one and then complain how Android sucks that you struggle every day with your choices of architecture and do the opposite of what Google offers you as a solution to your problem 🤷🤷🤷 and using livedata with room is actually pretty handy if you don't require data transformations, when I just need to observe the changes out of the box it is great to return a livedata and just write the changes and they are gonna be applied to UI automatically, I designed two apps with this set up already and it had been a breeze so far