Manuel you are doing a lot of job to improve how Android should be taught. Finally you guys from Android speak slowly, put emphasis on the words, and furnish a lot of visual tools, and explain clearly the problem you are going to solve, then repeat in a structure what you say, and finally we have an app android now that put in practice everything.
Not sure wha the point of this is given that there has already been a lifecycle api available for years and you can use it in a viewmodel where you can do your flow collection.
I think for MVVM and normal cases, viewModel Scope should do just good But there are people that will collect everything in the activity, and there might be complex cases where you want manual control over lifecycle much more than viewModelScope
You can't reference an Activity or Fragment lifecycle in a ViewModel, that would be a memory leak. You need an API at the View level to synchronize the Flow collection with the view lifecycle.
That's why LiveData might be outdoing Flows. Integrating lifecycle into your flows this way always creates a new coroutine, for example, when the app is sent to bg (STOPPED) and brought back to fg (STARTED) again. If you had LiveData, you could just observe it w/out this overhead and latest data would always been republished when necessary.
LiveData is unfavorable because it exposes UI/Activity logic (the lifecycle) to your viewmodels. It makes separation of concerns between view/viewmodel blurry.
@@javiere.gonzalez1021 at one point one way or another, the lifecycle will need to be accounted for - whether or not that's with livedata in the viewmodel or creating coroutines in the fragment/activity/composable to consume it in a lifecycle aware way there. unless android has a fundamental rewrite of the framework, we'll need to account for that. I think the argument around where those concerns interact is a valid one, as there are tradeoffs to both ways.
You are a life saver brooo 🥳🎉🎉🎉🎉
Manuel you are doing a lot of job to improve how Android should be taught. Finally you guys from Android speak slowly, put emphasis on the words, and furnish a lot of visual tools, and explain clearly the problem you are going to solve, then repeat in a structure what you say, and finally we have an app android now that put in practice everything.
The problem of the collect manner is too many workable ways that let junior developer may use incorrectly.
Not sure wha the point of this is given that there has already been a lifecycle api available for years and you can use it in a viewmodel where you can do your flow collection.
I think for MVVM and normal cases, viewModel Scope should do just good
But there are people that will collect everything in the activity, and there might be complex cases where you want manual control over lifecycle much more than viewModelScope
You can't reference an Activity or Fragment lifecycle in a ViewModel, that would be a memory leak. You need an API at the View level to synchronize the Flow collection with the view lifecycle.
This API is just ugly, why do we have so many lambdas nested? Why not have it as clean as LiveData?
You can make your own extension and use it exactly like livedata.
Thanks
thanks
Thankss and byebye live data
Ok thanks
That's why LiveData might be outdoing Flows. Integrating lifecycle into your flows this way always creates a new coroutine, for example, when the app is sent to bg (STOPPED) and brought back to fg (STARTED) again. If you had LiveData, you could just observe it w/out this overhead and latest data would always been republished when necessary.
Normally we should not be worried about yet another coroutine created - they as lightweight and thus cheap unlike threads
LiveData is unfavorable because it exposes UI/Activity logic (the lifecycle) to your viewmodels. It makes separation of concerns between view/viewmodel blurry.
@@javiere.gonzalez1021 at one point one way or another, the lifecycle will need to be accounted for - whether or not that's with livedata in the viewmodel or creating coroutines in the fragment/activity/composable to consume it in a lifecycle aware way there. unless android has a fundamental rewrite of the framework, we'll need to account for that. I think the argument around where those concerns interact is a valid one, as there are tradeoffs to both ways.