https://kotlinlang.org logo
Join Slack
Powered by
What about `remember` function? What happens with ...
# compose
i
What about 
remember
function? What happens with remembered value when composable leave the composition? For exapmle
Copy code
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?
I want to find a kind of callback or event when composition scope ceases to exist
To close screen dependent dependencies
p
i
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)
z
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)
➕ 1
i
got it, thanks
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
z
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.
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
i
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
z
but inside onDestroy callback, not inside onStop
Why?
(Also, i didn’t mean necessarily androidx ViewModel, just the layer above the view layer – presenter or whatever)
i
Because i don't want to reload pages when i returned to it, but want to first load on create
I have "viewmodel", but i must drop it when screen doesn't exists anymore
I can handle this with androidx viewmodel though
There is Composable viewModel() that destroys when on destroy be called
So i can wrap anything with it
And handle closing in view model onClose or whatever
i
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.
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)
6 Views
Open in Slack
PreviousNext
Powered by