After adding an `AbstractComposeView` to our app, ...

# compose

[saket]

After adding an AbstractComposeView to our app, I’m noticing that my states aren’t getting saved (using rememberSaveable) when the view is detached from window. I’m trying to investigate this for some time but I haven’t reached anywhere. How can I investigate what might be happening?

[saket]

I haven’t changed the default setViewCompositionStrategy which is DisposeOnDetachedFromWindow.

[Andrey Kulikov]

if you have multiple `AbstractComposeView`s in one Fragment/Activity they should have unique ids so they can save their states in a bundle correctly

[saket]

yep, I’m already setting a unique ID to my AbstractComposeView

[saket]

fwiw state restoration is working as expected when my screen is recreated due to a config change (like the system theme) but not when I navigate to another screen — which makes me suspect if there’s something our navigation system is messing up. but I’m finding it hard to find out what.

[Ian Lake]

Is your navigation system fragment based? Or custom view based?

[Ian Lake]

Because if it is fragment based, DisposeOnDetachedFromWindow is always too early, as per the docs: https://developer.android.com/jetpack/compose/interop/interop-apis#composition-strategy

[Ian Lake]

Same for if you are using Transition

[Ian Lake]

If it is custom view based, then it would be up to you to manually save the state of the View before detaching it from the window, then manually restore the view state when you return to that screen (this is what fragments does for you, FWIW)

[saket]

Our navigation system is view based and state restoration is working as expected for all non-composable screens so far. For instance, I’ve verified that my AbstractComposeView implementation’s onSaveInstanceState() is getting called. Is there anything else I can check?

[saket]

we’re still using compose 1.0.1 if it matters

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

Does your navigation system support SavedStateRegistry? Compose uses that instead of instance state

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

We had to do a ton of work to support compose state restoration in workflow, which is also view-based.

[saket]

Does your navigation system support SavedStateRegistry? Compose uses that instead of instance state

I think it does because LocalSaveableStateRegistry.current is non-null?

[saket]

why did workflow require special changes for state restoration to work if the host Activity already provides a saved state registry?

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

Because the activity's saved state registry saves state when the activity goes away*, and restores it when the activity comes back. Your navigation framework probably makes manual calls to save/restoreHierarchyState, it needs to also manually save and restore child registries for each of its screens.

*Technically it saves it more often, but since it's only restored when the activity is restored it effectively only hangs onto the last saved state before it goes away.

[saket]

oooh that makes sense. I think I understand the problem now. We’ll have to manually dispatch state saves then. Your article was very useful, thank you!

[saket]

on a second thought, I checked that my composition is getting disposed when my view is detached from window. shouldn’t that trigger a state save? or are disposals and state saves decoupled from each other?

[Ian Lake]

The whole thing is that you need to save state before the composition gets disposed

[saket]

got it. thanks both of you!