:wave: I came across this <article> recently, the ...
# compose
r
๐Ÿ‘‹ I came across this article recently, the part
Safe Flow collection in Jetpack Compose
Copy code
@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?
a
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
r
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.
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.
Probably an example or use-case can clarify ๐Ÿ™‚
a
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
I think one of the examples also used is something like a flow for GPS location
leaving the GPS running is very costly for the user's battery life
r
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.
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!
cc: @Manuel Vivo
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.
a
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
๐Ÿ‘ 1
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 ๐Ÿ™‚
r
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?
๐Ÿ‘ 1
a
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
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
๐Ÿ‘ 1
r
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!
๐Ÿ‘ 1