Fixed
Status Update
No update yet.
Comments
ma...@google.com
ar...@physitrack.com
Does this happen if you temporarily remove/disable the pull-refresh part?
ha...@gmail.com
an...@sigma.software
Here is screen recording with pull refresh removed from grid content modifier. AppBar color animation on scroll no longer blocked, but when I call gridState.scrollToItem(0) by clicking scroll to top button, it's color not changed unless I pull content down manually.
ma...@google.com
co...@google.com
ap...@google.com
We're facing the same issue with TopAppBar and TopAppBarDefaults.pinnedScrollBehavior. When scrolling quickly on a lazy layout, the app bar container color does not respond.
Repo:
Video:
val scrollBehavior = TopAppBarDefaults.pinnedScrollBehavior()
Scaffold(
modifier = Modifier
.fillMaxSize()
.nestedScroll(scrollBehavior.nestedScrollConnection),
topBar = {
TopAppBar(
title = {
Text(
modifier = Modifier.fillMaxWidth(),
text = "Hello!",
textAlign = TextAlign.Center,
)
},
scrollBehavior = scrollBehavior,
)
},
) { innerPadding ->
LazyColumn(
modifier = Modifier.padding(innerPadding),
contentPadding = PaddingValues(16.dp),
verticalArrangement = Arrangement.spacedBy(8.dp),
) {
items(100) {
Text(
text = "Item $it",
modifier = Modifier
.fillMaxWidth()
.background(MaterialTheme.colorScheme.surfaceContainerHigh)
.padding(24.dp),
)
}
}
}
Description
I've been testing the new PullToRefresh implementation in M3 and finding a number of issues, both functional and API ergonomics.
1. No exit animation when
endRefresh()is calledThis one is fairly straightforward and visible in the attached example. I would expect this to animate the progress indicator back to rest.
2. The indicator is always drawn above the content, including on top of other content
This is more serious bug, as it results in what looks like a floating artifact in the UI. The indicator implementation seems to assume that the container is always pushed up against the top of the display, and thus wouldn't worry about drawing the indicator. However, when used in even simple scaffolds with a top app bar of some sort, it will draw the indicator (even when not refreshing) on top of the app bar. This is visible in the attached examples as well.
3. The container intercepts upward scroll events in nested scrolling conditions
This is visible in the attachment as well. In a scaffold with a collapsing/moving top bar, the container will actively intercept upward scroll events in some cases and prevent expansion of the top app bar.
4. The API is awkward and a regression from the M2 implementation
The M2 implementation offered an
onRefresh: () -> Unitcallback that made using this dead simple. It also better aligned with what this UI ultimately is - a glorified refresh button implemented as a gesture. In the new M3 API, there is no such hook. Instead, one has to directly observe theisRefreshingboolean state. In simple cases (such as the samples) where the UI is directly suspending/blocking on some refresh call to the data layer, this works ok. However, it quickly breaks down when interacting with more real-world cases where a refresh event is signaled to the data layer (such as viaLazyPagingItems.refresh()) and awaiting an updated load state.The result is that the user has to manually implement this synchronization of states. If it's refreshing but the pager load state isn't loading, you now have to independently track if
I've attached a screenshot example of what this synchronization tedium looks like in practice