Status Update
No update yet.
Comments
f....@gmail.com
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
f....@gmail.com
ni...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.graphics:graphics-shapes:1.0.0-alpha04
ma...@google.com
Assigning to Max, it might be a good task to start rumping up on APIs
ma...@google.com
Experimented with adding Start alignment but it conflicts with the hamburger menu in the bottom bar. Can we get UX to weigh in on how/if we can work around this? If we decide to support this, it'll most likely require an update to the Material spec
ay...@google.com
Hey Max, nice work!
Can you explain why this adopter is looking to have a left aligned FAB? That information will help me evaluate if this pattern is an acceptable user experience and where the hamburger menu could be placed.
ma...@google.com
I believe the user has explained the use case as well as provided a screen shot in
f....@gmail.com
As someone named Max myself, I'd also like to say nice work to my fellow Max for the progress on this.
To explain the use case further, I am presenting numerical data on the 'end' side of the bottom sheet, which naturally leaves space on the 'start' end and makes it awkward to place the FAB anywhere else (I have tried). I've attached a screenshot with the FAB in the Start position as I intend. In landscape mode, as you can see, it becomes even more critical to place the FAB at the start because the vertical space is at a premium.
Another point is, assuming a right handed user using their thumb in portrait mode, it's actually a lot easier to tap a FAB on the lower-left hand side of the screen, than one on the lower-right hand side. So IMO the FAB position should be allowed on either side of the screen.
Regarding the hamburger menu, can it just stay at the top left in this case? I don't see how the ability to place a hamburger menu on the bottom left implies that it should be impossible (using the API) to place a FAB there instead.
ay...@google.com
Hey all, apologies for the lag time on my end. This is an acceptable modification for the FAB given the content in the bottom sheet.
ma...@google.com
Hey Ayan, can you clarify the expected behavior of the screenshot in
ay...@google.com
Sorry I missed your question in #6, Max!
One alternative solution is swapping the start placement for the hamburger menu (and icon) to the right. This could result in awkward UX, so I wouldn't advise we add this use case to spec.
se...@google.com
ap...@google.com
Branch: androidx-main
commit cc2b03e66b081b4b7425e58fdb1fc9209acace9a
Author: Max Alfonso-Ying <maxying@google.com>
Date: Wed Jun 14 19:18:03 2023
Add 'Start' position for FabPosition
Relnote: Added new Start alignment for FabPosition
Fixes:
Test: ScaffoldTest, BottomSheetScaffoldTest, ScaffoldScreenshotTest
Change-Id: Ib7aea97d6ac5c6ee33fd10916c74c540ff5889de
M compose/material/material/api/current.txt
M compose/material/material/api/restricted_current.txt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/BottomSheetScaffoldTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/ScaffoldScreenshotTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/ScaffoldTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/BottomSheetScaffold.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/Scaffold.kt
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/src/androidAndroidTest/kotlin/androidx/compose/material3/ScaffoldTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/Scaffold.kt
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material:material:1.6.0-alpha02androidx.compose.material:material-android:1.6.0-alpha02androidx.compose.material3:material3:1.2.0-alpha04androidx.compose.material3:material3-android:1.2.0-alpha04
Description
Hi, I just migrated to the Compose implementation of
BottomSheetScaffoldtoday, but found I couldn't place the FAB on the left side of the screen using thefloatingActionButtonPosition=argument ofBottomSheetScaffold.In my app, the FAB needs to be placed on the left side of the screen and can't be placed on the right or in the middle, as you can see in the screenshot.
So I would like to request that a 'Start' position is added to the FabPosition enum.
Thank you.