Full screen search bar is unintuitive - consider using a dialog [283311462]

Fixed

Feature Request

Status Update

No update yet.

Description

ma...@google.com

created issue #1

May 18, 2023 10:05PM

The current implementation uses the same component for the unexpanded search bar and the expanded search view. This makes it hard to use the search bar in the middle of other content, since you have to ensure not to accidentally pass constraints that prevent it from being full screen.

Making the full-screen search view into a dialog would avoid most of these issues.

If there is enough interest (by +1-ing this issue), we could explore the possibility of using this approach.

Comments

ma...@google.com <ma...@google.com> Aug 13, 2024 06:17PM

Accepted by ma...@google.com.

ap...@google.com <ap...@google.com> #2Dec 12, 2024 01:56PM

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

ap...@google.com <ap...@google.com> #3Dec 12, 2024 01:56PM

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

ap...@google.com <ap...@google.com> #4Dec 12, 2024 01:56PM

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

ap...@google.com <ap...@google.com> #5Jan 29, 2025 07:08PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Max Alfonso-Ying <maxying@google.com>
Link: https://android-review.googlesource.com/3460540

Publish new search bar APIs.

Expand for full commit details

Publish new search bar APIs. 
 
Samples have also been updated. 
 
Bug: b/261496232, b/263130999, b/283311462, b/350916229, b/352872248 
Test: manually + existing unit/screenshot tests 
Relnote: """New search bar APIs: 
  * Collapsed search bars and expanded search "views" are now 
    separate composables. 
  * `SearchBar` represents a search bar in the collapsed state. 
  * `ExpandedFullScreenSearchBar` and `ExpandedDockedSearchBar` 
    represent the search bar in the expanded state. These open 
    in a new window. 
  * `SearchBarState` to control the state of the search bar 
  * `TopSearchBar` to add insets handling and scroll behavior 
  * New overload of `InputField` which uses `SearchBarState` 
  """ 
Change-Id: Ie0723015eddd66c82f420481dc6f366a7e26f4a8

Files:

M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/integration-tests/material3-catalog/src/main/java/androidx/compose/material3/catalog/library/model/Examples.kt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/SearchBarSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/SearchBarScreenshotTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/SearchBar.kt

Hash: 2c46cabd287091ae4a47a7309f2f3eb19930c754
Date: Tue Jan 21 18:19:22 2025

ma...@google.com <ma...@google.com> Jan 29, 2025 07:50PM

Marked as fixed.

pr...@google.com <pr...@google.com> #6Feb 12, 2025 06:40PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.compose.material3:material3:1.4.0-alpha08
androidx.compose.material3:material3-android:1.4.0-alpha08
androidx.compose.material3:material3-jvmstubs:1.4.0-alpha08
androidx.compose.material3:material3-linuxx64stubs:1.4.0-alpha08
androidx.core:core-viewtree:1.0.0-rc01

xe...@gmail.com <xe...@gmail.com> #7Feb 13, 2025 04:25PM

Will this be tweaked to be able to use it according to the M3 Design? Search View Appearing.

In the current version animation does not work correctly without TopSearchBar.

ma...@google.com <ma...@google.com> #8Feb 13, 2025 04:30PM

Can you elaborate on what you mean? The animation is dependent on where the search bar is on the screen, so if you want an animation like in the design guidelines, it has to be placed at the top like TopSearchBar provides.