:wave: I came across this <article> recently, the part `Safe Flow collection in Jetpack Compose` ``...

# compose

[ritesh]

👋 I came across this article recently, the part Safe Flow collection in Jetpack Compose

@Composable
fun LocationScreen(locationFlow: Flow<Flow>) {

    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]

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]

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]

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]

Probably an example or use-case can clarify 🙂

[Adam Powell]

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]

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

[Adam Powell]

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

[ritesh]

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]

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

[ritesh]

cc: @Manuel Vivo

[ritesh]

Adam, I came across this thread I should have searched before asking 🙂

Few takeaways from this conversation i wanted to clarify -

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]

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]

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 🙂

[ritesh]

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

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]

😄 nvm, i came across this
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1620842047437000

[Adam Powell]

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]

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]

we might publish some additional guides down the line since it comes up fairly frequently

that would be great!

This thread has detailed explanation!

Thanks Adam!