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

Alternatives to msrv_speed_ms_per_inch #24

Open
mvgreen opened this issue Mar 17, 2020 · 3 comments
Open

Alternatives to msrv_speed_ms_per_inch #24

mvgreen opened this issue Mar 17, 2020 · 3 comments

Comments

@mvgreen
Copy link

mvgreen commented Mar 17, 2020

Hello and thank you for your library, it helped me a lot! However, I found an issue in your implementation.
In fact there are two issues in one:

  1. ms/inch is not a speed, it's inversion of speed, so the word "speed" in the attribute name is very confusing;
  2. It would be better to have some alternative attribute to define constant snap time.

I'll explain the second issue as it is more important.
If you swipe your recyclerview on a small screen in portrait mode with (for example) msrv_speed_ms_per_inch=50, it will change the page pretty fast. But if you'll try it on a bigger device (on a tablet), it will scroll really slow, because it has a larger surface and it takes more time to reach target point.

Instead, it would be better to declare a constant time for snap helper, that will be equally fast on both devices.

@TakuSemba
Copy link
Owner

TakuSemba commented Sep 3, 2020

Sorry for the late replay and thank you for the suggestion.

Can I ask about No2 a bit more to make it clear?

it will scroll really slow, because it has a larger surface and it takes more time to reach target point.

I feel, regardless of the orientation, the distance between the current-selected position and the next target point is the same.
Let's say, msrv_speed_ms_per_inch=50 and snap_count=2 and the selected item is on index 4.
If you scroll to right, it will snap to index 6.
Since the distance between the item on index 4 and index 6 is the same on any orientation (as long as the size of each item is the same.), it will take the same amount of time. (I'm trying to reproduce it on demo app, but could not reproduce it.)

Or when you are talking about the bigger device, it has bigger items than a smaller device?

@mvgreen
Copy link
Author

mvgreen commented Sep 4, 2020

Yes, in my case items had "match_parent" width and so they were bigger when I change orientation to landscape, for example.

@TakuSemba
Copy link
Owner

I see. I understand your use case.

I will try and see if I can handle that use case and get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants