Hello, people from Flutter made an extensive document about state restoration and their plans (since it's not supported natively yet). When it comes to Jetpack Compose, I've not seen much about facilities to ease state saving (yet), so I'm wondering if that document could help shape the APIs that we can use to support state restoration easily. Here it is: https://flutter.dev/go/state-restoration-design

Compose supports state restoration via the

savedInstanceState

function - what else do you need?

An example with text input, a slider, and a list.

Just take any existing example that uses

state

and replace

state

with

savedInstanceState

.

I think I now see how it'd work, interesting

I think

RestorationManager

in this doc roughly corresponds to

UiSavedStateRegistry

,

RestorationId

to whatever key is used for

savedInstanceState

(the positional memoization key by default), and

RestorationScope

to the ambient that holds the

UiSavedStateRegistry

.

One other thing we've talked about doing not just for saved state but for other types of stable composition scope keying is some sort of

Path("key") { }

nesting that I think roughly parallels the nested bucket approach described here

Something that'd really like is to be able to swap system savedInstance state by a custom alternative, very easily, that could then send those values over, for something like Handoff on iOS & macOS. That could also be used to sync reading position or alike, and have some state persist when coming back.

Interesting, I could see that falling out of some natural interface layering we'd want anyway for testing/etc.

The Handoff use case seems like you could do with a custom function similar to

savedInstanceState

. You'd have to explicitly call that function instead of magically swapping it in, but it seems like the behavior would be different enough anyway (what Adam said, two way syncing?, Etc) that the opt-in would be safer.

I was thinking there'd be two things: 1. Configuration and initialization of the

savedInstanceState

substitute (which might involve a suspending logic, and "linking" to an error handling logic) 2. Explicitedness about the actual key use for saving some data, to allow long term storage (i.e. not limited to the app version), without conflicts For merging, I was thinking it'd be something to handle in the logic of the

savedInstanceState

substitude.

@Zach Klippenstein (he/him) [MOD] There always has been but it's been pretty raw to use. This just went in and should make it easier https://android-review.googlesource.com/c/platform/frameworks/support/+/1326201

and yes, you can provide your own

UiSavedStateRegistry

with an ambient where you can do your own saving and restoration as it is nicely abstracted

Are there composables from androidx.ui or other first party lib(s) that already use

UiSavedStateRegistry

?

yes, text fields and scrollers are saving the state already

Thank you very much for your answers, I think I'll experiment with persisting state periodically later this summer (but not do I/O on the main thread ⏸️ )

I’ve got a proof-of-concept project that uses the saved state registry manually: https://github.com/zach-klippenstein/compose-backstack/blob/5fe89af17b9dc48ee28bea3e95c020ce353ff31b/compose-backstack/src/main/java/com/zachklipp/compose/backstack/ChildSavedStateRegistry.kt (thanks to @grandstaish for fixing my bugs 😅)