Status Update
Comments
ti...@google.com <ti...@google.com> #2
Related to this, there seems to be another issue with this setup: if I set a nestedScroll
modifier that consumes all the available scroll in the scrollable column inside, this should take precedence over the swipe gesture in the BottomSheetScaffold
, but that's not the case, the bottom sheet swipe gesture consumed the scroll.
However, I tried duplicating the BottomSheetScaffold
implementation and switched the anchoredDraggable
modifier, DraggableAnchors
and other M3 APIs with their equivalents in the Foundation library, and then it worked as expected. The code in androidx.compose.material3.AnchoredDraggable
has this comment:
/**
* This is a copy of androidx.compose.foundation.gestures.AnchoredDraggable until that API is
* promoted to stable in foundation. Any changes there should be replicated here.
*/
So it seems like both APIs are interchangeable, but either the M3 ones aren't up to date with the changes in foundation or its implementation has differed and has this bug.
ti...@google.com <ti...@google.com> #3
Maybe someone has nice workaround?
ap...@google.com <ap...@google.com> #4
Branch: androidx-main
commit bbd9f1020330ba0373d7588091578aa678239d4b
Author: Max Alfonso-Ying <maxying@google.com>
Date: Fri Mar 29 19:05:03 2024
Fix BottomSheetScaffold nested scroll when sheet gestures disabled
Fixes:
Test: added unit test
Relnote: "`BottomSheetScaffold` will no longer scroll from nested scroll if `sheetSwipeEnabled` is false"
Change-Id: I5e1c1adb83167184f2baa4457cf1b3c70272a72c
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/BottomSheetScaffoldTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/BottomSheetScaffold.kt
ti...@google.com <ti...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha05
androidx.compose.material3:material3-android:1.3.0-alpha05
androidx.compose.material3:material3-desktop:1.3.0-alpha05
Description
After offline discussion with Adam we came up with the good idea around AnimaitonDecaySpec and the level of granularity we might want to add.
Basic idea: Let's split AnimationDecaySpec into two abstractions: one will be an per-animation-run "Info" thing that, and the other will allow creation of this "info" things for any particular animation given some input.
Detailed information: Let's split
AnimationDecaySpec
into two things:the API of this will be similar to what we have right now in AnimationSpec, BUT with one big difference: you already have all the knowledge about this particular occurrence of the animation, so you don't need to remember what was your entrypoints (start position, start velocity, etc).
Given that,
will become
and similar with other methods.
(Names are TDB of course).
What this separation gives us: This granularity brings clear separation of concerns and knowledge: one thing lives for a long time and hosts somewhere higher lever (in components, states) and it's generated "Info" objects can flow into lower level abstraction that are one-time fired (such as
AnimatedFloat.fling
oranimateTo
).Additionally, I would suggest to rename Decay to Fling (or just make it part of plain animations api) everywhere because:
For the reference and initial idea: take a look here
Going forward, we can try to stretch this idea to the whole animation, and not only decay/fling part.
Doris, I'd like to know your opinion on this.