A modern programming language that makes developers happier.

kotlinlang

Hello guys, If you are using coroutines in your Android Projects, this could probably help you to boost it <https://blog.loop-ideas.com/android-livedata-coroutines-the-next-level-with-map-and-switchmap-extensions-b56a2f2f2ba7>

Why would you use livedata and coroutines in the same project? LiveData has a subset of the functionality that coroutines provide. Seems redundant to have both libraries

LiveData is a reactive lifecycle aware component that help's you handle data and persist it as long as the lifecycle owner is "alive", while Coroutines are used for handle thread safety asynchronous operations, I dont' see the redundant part as they are 2 different libraries with waay two different purposes...

You can easily accomplish the same thing as LiveData with Coroutines Channels or StateFlow. As far as being lifecycle aware, this is easily accomplished by making a coroutinescope and cancelling it `onClear` or `onViewDestroy` , or by making use of the android provided `lifecycleScope` or `viewModelScope` (although I wouldnt suggest the latter option)

LiveData also does not "persist" data. You still need to handle the android OS killing your lifecycle owner regardless of which approach you use to create a stream from viewmodel to view

Bro, have you read the article? :sweat_smile: because I think you are getting conclusions based on the title... I don't think is wrong to make LiveData and Coroutines work together if they are already on the project module, I don't know why would you use Channels (which are HOT observables) for replace of LiveData, or probably you think I'm using LiveData in other layers outside of the presentation layer (which Im not). Apart from being lifecycle aware it's great to use at `presentation/ui` level with DataBinding, reduce the verbosity of your views. Also, I never said that LiveData "persist" the data even if the OS Kill the app, we all know that the "ViewModel" can't survive that (but now it actuallty work with <https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate|onSaveInstance> so is not "imposible" any more), I said `persist it as long as the lifecycle owner is "alive"` For the purpose of the example It's just a combination of libraries which you can or can not use in your projects, not a MUST TO, if you are fine working only with coroutines and not livedata or viceversa, it's ok. Also why wouldn't you use `viewModelScope`?

yes I read the article... StateFlow can do just about everything LiveData can (even google agrees it can replace LiveData). Theres nothing wrong with using LiveData but if you already have coroutines as a dependency in your project, using LiveData just adds an extra dependency that doesnt provide any extra functionality

Yes, google recently have a video about it, but even Manuel Vivo says "It's to early to say what's the future of LiveData" (<https://youtu.be/6manrgTPzyA?t=770>) It could probably be the end of LiveData aswell, but that is not close yet. If you already have experience with StateFlow and an App with no LiveData dependencies, it would be great that you show us how does it work! I would like to see that. :raised_hand_with_fingers_splayed:

sure thing! this setup is very similar to LiveData
```  private val _viewstate: MutableStateFlow&lt;ViewState&gt; = MutableStateFlow(ViewState.Idle)
    val viewState: StateFlow&lt;ViewState&gt; = _viewstate```

you can then set the value whenever you need and do `viewState.collect { }` from your fragment class to receive the events

you can also accomplish similar behavior with a BroadcastChannel