Status Update
Comments
de...@gmail.com <de...@gmail.com> #3
Does this happen if you temporarily remove/disable the pull-refresh part?
jo...@google.com <jo...@google.com> #4
jo...@google.com <jo...@google.com>
de...@gmail.com <de...@gmail.com> #5
sy...@gmail.com <sy...@gmail.com> #6
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),
)
}
}
}
se...@google.com <se...@google.com>
se...@google.com <se...@google.com>
gl...@gmail.com <gl...@gmail.com> #7
I am facing the same bug and i think the root case for it is that the PinnedScrollBehavior
doesn't override the onPostFling
in its NestedScrollConnection
implementation.
I made a crude simple custom version and added
override suspend fun onPostFling(consumed: Velocity, available: Velocity): Velocity {
if (available.y > Velocity.Zero.y)
state.contentOffset = 0f
return super.onPostFling(consumed, available)
}
and then it works fine for me!
se...@google.com <se...@google.com> #8
Project: platform/frameworks/support
Branch: androidx-main
Author: Shalom Gibly <
Link:
Fix the app-bars behaviors to detect end of scroll
Expand for full commit details
Fix the app-bars behaviors to detect end of scroll
Apply a fix to all the behaviors to detect the end of scroll in the post
fling function. This will better ensure an app-bar color change when the
content is scrolled all the way.
Bug: 293665988
Test: Manual
Relnote: "Fix the top and bottom app-bar behaviors to reliably change
color when content is scrolled all the way."
Change-Id: Idc4e834695cbd7cb8099f7b63cf21d5b764f1c81
Files:
- M
compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/AppBar.kt
Hash: 792c8cdf7db425c674de1214e60c7d01f46e9750
Date: Mon Nov 25 06:03:57 2024
ma...@quantox.com <ma...@quantox.com> #9
So the question is, should we actually be starting new projects on Material3 or not? It's even "final" now. And is it really more future proof from the project maintenance perspective?
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit e6892a2153fca43e348b0de7c2614e7bf6cbc708
Author: José Figueroa <serniebanders@google.com>
Date: Tue Nov 01 10:38:11 2022
[Material3][SwipeToDismiss] Update Swipe To Dismiss to M3 library
Updates:
* Threshold calculation simplified and moved to DismissState.
* SwipeableState inheritance moved internally, with relevant parameters exposed to DismissState API.
* Splits more complex demo and simple sample code logic.
Test: Forked M2 Unit Tests
Bug: 242889540
RelNote: Implement SwipeToDismiss in Material 3 library.
Change-Id: I458a8e1359896712a2a8aede43e0283977be4601
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/public_plus_experimental_current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/integration-tests/material3-demos/src/main/java/androidx/compose/material3/demos/Material3Demos.kt
A compose/material3/material3/integration-tests/material3-demos/src/main/java/androidx/compose/material3/demos/SwipeToDismissDemo.kt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/SwipeToDismissSamples.kt
M compose/material3/material3/src/androidAndroidTest/kotlin/androidx/compose/material3/SwipeToDismissTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/SwipeToDismiss.kt
se...@google.com <se...@google.com> #11
@marko I can't speak to the PullToRefresh feature as I've not worked on it, but to generally answer your question: I would say that is ultimately your call to make. Personally I would recommend using Material3, as it has a longer window of active development (feature requests, bug fixes, other dev time resources) while the goal is to sunset M2 support over time. However M2 is of course more feature complete at this time.
PullToRefresh is not currently on the M3 radar however you are welcome to file a feature request.
de...@gmail.com <de...@gmail.com> #12
@se...@google.com maybe not so good to post the full mail here?
na...@google.com <na...@google.com> #13
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.1.0-alpha04
Description
Feature Request to add SwipeToDismiss to Compose for Material 3, as it is not recommended to use material components in a Material 3 project according to this ticket .