“This is the 15th day of my participation in the November Gwen Challenge. See details of the event: The Last Gwen Challenge 2021”.

preface

In my previous article, I encountered a problem:

The controller’s animateTo event triggers the ScrollPosition call beginActivity(DrivenScrollActivity()), which interrupts the drag event.

After some thought, I decided to use a custom ScrollActivity to handle this problem.

Take a look at the implementation of the source code:

In the ListView, the animateTo method does something very simple:

Call position to handle;

What position does is hand the task to the scrollActivity:

The scrollActivity, however, is not complicated. Basically, it is computed by the AnimationController and constantly renders the result setPixels; Finally, call goBallistic, goIdle to complex bit;

There seems to be nothing complicated ………… It’s not hard to write a new one;

implementation

The implementation of this, it seems that there are few things to change:

  • For the new ScrollActivity, there’s nothing complicated about what drag compatibility does: Check the delegate, the ScrollPosition, and see if the currentDrag that it’s holding is empty, and if it is, it looks exactly like DrivenScrollActivity now; If it’s not empty, what you do is you don’t call goIdle or goBallistic reset at the end, bad thing;

  • In the animation section, modify the beginActivity to see if you want to clear the Drag;

I created a ScrollController and a ScrollPosition based on the above ideas. And a new base class for ScrollActivity. Save whether to interrupt the drag judgment;

ScrollController:

ScrollPosition:ScrollPosition, because a lot of things are private… Only copy ScrollPositionWithSingleContext this completely, and then according to the need to modify;

ScrollActivity:

At the end

Simple modification, as if the effect is ok?

However, it seems that the offset calculated one more viewPort, this is a small problem ~

However, there is a big problem. According to the effect of Xiaomi reading, even if you move your finger before the animation ends, you can track the final position of your finger smoothly. Now, if you keep moving your finger until the animation is over, the animation will never start

The animateTo method is triggered every time you swipe the finger, and the AnimationController is destroyed and rebuilt so that it doesn’t actually work.

Looks like we’re going to need to make some changes to the AnimationController calculation? Perhaps we should break away from the current limitation of from and to, fix a time, distance and speed, and finally constantly judge whether we have reached the specified end point, so as to end this calculation method in advance?