wave I came across this

Question

wave I came across this <https medium com androiddevelopers a safer way to collect flows from android uis 23080b1f8bda|article> recently the part `Safe Flow collection in Jetpack Compose` ``` Composable fun LocationScreen locationFlow Flow lt Flow gt val lifecycleOwner = LocalLifecycleOwner current val locationFlowLifecycleAware = remember locationFlow lifecycleOwner locationFlow flowWithLifecycle lifecycleOwner lifecycle Lifecycle State STARTED val location by locationFlowLifecycleAware collectAsState Current location do something with it ``` Do we need it while collecting states Isn t `Composables` have their own life cycle and we need not to worry about how the lifecycle of host it s contained in while collecting flows

Adam Powell · Answer

Things don t leave the composition when your activity moves to the background If that matters for your data collection lifecycle then a tool like this can be useful

ritesh · Answer

That should be probably okay i guess when you are collecting `state flows` if my app moves to background new `emit` from api or so before moving to background will just update the view compose or re compose while in background

ritesh · Answer

Making `sate flow` collection host life cycle aware how composable gets notified when there is change in lifecycle from `STARTED` to `PAUSED` or so considering the mentioned scenario where app goes in background and then comes back to foregroud

ritesh · Answer

Probably an example or use case can clarify slightly smiling face

Adam Powell · Answer

if your upstream flow is a cold flow that causes work to be performed while it is actively collecting then this matters to you For example if you had a flow that maintained an open server connection receiving events regularly that is not the sort of thing you want to leave running in the background

Adam Powell · Answer

I think one of the examples also used is something like a flow for GPS location

Adam Powell · Answer

leaving the GPS running is very costly for the user s battery life

ritesh · Answer

Thanks for the explanation Adam makes sense in above use cases I was more thinking or asking in terms `StateFlow` which is a hot stream and whose emission is usually based on some click event or say one shot api call in most of the apps or screens In above scenario it s probably an over kill IMO and doesn t makes much to make this collection host life cycle aware

ritesh · Answer

I am basically looking for a strong reason for making `state flow` collection host activity life cycle smile aware unless required And in most of the use cases we probably don t need it i guess

ritesh · Answer

cc < Manuel Vivo>

ritesh · Answer

Adam I came across this <https kotlinlang slack com archives CJLTWPH7S p1615990405035300 thread ts=1615988629 033800 amp cid=CJLTWPH7S|thread> I should have searched before asking slightly smiling face Few takeaways from this conversation i wanted to clarify gt If you re using the default Recomposer that gets configured when you use ComposeView or ComponentActivity setContent then recompositions will stop when the lifecycle does and start again when the lifecycle does As this is the default behavior one should not worry about re composition when app is in background re comp stops when it s host life cycle does Considering above it s more of a concern if you are collecting cold stream few examples like location update or open socket connection etc or any stream which is effectively updating some state even if the app is in background and to avoid that collecting flows using ` flowOnLifecycle` makes sense But if you have something like StateFlow a hot stream whose emission is not very frequent but limited to one shot api calls etc ` flowOnLifecycle` could be totally avoided as re comp won t take place when app is in back ground as it adheres to the host lifecycle and updating state is fine

Adam Powell · Answer

I would expect that in the future recomposition will likely be slowed way down in frequency ~1Hz or so rather than stopped entirely when the host lifecycle is stopped there are cases where recomposition can be used to stop work too e g removing an effect collecting a cold stream under some circumstances so stopping it entirely probably isn t the ideal long term behavior

Adam Powell · Answer

and if you have something like a StateFlow that isn t a ` stateIn SharingStarted WhileSubscribed ` then you should also ask why it s not a `mutableStateOf` instead slightly smiling face

ritesh · Answer

Sure Is there a benefit or reason when one should mostly prefer `mutableStateOf` instead of `StateFlow` i know that somewhere down the line when we do `collectAsState` it converts to `State lt gt ` I have been using `StateFlow` for every screen even if i don t need to use transformation or other operators and have found it pretty handy when it comes to testing using libs like `turbine` etc Say i don t want to use operators on flows i should be prefer `mutableStateOf` Probably wrap all my `mutableStateOf` inside one class and then expose it to composable

ritesh · Answer

smile nvm i came across this <https kotlinlang slack com archives CJLTWPH7S p1620842047437000>

Adam Powell · Answer

there are some other threads here and there on the topic as well we might publish some additional guides down the line since it comes up fairly frequently

Adam Powell · Answer

a few patterns we ve been playing with make it nice to work with snapshots when cold sources are upstream as well nothing to share as a library there yet though

ritesh · Answer

gt we might publish some additional guides down the line since it comes up fairly frequently that would be great This <https kotlinlang slack com archives CJLTWPH7S p1623313858334200|thread> has detailed explanation Thanks Adam