how do you consume scroll events on the way down t...

# compose

[grandstaish]

how do you consume scroll events on the way down the composable hierarchy? If I add a scrollable modifier a parent composable, I never get the opportunity to consume scroll events before my children do. Basically i want to intercept the scroll gesture

[jim]

cc @Shep Shapard

[Adam Powell]

If you're willing to get into the guts of this a bit as it's changing, compose's input processing has three phases: Initial, Main and Final. Initial and Main roughly map to the onInterceptTouchEvent/onTouchEvent down-from-parent and up-from-child stages you're familiar with from views

[Adam Powell]

We're currently moving to a suspend-based model of expressing gesture detection state machines, see Modifier.pointerInput {} - there's a DSL there that will let you install pointer event handlers and receive events at each of those pipeline stages, and at each phase you can consume motion from the event such that later processors (i.e. children in the Initial pass) will see it as consumed

[Adam Powell]

You can also use the existing PointerInputFilter API for this; same mechanism either way

[grandstaish]

thanks Adam, i’ll take a look into these APIs

what are your thoughts on including a hook for intercepting scroll in ScrollableController? it’d be nice to just say how many pixels i want to consume in the initial phase vs. the main phase without having to process all the complexities of a gesture myself

[len]

Do you have an example using the pointerInput {} modifier? I tried to use it the other day but using a while (true) sounded weird to me (maybe it's supposed to be used like that?)

[jaqxues]

https://github.com/android/compose-samples/blob/master/JetNews/app/src/main/java/com/example/jetnews/ui/SwipeToRefresh.kt

Ig worth to mention

[Adam Powell]

I think the suspending input direction is going to give an even nicer way of expressing that than hooks in ScrollableController would

[Adam Powell]

https://android-review.googlesource.com/c/platform/frameworks/support/+/1483931 gives a bit of an idea as to where we're going with this

[grandstaish]

ok yeah i agree, this looks great. i might hold off on my component til this is merged, it looks like it makes my use case really easy

[grandstaish]

actually i lie, all of these drag extensions are happening in the main phase. it looks like there’s still no way (aside from writing everything myself) to consume events from the initial phase? would you consider making this possible as a part of this PR?

[Adam Powell]

Can you describe the specific interaction you're building?

[grandstaish]

I am basically trying to think about how to build our collapsing header component (similar to the material one).

I was thinking it could be a layout component with two child composables (a header and body). The component would basically:
• consume upwards scroll events until the header is fully collapsed during the Initial phase.
• consume downwards scrolls in the Main phase until the header is expanded again.

[grandstaish]

do you think that’s a legitimate use case, or am I way off with my impl idea here?

[Adam Powell]

It's one approach but the nested scrolling use cases are still WIP. @matvei

[matvei]

Yup, working on this. Seems like this usecase fits the explorations we've done so far, stay tuned 🙂

[grandstaish]

thanks both!

[Adam Powell]

A challenge is that scrolling is often a composite of motion from many pointers or sources. Knowing how much motion to consume from each pointer in those cases to achieve a result isn't always clear

[Adam Powell]

Which is part of why nested scrolling is a separate, higher level concept in Android views

[grandstaish]

yeah, if I’m honest i’m never really that clear on how I should handle additional pointers, i usually ignore them in my custom touch logic 🙈

[Adam Powell]

Many do 🙂 we're trying to make that easier/more automatic with some of the APIs described above