Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CollapsingToolbar does not consume fling #7

Closed
onebone opened this issue Jul 6, 2021 · 4 comments
Closed

CollapsingToolbar does not consume fling #7

onebone opened this issue Jul 6, 2021 · 4 comments
Labels
bug Unexpected behavior or crash that disrupts library usage help wanted Extra attention is needed

Comments

@onebone
Copy link
Owner

onebone commented Jul 6, 2021

Summary

Although the user flings the content all the way to the top and there is a left velocity that CollapsingToolbar can consume, it does not consume fling.

Partial Solution

I can implement fling behavior by overriding onPreScroll() and onPostScroll() callbacks in NestedScrollConnection. However, the problem is that as of Jetpack Compose 1.0.0-rc01 it calculates fling velocity by relative position of the content (For the actual source code calculating the velocity, refer to here and here). As an offset of content moves as the toolbar is expanded/collapsed, the velocity that is calculated inside a child(moving) layout does not provide a valid velocity as a whole resulting in buggy fling behavior because the change in relative position hardly matches the global position change in screen surface.

Further Observations

Jetpack Compose basically utilizes event bubble(where event is passed from child through its parents) while we can capture an event before the child processes it using Initial PointerEventPass. However using PointerEventPass.Initial type will pay high implementation cost as there is an only small set of high level API with Initial passing type.

Traditional Android UI System

The traditional Android UI components which support nested scrolling such as RecyclerView and NestedScrollView calculate velocity using relative position, but they adjust their offset when its relative position to the screen has changed as we can see at here and here.

Conclusion

At the moment, I could not find a method to implement flinging behavior correctly, I will leave this as an issue until a valid way is found.

@onebone onebone added bug Unexpected behavior or crash that disrupts library usage help wanted Extra attention is needed labels Jul 6, 2021
@onebone
Copy link
Owner Author

onebone commented Jul 6, 2021

Progress

I found that the the value in the DragDelta which is used to provide scroll delta for onNestedPreScroll() is calculated using absolute position in screen (though transformed to relative position at the end, refer here). A possible solution from this fact is to calculate velocity on the parent using these scroll delta values and then override the velocity at onNestedPreScroll(). onNestedPreScroll() does not check if the available scroll delta changes its sign, so we can override it.

@alashow
Copy link

alashow commented Jul 8, 2021

This might be related https://issuetracker.google.com/issues/179417109

@onebone
Copy link
Owner Author

onebone commented Jul 8, 2021

This might be related https://issuetracker.google.com/issues/179417109

Thank you for pointing the issue. It is sad that the commit has reverted since I thought calculation based on a relative position was correct.

@onebone
Copy link
Owner Author

onebone commented Sep 4, 2021

Fixed as of 2.2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected behavior or crash that disrupts library usage help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants