I've been playing around with the new NavHost. But I'm wondering: if it completely replaces the composable, how are we gonna keep the scroll position 🤔 Right now it seems to lose it. I'm also not sure about passing arguments. The api doesn't seem to support it?

I think the general plan is for scrollable composables to store their scroll position in a

rememberSavedInstanceState

, and then whatever navigation framework you’re using just needs to support that API.

But a composition getting disposed is not the same as passing through the saved instance cycle. Won't that be kind of abusing framework APIs? 🤔

i don’t think it’s abusing them, i think it’s exactly what they’re there for

I like the excitement, but the CLs aren't even landed, much less in a dev release. I don't think it is useful to be extrapolating anything about the in-progress state

I know, sorry about that. I'm very excited seeing compose grow and where it is headed. Really looking forward to write apps with it

Any links to the mentions of "low priority" composables? I've experimented a bit with navigation and it seems like there is currently no "nice" way to automagically handle saved state across compositions, maybe other than abusing

Stack

. Just curious if there are any ideas how a possible implementation might look.

I think using saved instance state should "just work" assuming the navigation framework you're using supports it correctly, and you're actually using it to save state (or the components you're using are using it, as in the case of eg scrollers that hold their own state info).

The part I'm a bit confused about is how it might be implemented to support that correctly in a navigation framework. Because it seems to me that it would entail either keeping compositions "not disposed" in some way, or to change how UiSavedStateRegistry is provided and both seem like pretty big undertakings.

change how UiSavedStateRegistry is provided

Why do you think this is necessary? It’s very possible to provide support for this already, and not that hard either.

My understanding is: if you have some form of

Flow<Screen>

to represent a currently active tab, the other tabs would not be in the composition tree so their state would not be saved/restored. When navigating to a new tab Compose wouldn't really automatically know then whether to start with a fresh state or try to restore a previous one afaik.

@Zach Klippenstein (he/him) [MOD] i am also interested in this topic. Currently i save the scroller positions in an business logic object to make sure the positions is not lost after switching to other screens. So i would love to integrate some savedInstanceState solution in my navigation code. But i do not know how. So how is it possible to store the savedInstance state of a composition and later restore it?

The simplest thing is definitely to just leave the inactive tabs in the composition. If those tabs are doing “work”, you could design the tab system to pass an “isActive” flag to each tab that it could use to opt-out of expensive things when it’s not being shown.