[Material3] Add shadowElevation parameter to SearchBar [271040353]

Fixed

Feature Request

Status Update

No update yet.

Description

dp...@phunware.com

created issue #1

Mar 1, 2023 05:35AM

Jetpack Compose version: 1.1.0-alpha07 Jetpack Compose component used: Material3

As described in the Material3 Guidelines, shadow elevation should be used to separate components from patterned or busy backgrounds.

https://m3.material.io/styles/elevation/applying-elevation

When to use visible shadows

Protect elements

When a background is patterned or visually busy, 
the hairline style might not provide sufficient protection. 
In these cases, use elevation to separate and emphasize elements 
such as cards, chips, or buttons, as in the image below.

The SearchBar component already supports tonal elevation, but if we need to use it on a busy background (like over a map view, for example), that's not enough to protect the component and indicate separation.

The Surface component already supports a shadowElevation parameter and some other components that use Surface also already have that parameter that they pass down to the underlying Surface, like the ListItem component.

Can we please do the same for the SearchBar component? Simply adding a shadowElevation parameter and passing it to the shadowElevation of the Surface is enough to fix this. I copied the SearchBar component and tested the change and it worked fine.

Thanks.

Comments

ma...@google.com <ma...@google.com> Mar 2, 2023 04:34PM

Reassigned to ma...@google.com.

ma...@google.com <ma...@google.com> Mar 2, 2023 05:42PM

Accepted by ma...@google.com.

ab...@google.com <ab...@google.com> #2Mar 8, 2023 11:16PM

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

dp...@phunware.com <dp...@phunware.com> #3May 10, 2023 10:01PM

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

ma...@google.com <ma...@google.com> May 31, 2023 03:08PM

Marked as fixed.

ap...@google.com <ap...@google.com> #4May 31, 2023 03:08PM

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

pr...@google.com <pr...@google.com> #5Jun 21, 2023 08:57PM