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

Hi,

Thanks for providing a way to do this. However, my original use case was actually an app with a full screen Google Map, and unfortunately this modifier doesn't seem to help. Since my original post, there is now an official Google Maps compose library, but that is also using AndroidView. Is there a way to make this work with AndroidView, or is this on the roadmap?

Can we please open this issue again?

I have the same issue with an AndroidView for MPAndroidChart lineChart view to consume drag event inside a SwipeDismissableNavHost.

The edgeSwipeToDismiss works with scroll modifier, but not on any composable such as AndroidView, which shall really be able to consume any touch event inside a SwipeDismissableNavHost. If not, it would be pointless to use compose navigation at all with AndoidView.

I can use a hack to disable swipe event for any composable, but then the most PointerInput related to drag are difficult to detect, which makes the underline AndroidView lineChart feels laggy to drag along https://kotlinlang.slack.com/archives/C02GBABJUAF/p1673352672964539?thread_ts=1673292989.364779&cid=C02GBABJUAF

/**
 * Override a composable to be unswipeable by blocking the swipe-to-dismiss gesture.
 *
 * When a composable is on top of another composable that supports swipe-to-dismiss,
 * then [Modifier.unswipeable] can be applied to the top composable to handle and ignore
 * the swipe gesture. For example, this may be used to prevent swiping away a dialog.
 */
public fun Modifier.unswipeable() =
  this.then(
    Modifier.draggable(
      orientation = Orientation.Horizontal,
      enabled = true,
      state = DraggableState {}
    )
  )

It would be really great if, the edgeSwipeToDismiss can also work on any composable, or the swipe back event on SwipeDismissableNavHost can be disabled individually for a child composable of SwipeDismissableNavHost

Hi Yingding, Can you please share the code example regarding that issue? What exactly you're trying to make work? How MPAndroidChart is added and where are SwipeDismissableNavHost and edgeSwipeToDismiss in it? Thanks!

Reply to #6

Hi Mikhail, I created a demo repo for the MPAndroidChart inside AndroidView (https://github.com/yingding/swipeToDismiss).

Please find the demo video showing the edgeSwipeToDismiss doesn't work on AndroidView under this link https://github.com/yingding/swipeToDismiss/blob/main/video/dragEventConflictAndroidView.webm

I want to show multiple LineChart Graphs with MPAndroidChart, which are horizontally scrollable. The drag and scroll event is handled by the view system code from the AndroidView, so that all the drag event shall be passed to the AndroidView without being consumed by the parent SwipeDismissableNavHost.

You shall be able to run the code from my sample repo directly and see this effect on the emulator.

I will be glad to answer any further of your questions. I am seeking a way to tell the SwipeDismisableNavHost shall not consume drag event for the AndroidView, the unswipeable hack gives currently partial success. It would be great, that the edgeSwipeToDismiss modifier can work on any composable.

Thanks for the demo! So I see that sometimes scroll works, sometimes doesn't . When I remove .unswipeable and .edgeSwipe modifiers, I still able to scroll graphs in some cases- like a long hold and drag - then they start working. I think the problem here is with touch events, that they are not properly handled in Views and Compose worlds if used together

reply to #8 I don't think so, if you try the GraphsScreenPreview in GraphsScreen.kt in interactive mode and remove the unswipeable and edgeSwipeToDismiss, the touch event works fine.

The Preview tool works, since it is not wrapped inside SwipeDismisableNavHost, which intercepts the drag events. My code shall work if it is not used with SwipeDismisableNavHost. I am just curious, what happens here.

Probably the handling of touch events in both view and compose world also contributes to this complex issue :(

Kindly asking if there is any update on making edgeSwipeToDismiss supporting "AndroidView" composable?

1. I am wondering whether, #5 unswipeable() is the official solution for disable SwipeToDismiss.
2. Whether the associated root cause stated by #8 that AndroidView not receiving proper touch events from 170320973 is still present for AndroidView associated with SwipeToDismissBox. Does the touch event issue need to be dealt by the developer for AndroidView individually or the compose framework can help?

We have submitted a fix to b/230865655 that adds a userSwipeEnabled property to SwipeDismissableNavHost - this could be passed at the app-level when the current nav destination is a screen where you want to fully controlled the gesture handling (like the case in https://b.corp.google.com/issues/200699800#comment7). This will be available in the next Compose for Wear OS alpha release.