https://kotlinlang.org logo
Join Slack
Powered by
I've been playing around with the new NavHost. But...
# compose
r
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?
z
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.
👍 2
Leland also hand-waved about the concept of “low-priority” composables the other day, so they could stay in the composition even when not active.
r
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? 🤔
About the "low-priority", that kinda smells like the complicated fragment lifecycles where the view gets destroyed but not the fragment 😟
z
i don’t think it’s abusing them, i think it’s exactly what they’re there for
views go away and then come back, and need to save/restore state when they do. Whether that’s because an activity got destroyed, or because some internal navigation framework changed screens, doesn’t matter.
i
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
r
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
a
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.
z
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).
a
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.
z
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.
a
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.
Having all tabs in the composition tree seems like it could work for state restoration, but that also seems like it could have it's own issues with extra work in the "inactive" tabs.
But I guess that's something a low priority composable would be able to fix :)
t
@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?
Just to be clear the composition will be disposed during screen switching
z
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.
However if you want to remove tabs from the composition, the tab host just needs to provide the registry as an ambient, and then invoke the save and restore calls at the correct times.
4 Views
Open in Slack
PreviousNext
Powered by