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

The current implementation after the fix is aligned with the foundation API AnchoredDraggable - I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.

Let me know if you have different thoughts. : )

I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.

That sounds reasonable to me. Is there a separate bug for that or should I file one?

One thing that I think will be weird is that the size of the panes can come from that anchor or from PaneScaffoldDirective defaultPanePreferredWidth (possibly influenced by the hinge?). In an ideal world, I think we would have the sizes all come from anchors, but that wouldn't work today with three panes visible. I'll add a note to the doc on this.

We don't have a separate bug for that but it's already being supported via:

rememberPaneExpansionState(
    ...
    initialAnchoredIndex = i,
)

You raised a very good point about having parallel ways to set up pane sizes.

To me it's sort of reasonable as there are actually referring to different use cases and have different priorities -

1. Hinge policies always have the highest priority.
2. Pane expansion (and its anchors) are associated with layout splits, but less with the "roles" of the panes that occupy those splits.
3. Modifier.preferredWidth always has the lowest priority - more like a fallback default.

I guess we can have more detailed explanation in the doc if this can be confusing?

Oh, it's in the remember call, perfect!

Yeah, it seems reasonable debating about the use cases, but I worry if it's reasonable for a developer who doesn't consider all that and just wants to show two panes? It's also even more nuanced since 2 only applies for two panes (e.g., if your app shows two panes in portrait on a Samsung Ultra tablet and three panes in landscape). Maybe in the kdoc we should have something similar to what you listed here and in DAC we can provide more context around these.

Yeah that sounds good to me. I plan to have some time to refine our kdoc and samples no matter what. Let's maybe work on this in the upcoming alpha/beta period.