IssueTracker

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3328184

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling 
 
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component. 
 
Fixes: b/266550551 
Fixes: b/204650733 
Fixes: b/255554340 
Fixes: b/229537244 
Test: OverscrollTest 
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering  overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere." 
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.8.0-alpha06
• androidx.compose.foundation:foundation-android:1.8.0-alpha06
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06

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?