Status Update
Comments
ma...@google.com <ma...@google.com>
sg...@google.com <sg...@google.com> #2
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
ro...@veeva.com <ro...@veeva.com> #3
ro...@veeva.com <ro...@veeva.com> #4
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
di...@google.com <di...@google.com> #5
Thanks for looping me in!
Shalom is correct. To meet accessibility requirements we must ensure 48x48 touch targets for each element in the picker. With 7-days (thus 7 columns) that translates to 336dp wide and then there is an additional added left/right 12dp equaling 360dp total.
There are multiple views– including the date-input (non picker) format for screens with not enough real-estate.
On small screens, such as mobile, a full-screen modal date-picker is recommended to increase readability and touch target size. It can cover the entire screen on small screens. The full-screen picker must also ensure the minimum 48x48dp touch-targets so won't work for scenarios below 360dp wide. I will bring the idea past a few others as well on possibly enforcing full-screen under these strained viewports and what the logic might be.
In the meantime, as our guidelines do lean in that direction (full-screen for strained mobile experiences), that would be my recommendation, but the language could be more explicit.
ro...@veeva.com <ro...@veeva.com> #6
Hi #5, thank you for your reply. I have two comments:
- What about landscape mode? Currently it's completely broken (see image attached)
- Will this 48x48 touch target be enforced also for the
version? I hope so, because it's going to be confusing to have 2 different looks depending if your app is using Compose or classic Views, beside the fact that Android Material Component currently doesn't meet the accessibility requirements.Android Material Component
di...@google.com <di...@google.com> #7
No problem!
- Let me circle back on that to confirm, but I believe the Landscape mode follows the same logic to distill to direct input mode or full-screen instead of this modal in your screenshot.
- Yes the 48x48dp touch target is the new accessible requirement that all platforms will need to meet.
da...@bulder.no <da...@bulder.no> #8
Basically, with a small screen size and high text sizes and high screen zoom the "OK" and "Cancel" buttons goes off the screen, making them nearly impossible to click for the users that need high sizes. See attached screenshot.
Emulator specs:
320dp*640dp
720px*1280px
ar...@fara.no <ar...@fara.no> #9
Basically, with a small screen size and high text sizes and high screen zoom the "OK" and "Cancel" buttons goes off the screen, making them nearly impossible to click for the users that need high sizes. See attached screenshot.
"Cancel" and "OK" buttons are not visible also when you increase font size to 200% and display size to 320dp width (see attachment)
This violates WCAG guildelines and Google's own guidelines
Tested on Pixel 7 Pro emulator API 34
androidx.compose.material3:material3:2023.10.00
sg...@google.com <sg...@google.com> #11
For the "OK" and "Cancel" issue, you can add a Modifier.weight
to the DatePicker
in the DatePickerDialog
as a temporary workaround. I'm going to push a fix that will do that internally inside the DatePickerDialog
and will work for nesting a DatePicker
or DateRangePicker
.
DatePickerDialog(
onDismissRequest = {...},
confirmButton = {...},
dismissButton = {...}
) {
DatePicker(state = datePickerState, modifier = Modifier.weight(1f))
}
ap...@google.com <ap...@google.com> #12
Branch: androidx-main
commit f09ae412b90caf84bc36b55b0d4ef75b6b6503a8
Author: Shalom Gibly <sgibly@google.com>
Date: Wed Feb 14 17:03:33 2024
Ensure buttons visibility at the DatePickerDialog
Wrap the content with a Box and Modifier.weight = 1 to ensure any
confirm or dismiss buttons are visible when the dialog wraps a
DateRangePicker, or when large fonts are displayed on smaller screens.
Bug: 325107799
Bug: 277768544
Test: Verified screenshot tests and manual tests
Relnote: "Ensure that the DatePickerDialog displays its buttons when
nesting a DateRangePicker or when displaying any type of date picker on
small screens with larger fonts."
Change-Id: Ie4758e82b94eb2d5e448a973c550302ff1601f3f
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/DatePickerDialog.android.kt
se...@google.com <se...@google.com> #13
Hi Christian. Since Dillon is on leave do you mind forwarding this to the appropriate designer, thanks!
ch...@google.com <ch...@google.com> #14
Thank you JosÄ—. There are a couple of related scaling issues which I propose we look at all together. For the moment I am assigning this to ticket to Andrew, and included May in CC for awareness.
se...@google.com <se...@google.com> #15
Hi Andrew, do you gave an update on guidance here?
an...@google.com <an...@google.com> #16
Hi Christian, connecting to you as I believe you are currently looking into the 360dp width layouts. Please feel free to re-assign or reach out if there's anything I can do to help. Thank you!
ch...@google.com <ch...@google.com> #17
We are currently working on general layout updates to the date picker, as we will most likely need to support screen width up to 320dp.
Please stay tuned.
Description
Jetpack Compose version: 1.5.0-alpha02
Jetpack Compose component used: androidx.compose.material3
Android Studio Build: Android Studio Electric Eel | 2022.1.1 Patch 2
Kotlin version: 1.8.10
The
DatePickerDialog
has a fixed width of 360dp, which means that it cannot have any padding on devices with a width of 360dp. This issue is not present in theMaterialDatePicker
from the Material Component library (please refer to the attached screenshots for a comparison).Relevant source code references:https://github.com/androidx/androidx/blob/c830219ac8ec895fd660ed2a3c073ca1a6ebaf88/compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/DatePickerDialog.android.kt#L83
https://github.com/androidx/androidx/blob/869fe1f6c4151f742cfba5ccd327891dea582ca3/compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/tokens/DatePickerModalTokens.kt#L29
Steps to Reproduce or Code Sample to Reproduce: