IssueTracker

Project: platform/frameworks/support
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

https://android-review.googlesource.com/2649119

PointF was the main (possibly only) mutability issue, marking this as fixed

Hi, how does it look with SwipeToDismiss for M3? Only this force me to use complete M3 lib. Please can somebody point me how to use SwipeToDismiss in M3? Thanks

⌛ Waiting...

Question for Google devs: I see Pull-To-Refresh component has been added to Material2 but NOT Material3, so I'm wondering what is an actual priority and future development plan for these 2 libraries? As someone who started a project on Material3, and already missing both  BottomSheet and now a Pull-To-Refresh component, I'm really second guessing my choices and wondering if even future projects should be started on Material3, since even NEW stuff is being implemented on Material2..

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?

Project: platform/frameworks/support
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

https://android-review.googlesource.com/2282010