What about `remember` function? What happens with remembered value when composable leave the composi...

# compose

[iamthevoid]

What about remember function? What happens with remembered value when composable leave the composition? For exapmle

if (loading) {
    Loading()
} else {
    View(someLogic::calculateParam) // here inside remember 'someLogic::calculateParam' result has called 
}

For example on next composition composition loading is true, on next one false. In log i see that calculateResult changes, but what happens with previous? Is anywhere strong reference to it?

[iamthevoid]

I want to find a kind of callback or event when composition scope ceases to exist

[iamthevoid]

To close screen dependent dependencies

[ppvi]

https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#DisposableEffect(kotlin.Any,kotlin.Function1)

[iamthevoid]

DisposableEffect disposes even when view goes from screen, but alive (onStop) (below in stack, or just another tab in bottom navigation). I’d close scope when view absolutely close (onDestroyView)

[Zach Klippenstein (he/him) [MOD]]

I want to find a kind of callback or event when composition scope ceases to exist

and

I’d close scope when view absolutely close

are different things. If you want to take some action when a composable leaves the composition, use an effect. If you want to observe the underlying lifecycle, use LocalLifecycleOwner. But if you observe the lifecycle from a composable that leaves the composition before the lifecycle state changes, your observer won’t see the lifecycle changes (since it will have already been removed from the composition and removed as a lifecycle observer)

[iamthevoid]

got it, thanks

[iamthevoid]

Can you give me an example of when it can happen? If i use LocalLifecycleOwner only with Jetpack Compose Navigation, should i care about it? Looks like navigation handle lifecycle enough

[Zach Klippenstein (he/him) [MOD]]

If you’re trying to manage dependencies for the screen, it’s probably best to just use the simple composition hooks. It’s simpler, and makes your code more testable (because tests don't need to inject a custom lifecycle) and portable, because the dependencies will be correctly managed even if in the future things are moved around and need to be scoped to something smaller than the navigation frame.

[Zach Klippenstein (he/him) [MOD]]

If you’re trying to keep the resources between individual composables coming and going, eg because they’re expensive to initialize or something, then the composables might be the wrong owners and they should be managed by a view model or something

[iamthevoid]

I want to manage dependencies, but don't want lean on view model, because i have kmm project and want to unify mechanisms between ios and Android. So i have scopes for each feature and want somehow provide this scope to Composable (remember) and close it, but inside onDestroy callback, not inside onStop

[Zach Klippenstein (he/him) [MOD]]

but inside onDestroy callback, not inside onStop

Why?

[Zach Klippenstein (he/him) [MOD]]

(Also, i didn’t mean necessarily androidx ViewModel, just the layer above the view layer – presenter or whatever)

[iamthevoid]

Because i don't want to reload pages when i returned to it, but want to first load on create

[iamthevoid]

I have "viewmodel", but i must drop it when screen doesn't exists anymore

[iamthevoid]

I can handle this with androidx viewmodel though

[iamthevoid]

There is Composable viewModel() that destroys when on destroy be called

[iamthevoid]

So i can wrap anything with it

[iamthevoid]

And handle closing in view model onClose or whatever

[Ian Lake]

Note that there's an open issue for a 'permanently destroyed' signal (https://issuetracker.google.com/issues/177562901) that would only be called when the state is destroyed, but the tl/dr is that Compose doesn't support this. DisposableEffect is the only cleanup available in Compose only code.

[Ian Lake]

If you're using Navigation Compose, we do provide this signal through the onCleared() of every ViewModel you create at the screen / navigation graph level (and also handles the configuration changes case for you as well)