Collecting flows in a lifecycle-aware manner

Collecting flows in a lifecycle-aware manner is the recommended way to collect flows on Android. In this talk, we explore the different APIs you have to do so, such as the repeatOnLifecycle API or collectAsStateWithLifecycle API in Jetpack Compose, and see how they work under the hood.
Speaker: Manuel Vicente Vivo
Watch more:
Watch all the Android Dev Summit sessions → goo.gle/ADS-All
Watch all the Modern Android Development track sessions → goo.gle/ADS-MAD
Subscribe to Android Developers → goo.gle/AndroidDevs
#Featured #AndroidDevSummit #JetpackCompose

[@albab790]

Thanks

[@trocchiettoski]

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.

[@user-ij6um9vx4e]

You are a life saver brooo 🥳🎉🎉🎉🎉

[@omotexoman9860]

thanks

[@kalidsherefuddin]

Ok thanks

[@anthonyanthony3871]

Thankss and byebye live data

[@alco8864]

The problem of the collect manner is too many workable ways that let junior developer may use incorrectly.

[@SnoopyDoofie]

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.

[@gauravthakkar802]

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

[@digitaliabe]

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.

[@zekininadresi]

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.

[@alexiitrotsenko3781]

Normally we should not be worried about yet another coroutine created - they as lightweight and thus cheap unlike threads

[@javiere.gonzalez1021]

LiveData is unfavorable because it exposes UI/Activity logic (the lifecycle) to your viewmodels. It makes separation of concerns between view/viewmodel blurry.

[@sailor.seahell]

@@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.

[@georgeshalvashvili6270]

This API is just ugly, why do we have so many lambdas nested? Why not have it as clean as LiveData?

[@-Alexey-]

You can make your own extension and use it exactly like livedata.