IssueTracker

Hi Alex, that link is for Androidx source code, could you please share your video?

This is because in the sample we are using remember, whereas list state is using rememberSaveable internally, which persists config changes.

I wonder if it is possible for us to infer the nested scroll based on just the list scroll, so that when we create the new scroll behavior on rotation we start with the app bar in the correct position - this seems more friendly than making users use rememberSaveable here

Andrey, curious if you have any thoughts here - for classes relating to list state, like in this case app bar behavior, should we just always be encouraging using rememberSaveable for consistency with the list / scroll state?

The issue exists in the current material catalog app (which is the code I linked too) so I figured they could just use that to reproduce it (since all you have to do is go to the top app bar screen in the catalog demo app, scroll the screen container, and then rotate the screen). But I could also create a standalone separate Android Studio project with the same code as what is in the material catalog app if that is the preferred format.

LazyListState knows nothing about how other participants of nested scrolling mechanism used the unused deltas. So you will not be able to get this info from the restored LazyListState. So remember { TopAppBarDefaults.pinnedScrollBehavior() } is the only source of truth for such info and if it is desired to be able to restore its state it should have rememberSaveable.

Also note that it is in fact not only about restoration after screen rotation. Does AppBar display the state you want it to when you initialise LazyColumn with not 0 offset straight away? I mean something like

LazyColumn(state = rememberLazyListState(initialFirstVisibleItemIndex = 2, initialFirstVisibleItemScrollOffset = 10))

In response to comment #3...

I think there would still be a problem using rememberSaveable though. Because for example consider:

1. You start out in landscape in a list screen
2. You scroll down a tiny bit in the list screen causing the top app bar to animate its color
3. You rotate the device to portrait (and let's assume the list is small enough such that the entire list is shown, making the list no longer scrollable).

The desired behavior here would be that the top app bar would switch back to its initial state since the scroll position in portrait has now become 0, right?

So seems like there would need to be some way to have the top app bar and scroll position linked somehow...

The main part of this issue was fixed, and we made changes to the API to support it.

Example usage:

val scrollBehavior = TopAppBarDefaults.pinnedScrollBehavior(rememberTopAppBarScrollState())
SmallTopAppBar(
    ....
    scrollBehavior = scrollBehavior
) ...

We may still have issues with cases mentioned at #comment7, but those should probably be addressed on a separate ticket.

Does it make sense to create a separate issue to track the remaining bug?