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

Update: I tried using a side effect but with strange results. I am using the demo code shown in docs here.

For my first attempt, these two println statements are printed infinitely:

LaunchedEffect(state.isTransformInProgress) {
  println("Is transformation in progress? ${state.isTransformInProgress}")
  if (!state.isTransformInProgress) {
    println("Resetting offset")
    state.animatePanBy(offset = -offset)
  }
}

I assume this is because animatePanBy is quickly switching isTransformInProgress from true to false for running an empty animation, leading to the loop. It's funny that state.isTransformInProgress is always evaluated to false by the time the first print statement is executed.

If I add another condition to run the animation only for non-zero offsets, I get a slightly better result, but it still runs 2-3 times.

LaunchedEffect(state.isTransformInProgress) {
  println("Is transformation in progress? ${state.isTransformInProgress}")
  if (!state.isTransformInProgress && offset != Offset.Zero) {
    println("Resetting offset")
    state.animatePanBy(offset = -offset)
  }
}

I also tried using a snapshotFlow, but this suffers from a different problem: if the animation is interrupted with another gesture, the collect operator stops receiving any more values. There might be a way to restart it, but I wasn't able to figure out a simple one.

LaunchedEffect(Unit) {
  snapshotFlow { state.isTransformInProgress }
    .distinctUntilChanged()
    .filter { inProgress -> !inProgress }
    .collect {
      state.animatePanBy(offset = -offset, tween(1_000))
    }
}

Do you see anything obvious that I might be missing?

Yeah I think I was mistaken suggesting this as it will indeed flip back and forth, because that's the contract of the isTransformationInProgress. In fact, seems like you need an indication of the

I think what we should do is to add InteractionSource to the state, so that you can query specifically the Drag interaction and launch against its change. Louis, wdyt?

Yeah makes sense to add InteractionSource integration here, same as for things like ScrollState

Will DragInteraction be sufficient for querying fling velocity? I'm trying to think how would this work w.r.t nested scrolling.

Nope, there won't be a way to get that kind of information currently, and I don't think DragInteraction is the correct place for that sort of thing. If you specifically need velocity, I guess we need a specific callback / build your own implementation where you can reference this directly

A callback would be great for compatibility with nested scrolling.

On a second thought, a callback alone wouldn't be sufficient for enabling nested scrolling. Modifier.transformable() consumes all events by default even if its content can't pan any further, preventing scrollable parents from showing overscroll effects. I can file a separate issue for that if you want.

Ah I see, yes please file a separate bug. Probably transformable should just implement nested scrolling directly - if it did do that, would you still have a need to figure out the fling velocity on end?

If transformable can support nested scrolling, that'd be the best!

Modifier.transformable() consumes all events by default even if its content can't pan any further, preventing scrollable parents from showing overscroll effects

Am I understanding it correctly that https://android-review.googlesource.com/c/platform/frameworks/support/+/2547591 fixes this?

On a second thought, the new canPan parameter isn't sufficient. It needs to also provide the pan delta so that consumers can decide if content can be panned in the gesture direction.

Main usecase we covered with this API is the ability to disable pan based on some external state (e.g. cumulative scale or rotataion or something else). It is not clear why you would want to decide on wether to pan or not based on the direction of the pan delta.

I understand your usecase, but this API is not intended to substitute nested scroll-like abilities

If my content in a pager is zoomed in, but is also panned to the edge, is there a better way to return false from canPan? The documentation of canPan recommends using scale > 1f but that may not be something that all apps use.

While I understand that this is leaking into nested scrolling, nested scrolling can't be used for 2d scrolling yet.

Hmm, I see. The thing is that I don't think it will be possible to control the consumption of the events once you started the panning, e.g. if you are at the bound of the zoomed picture and the pointer goes down - providing delta will cover this case, but not when you reach the bound with the finger already down.

The only real way to make this change correctly is the nested scroll dispatch.

e.g. if you are at the bound of the zoomed picture and the pointer goes down - providing delta will cover this case, but not when you reach the bound with the finger already down.

That sounds perfectly fine! Can I ask you to try out this experience using telephoto's sample on your phone? https://github.com/saket/telephoto/releases/download/0.3.0/telephoto_0.3.0_sample.apk

I see what you mean, that does make sense from the UX perspective. I see that in general it can be beneficial to have this info anyway, I will add Offset to canPan to help with that.

Yay thank you!

Hey folks, can this issue be reopened again? https://android-review.googlesource.com/2597810 is unrelated to the original feature request.

My bad, reopening and reassigning to the tracking hotlist to address in the future work