This message was deleted.

# compose

[Slackbot]

This message was deleted.

[John O'Reilly]

https://developer.android.com/kotlin/flow/stateflow-and-sharedflow talks about difference in behaviour between LiveData and StateFlow in this scenario

• LiveData.observe() automatically unregisters the consumer when the view goes to the STOPPED state, whereas collecting from a StateFlow or any other flow does not.

[Timo Drick]

collectAsState will keep track of livecycle for you.

[John O'Reilly]

I'm seeing in this case that flow is still active when app goes in to background

[Timo Drick]

What do you mean with background?

[John O'Reilly]

home button vs say back button

[Leland Richardson [G]]

it will cancel when that location in composition is disposed

[John O'Reilly]

the link above (for pre-compose UI) talks about having to explicitly cancel in onStop()

[John O'Reilly]

not sure if there's something equivalent we can/should do in compose world

[Leland Richardson [G]]

collectAsState AFAIK uses rememberCoroutineScope which is a coroutinescope which will get cancelled automatically whenever it is removed from the slot table (which is when that location gets disposed)

[Leland Richardson [G]]

i don’t have my IDE open at the moment so i can’t verify this, but i’m pretty sure this is the case

[louiscad]

@John O'Reilly You can use the flatMapLatest operator on the Lifecycle.isStartedFlow() and bring your flow when started, and emptyFlow() otherwise.

The Lifecycle.isStartedFlow() I'm referring to is documented and available here:

https://github.com/LouisCAD/Splitties/tree/main/modules/lifecycle-coroutines

[Leland Richardson [G]]

OK, i’m part right, part wrong

[Leland Richardson [G]]

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/SideEffect.kt;l=265?q=LaunchedEffect&ss=androidx%2Fplatform%2Fframeworks%2Fsupport

[Leland Richardson [G]]

LaunchedEffect is fundamentally what is being used here, which implements a CompositionLifecycleObserver which will cancel the job as soon as it leaves the slot table

[Leland Richardson [G]]

so cancellation will occur when i said

[Leland Richardson [G]]

but it uses the applyCoroutineContext by default

[John O'Reilly]

how does that map then to say activity going in to STOPPED state?

[Timo Drick]

Stopped state of activity will not change anything.
Destroyed is interessting maybe. But your compose views should be disposed before the activity is destroyed

[Leland Richardson [G]]

it depends on whether or not you have any code that disposes your composition in onStop

[Leland Richardson [G]]

but i think typically it will mean nothing happens in this case

[Leland Richardson [G]]

but i think might be different if you use the navigation AAC w/ compose

[John O'Reilly]

so, sounds like this t something app needs to explicitly hook in to right now (to trigger cancellation) (as per that article above)

[Leland Richardson [G]]

or rather, I think NavHost might dispose the screen in this case. not sure

[John O'Reilly]

in this example I'm just testing with one screen (no navigation) and then hitting home button (or equivalent) to put app in background

[Leland Richardson [G]]

right now i think that is correct, yes. we might want to look into different default behavior for onStop

[Leland Richardson [G]]

though i should verify that right now as well, one sec

[Leland Richardson [G]]

we’ve been discussing some related questions

[Leland Richardson [G]]

for instance, when we have a composition of a row of LazyColumn that is off screen, should we dispose it or should there be some “stopped” like state. and should recompositions happen or not, etc.

[Ian Lake]

(PSA: Navigation does nothing in response to onStop)

[John O'Reilly]

fwiw I've pushed changes to following branch that demonstrate this scenario (though probably easy enough to replicate anyway) https://github.com/joreilly/PeopleInSpace/tree/iss_position_poll

[John O'Reilly]

Repository exposes api that returns flow that polls periodically (for ISS Position), in ViewModel that's converted to StateFlow (using stateIn()) and then compose code uses colllectAsState()

[John O'Reilly]

looks like collectAsState() can be passed a CoroutineContext ...wondering if that could perhaps be used to influence behaviour in this scenario

[Ian Lake]

Keep in mind that when you use .stateIn(viewModelScope, SharingStarted.Eagerly, emptyList()), you'll always be collecting on the upstream flow as long as the ViewModel exists, no matter what state / how many collectors you have downstream from that - whether you're stopped, started, in the background, etc. won't matter

[Ian Lake]

You'd need to use SharingStarted.WhileSubscribed if you want your upstream collecting to be cancelled when your subscribers go away: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-sharing-started/-while-subscribed.html

[Ian Lake]

and only then would it matter whether you cancel when stopped vs cancelled when destroyed/disposed

[John O'Reilly]

ah, interesting, thanks....I'd recently started using stateIn but didn't pay enough attention to that param!

[John O'Reilly]

regarding "it depends on whether or not you have any code that disposes your composition in onStop"

Is that something that I can influence right now?

[John O'Reilly]

It also feels like whatever is settled on in terms of lifecycle/scope related behaviour here has implications for value (or not) of continuing to use AAC ViewModel

[John O'Reilly]

I tried to capture my notes on this behaviour (and resulting changes I made to a sample project I have) in following https://johnoreilly.dev/posts/jetpack-compose-stateflow-livedata/. @Leland Richardson [G] @Ian Lake it would be great if you could cast an eye over it if you have a chance in case any glaring errors (or anything you think needs clarifying)

[louiscad]

@John O'Reilly I don't know if you saw my mention earlier where I was talking about another approach, but here's what I had in mind exactly, which I believe makes collecting a flow while the lifecycle is started, easier:

import androidx.lifecycle.Lifecycle
import kotlinx.coroutines.flow.*
import splitties.lifecycle.coroutines.isStartedFlow

fun <T> Flow<T>.whileStarted(lifecycle: Lifecycle): Flow<T> {
    return lifecycle.isStartedFlow().flatMapLatest { isStarted ->
        if (isStarted) this else emptyFlow()
    }
}

With that, you can then at use site simply do this:

someFlow.whileStarted(lifecycle).collectAsState()

You can even go one step further and make an extension named collectAsStateWhileStarted(lifecycle).

I find this neater and more scalable than tangling your composable code with the activity bound onStart and onStop where you keep the Job in a var. What do you think?

[louiscad]

Also, maybe a collectAsStateWhileStarted @Composable function might not even need the Lifecycle parameter if it can be retrieved via the ambients.

[John O'Reilly]

@louiscad changes I ended up making were to move from using StateFlow in ViewModel to use asLiveData() and then observeAsState() in Compose code....this has provided exactly behaviour I needed (ensuring I don't keep polling if app goes in to background). I'm also a little reluctant to pull in another library for this if possible but will take a closer look at splitties.

[louiscad]

You can copy paste what is in Splitties, the isStartedFlow function fits in a small file with only dependencies to kotlinx.coroutines and AndroidX Lifecycle.

[John O'Reilly]

k, thanks...will definitely take a look...be great though if this was behaviour that could be included in Compose (assuming it made sense)

[louiscad]

I think the best would be to have it in a platform independent way (not relying on androidx.lifecycle` so it can work on other platforms such as #compose-desktop)

[John O'Reilly]

yeah, that's a good point too

[louiscad]

That means Compose would need to abstract the different kinds of lifecycles. I'd think the paused/resumed and started/stopped states of Android translate well to desktop where part of the window is visible or not, but folks might want more granular control though.

I'm wondering if there's already been considerations about that and API desing concerns.