Status Update
No update yet.
Comments
il...@google.com
an...@google.com
Triage notes: Still P3, still a real issue. Compat issue.
il...@google.com
Personally, I think the question of 'how do I know when my rememberSaveable is being thrown away' might be an interesting avenue to pursue. Even just having a callback that is triggered when it is being explicitly thrown away via saveableStateHolder.removeState would remove the need for client code to rely on ViewModels for this type of case.
In the Architecture Components world, this is also precisely why SavedStateRegistryOwner implements LifecycleOwner - the onDestroy() there would be the correct place to check whether activity.isChangingConfigurations() (which is what onDestroy(), the state is not coming back, which would be the other where triggering an explicit state destruction might be helpful.
an...@google.com
```
rememberSaveable(onFullyDisposed = {
obj.doCleanUp()
}) { mutableStateOf(0) }
```
when you go to the next screen and the current one is kept in the backstack this composable will be disposed. but we will have to store the passed lambda somewhere, right? and lambdas are not serializable so if the activity will be recreated because of the screen rotation we will not have lambdas associated with the screens in the backstack as they were not composed yet after the activity recreation.
plus this can cause memory leaks:
```
val obj = remember { LeakingObject() }
val list = rememberSaveable(onFullyDisposed = {
obj.doCleanUp()
}) { mutableListOf<Int>() }
```
we keep the link to LeakingObject longer than its lifetime
2) saveableStateHolder.removeState is not the only way to fully dispose. in simple cases there is no navigation library used and no SaveableStateHolder at all. In this case we should use activity onDestroy?
sj...@gmail.com
This is an interesting use case that I would like to emphasize. Trying to get rid of the AAC ViewModel dependency in my code, the only thing that I'm currently missing is to provide an instance of a class (and an encapsulated coroutine scope) that survives configuration changes and thus is suitable for starting long running coroutine operations. In terms of user experience long running operations like a save for example should not be aborted when the user rotates the device. This is something that AAC ViewModels support but as far as I understand plain Jetpack Compose does not at the moment. Or at least not with a lot of error-prone boiler plate code.
il...@google.com
ka...@gmail.com
Any progress on this issue? The issue is almost 3 years old and it is blocking the usage of any other architecture with compose. To achieve this now I can write a lot of boiler plate code and do the following for every screen:
class OnClearedViewModel : ViewModel() {
override fun onCleared() {
super.onCleared()
// here write desired code
}
}
al...@google.com
From triage meeting, this seems related to rememberRetained so it probably should stay on Adam? May also intersect with TikTok (not that one) work.
al...@google.com
Triage notes: We still want to do rememberRetained, which is related, and there should be a separate bug for that. There's complexity with handling duplicates, and we'd need some unique identifier -- the composition hash code isn't a guarantee given the likelihood of collisions in int space. Needs a design discussion offline.
al...@google.com
Triage notes: In the design stage. We'll be using this as the canonical bug for rememberRetained.
Description
Component used: Jetpack Compose Version used: alpha 1.0.9
I would like to have an Effect for when a composable is fully destroyed. As pointed by Ian Lake, it would probably be the callback for when the compose version of RestorableStateProvider removes the state of the composable and deletes it for good (as inhttps://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt;l=162 ).
Ideally I would also want its analogous that would be called when the state was created, and only once for each deletion. So, if the composable is added and removed but its state is not cleared, this effect would not be triggered again.
So, in the same way that we have DisposableEffect that matches the composition lifecycle, I would like another effect that matches the full life of a composable.
My usecase is that I want to achieve the same behaviour as the Android ViewModel without having to use a ViewModel. The ViewModel is created when the user first navigates to a screen and it is not disposed as long as the view stays on the backstack. It is only disposed/cleared when its state no longer needs to be remembered -i.e. the view is removed from the backstack.
Currently I use
rememberSavedInstanceStatefor the creation callback, and I rely on the navigation component for the destruction callback. The first is hacky, and the second is far from ideal as I depend on the navigation framework.