fix scroll issues

[marunjar]

make a difference wetween left and right scrolling when snapping to day
use default scroll duration (250ms) instead of 50ms before
allow changing direction while scrolling

[entropitor]

Has the number 40 been tested with different number of days selected in the app? Because it seems like a magic value?

[marunjar]

it is kind of a magic number, i just need a small threshold so there has to be a notable change in scroll direction before changing it. else there are some glitches if you put your hands off the screen and the scroll distance is suddenly 0.1 in other direction.

while writing this maybe the best would be if this threshold is calculated including density.

[marunjar]

@caske33 do you have any idea how we can predict where the fling stops scrolling before we call mScroller.fling?
then there would be no snapping to next day and it also will look a little bit smoother

we also can play around with goToNearestDay function e.g. to go to next day only if 25%-30% of next day are visible, else we snap back.

[Tolriq]

On android usually the value to use is : http://developer.android.com/reference/android/view/ViewConfiguration.html#getScaledTouchSlop() as a minimal distance trigger.

I'm currently testing another approach that works quite well.

First for snap scrolling I use :

mScroller.startScroll((int) mCurrentOrigin.x, (int) mCurrentOrigin.y, -nearestOrigin, 0, (int) ((Math.abs(nearestOrigin) / mWidthPerDay) * 1500));

This makes the duration relative to the distance to scroll, making it more natural for all cases. (unlike fixed duration whatever distance to scroll)

Second I start snapping a littler earlier than when fling is finished to avoid the pause effect.

In computeScroll()

        if (!mScroller.isFinished() && (mCurrentFlingDirection != Direction.NONE) && (mScroller.getCurrVelocity() <= mMinimalFlingVelocity)) {
            goToNearestOrigin();
        } else if (mScroller.isFinished()) {

With mMinimalFlingVelocity set to ViewConfiguration.get(mContext).getScaledMinimumFlingVelocity() (This value can be tweaked depending on needs).

Bouncing to back day when the fling stop in the start of next day feels more natural, than scrolling the whole day to go to next or previous one.

[entropitor]

@Tolriq Your code doesn't seem to snap anymore.

[entropitor]

I've played a little more but I can't get any good behaviour (yet)

As @marunjar I've tried adding a new FastOutLinearInInterpolator() to the OverScroller (on Line 345). I think if we combine that with a variable duration of the scrolling on line 1703 (based on the distance) we might get it to work better. (so we alsways scroll with the same speed, now it's ok for short distances but really fast for longer distances. So I guess we have to increase the duration for longer distances. Especially for a one-day view).

The ViewPager class from AOSP seems to use Math.sin() for that. Maybe we should try to experiment with that too?

[Tolriq]

@caske33 Well it does still snap here : please see Tolriq@b2e595e

I can't really make PR for now as I've diverged a little from code base and had a too quick push with code formatting.

Anyway whatever interpolator or not is used there will be a cut in animation since it will be after the fling that is decelerating.

The only real proper way would be to not use the scroller fling but calculate the correct destination then do the scroll manually with an interpolator.

But then it's no more snapping. Snapping effect is not a bad thing as it help users to understand the limits of the days and add interaction effect.

[marunjar]

thanks @Tolriq, i just played around with your suggestions and dynamic scroll speed and the properties from VieConfiguration helps a lot.
I also used the FastOutLinearInInterpolator so the difference between scroll speed at the end of scrolling and speed in gotoNearestOrigin isn't too big.

i also tried the early snapping but this only works on >= api 14

@caske33 we can also play with different scroll durations and custom interpolators, shouldn't be that hard.

[entropitor]

@marunjar So the last commit should not "snap" anymore?

@Tolriq Have you gotten a chance to test that commit yet?

[Tolriq]

Sorry no, I'm not in production with my current code so can't really test right now.

[entropitor]

@marunjar I like this a lot better!

Should we merge it like this?

The only thing that could be enhanced is maybe that the fling gesture doesn't start this easily.

[marunjar]

i think it can be merged.

I'm not sure if we can change the behavoour for the fling gesture.
In SimpleOnGestureListener the ViewConfiguration.getScaledMinimumFlingVelocity() is used to detect a fling. We can't change this.
Maybe it's enough when we just support disabling of the fling gesture.