Anyone else bothered by compose's scroll container "sticky" behavior when hitting the edges? When I...

# compose

[ursus]

Anyone else bothered by compose's scroll container "sticky" behavior when hitting the edges?

When I scroll (both Column / LazyColumn) and hit the top/bottom of the container, the physics are odd/wrong.
It's becomes unresponsive to touch events for a bit (when comparing to Views), i.e. I cannot scroll down immediately, I have to wait for the "stretchy" animation to complete.

This wasn't the case with Views.

(Note: when I don't hit the edge, I can immediately change directions - works as expected)

[Louis Pullen-Freilich [G]]

Do you have a video example of what you mean by this? There are a couple of known issues in Compose overscroll that are being fixed that affect how the stretch relaxes, and make it faster to relax, but it’s unclear if that is the same issue you are talking about.

[ursus]

sorry for the delay, although im not sure if youre going to be able to tell from the video

it feels "sticky" when edges are hit

screen-20240630-170909.mp4

[ursus]

is there a way to show touches?

I find it most offensive on screens with nested scrolling (not actually nested, but say collapsing toolbars etc)

[Louis Pullen-Freilich [G]]

Yeah there is a developer setting in android for showing touches

[ursus]

I think slacks preprocessing will kill the details anyways 🤔

[ursus]

here is a rather long list, I dont hit the edges, its super responsive

screen-20240630-171428.mp4

[ursus]

here is a single video with touches enabled

first screen (long list) feels nice, the second one (short list) feels "sticky" (since edge of container is hit with the rapid swipe)

screen-20240630-172013.mp4

[Louis Pullen-Freilich [G]]

Slightly hard to tell, but what I think is happening: when you scroll to the end, and overscroll, you stretch the content of the list. When you scroll in the opposite direction, before the list can scroll - the list has to ‘destretch’ first, which is maybe the ‘stickiness’ as the first part of your motion in the opposite direction doesn’t move the list - it just relaxes the stretch. Does this sound like what you are seeing?

[ursus]

yep exactly

[Louis Pullen-Freilich [G]]

We have a couple of bugs / differences in behavior in Compose related to this, they should be fixed soon though to be consistent with views: so if you feel that the view implementation has no issues in this space, then this should resolve it

[ursus]

tbh now im not sure if this is as it always was with the stretch effect, or is a compose thing

but I dont remember disliking the effect when it came out, so I'd argue its a bug of compose impl as you say

[ursus]

great, btw this is a Foundation thing?

[Louis Pullen-Freilich [G]]

yeah, well there are a few issues in this, but the main one is that in Views when this happens, the stretch is relaxed 4x faster than normal, in Compose it’s not

[Louis Pullen-Freilich [G]]

So after we make this change, the Compose one should relax a lot quicker

[ursus]

great! in what artifact would happen? (so I can pay attention)

[Louis Pullen-Freilich [G]]

It should end up in 1.8.0* builds, when we ship the first alpha of that

[ursus]

will look forward to it, thanks!

[Louis Pullen-Freilich [G]]

if you still see issues then, please file a bug

[ursus]

If I have a somewhat related note:

I'm doing a scroll effect (collapsing toolbar) based on column scroll position (nestedScroll connection)

and if I simply apply offset { .. } to the toolbar it works,

but obviously I don' get the stretch effect on the toolbar (since it's not part of the scrolling column, it just "synchronizes" visually with the scroll position).
Are there some internals of the scroll container stretch effect I could hijack?

[Louis Pullen-Freilich [G]]

Not currently, but we plan to separate out the overscroll effect into different parts, so you could more easily apply the stretch to a component outside the main scrolling container

[ursus]

great, thanks for the info!