Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
jo...@veeva.com <jo...@veeva.com> #2
Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <
Link:
Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling
Expand for full commit details
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
Files:
- M
compose/foundation/foundation/api/current.txt
- M
compose/foundation/foundation/api/restricted_current.txt
- M
compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/OverscrollDemo.kt
- M
compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/OverscrollSample.kt
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/OverscrollTest.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Overscroll.kt
Hash: f64e25b7a473c757d080521e7dd97b3f6670f60d
Date: Fri Nov 01 18:43:56 2024
ar...@physitrack.com <ar...@physitrack.com> #3
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
ha...@gmail.com <ha...@gmail.com> #4
How did this implementation get through the review? It violates such basic principles as state hoisting and is simply much worse to use than the M2 variant.
an...@sigma.software <an...@sigma.software> #5
It's impossible to migrate to M3 pull to refresh if you're using M2. API is so narrowly designed to just run async OPs directly inside @Composable functions so that you can call endRefresh() in the end. If you have adequate (can't find more suitable word) codebase with ViewModels, there is literally no way to control refresh state using outer state. It's such a terrible release that only wastes developers time to try it out and disappoint.
ma...@google.com <ma...@google.com>
co...@google.com <co...@google.com>
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
commit a1154475dd101bcf9867c11ceb567f9511dc7c1c
Author: Mariano Martin <marianomartin@google.com>
Date: Fri Apr 05 12:00:06 2024
[PullToRefresh] Update Material 3 PullToRefresh APIs
Test: updated existing tests
Fixes: 314496282, 317177684, 323787138, 324573502, 317177683
Relnote: "New pull-to-refresh APIs:
- Simplified PullToRefreshState to use fractional values instead of Dp units.
- isRefreshing state is controlled by the user instead of PullToRefreshState.
- Separated out the nested scroll connection from PullToRefreshState. It is handled by the new PullToRefreshBox or Modifier.pullToRefresh.
- This update is a breaking change to previous experimental APIs."
Change-Id: I0adeb950063988d1a05aca7aa135ccd982431423
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/integration-tests/material3-catalog/src/main/java/androidx/compose/material3/catalog/library/model/Examples.kt
M compose/material3/material3/integration-tests/material3-demos/src/main/java/androidx/compose/material3/demos/PullToRefreshDemo.kt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/PullToRefreshSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/pulltorefresh/PullToRefreshIndicatorScreenshotTest.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/pulltorefresh/PullToRefreshIndicatorTest.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/pulltorefresh/PullToRefreshStateImplTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/pulltorefresh/PullToRefresh.kt
https://android-review.googlesource.com/3029663
Branch: androidx-main
commit a1154475dd101bcf9867c11ceb567f9511dc7c1c
Author: Mariano Martin <marianomartin@google.com>
Date: Fri Apr 05 12:00:06 2024
[PullToRefresh] Update Material 3 PullToRefresh APIs
Test: updated existing tests
Fixes: 314496282, 317177684, 323787138, 324573502, 317177683
Relnote: "New pull-to-refresh APIs:
- Simplified PullToRefreshState to use fractional values instead of Dp units.
- isRefreshing state is controlled by the user instead of PullToRefreshState.
- Separated out the nested scroll connection from PullToRefreshState. It is handled by the new PullToRefreshBox or Modifier.pullToRefresh.
- This update is a breaking change to previous experimental APIs."
Change-Id: I0adeb950063988d1a05aca7aa135ccd982431423
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/integration-tests/material3-catalog/src/main/java/androidx/compose/material3/catalog/library/model/Examples.kt
M compose/material3/material3/integration-tests/material3-demos/src/main/java/androidx/compose/material3/demos/PullToRefreshDemo.kt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/PullToRefreshSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/pulltorefresh/PullToRefreshIndicatorScreenshotTest.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/pulltorefresh/PullToRefreshIndicatorTest.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/pulltorefresh/PullToRefreshStateImplTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/pulltorefresh/PullToRefresh.kt
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: () -> Unit
callback 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 theisRefreshing
boolean 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