IssueTracker

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3328184

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling 
 
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component. 
 
Fixes: b/266550551 
Fixes: b/204650733 
Fixes: b/255554340 
Fixes: b/229537244 
Test: OverscrollTest 
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering  overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere." 
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61

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

• androidx.compose.foundation:foundation:1.8.0-alpha06
• androidx.compose.foundation:foundation-android:1.8.0-alpha06
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06

Any feedback from the design POC?

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.

Hi #5, thank you for your reply. I have two comments:

1. What about landscape mode? Currently it's completely broken (see image attached)
2. Will this 48x48 touch target be enforced also for the Android Material Component 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.

No problem!

1. 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.
2. Yes the 48x48dp touch target is the new accessible requirement that all platforms will need to meet.

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 https://support.google.com/accessibility/android/answer/12159181

Tested on Pixel 7 Pro emulator API 34

androidx.compose.material3:material3:2023.10.00

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))
}

Hi Christian. Since Dillon is on leave do you mind forwarding this to the appropriate designer, thanks!

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.

Hi Andrew, do you gave an update on guidance here?

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!

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.