Thread
#compose
    saket

    saket

    11 months ago
    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?
    I haven’t changed the default
    setViewCompositionStrategy
    which is
    DisposeOnDetachedFromWindow
    .
    Andrey Kulikov

    Andrey Kulikov

    11 months ago
    if you have multiple AbstractComposeViews in one Fragment/Activity they should have unique ids so they can save their states in a bundle correctly
    saket

    saket

    11 months ago
    yep, I’m already setting a unique ID to my
    AbstractComposeView
    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.
    i

    Ian Lake

    11 months ago
    Is your navigation system fragment based? Or custom view based?
    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
    Same for if you are using
    Transition
    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

    saket

    11 months ago
    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?
    we’re still using compose 1.0.1 if it matters
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    11 months ago
    Does your navigation system support SavedStateRegistry? Compose uses that instead of instance state
    We had to do a ton of work to support compose state restoration in workflow, which is also view-based.
    saket

    saket

    11 months ago
    Does your navigation system support SavedStateRegistry? Compose uses that instead of instance state
    I think it does because
    LocalSaveableStateRegistry.current
    is non-null?
    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]

    Zach Klippenstein (he/him) [MOD]

    11 months ago
    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

    saket

    11 months ago
    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!
    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?
    i

    Ian Lake

    11 months ago
    The whole thing is that you need to save state before the composition gets disposed
    saket

    saket

    11 months ago
    got it. thanks both of you!