Split AnimationController into two

[Hixie]

I think we should consider splitting AnimationController into two, one for straight-forward linear progress on a tick for a duration, and one for driving a Simulation. They can both be Animation<double>s. This would simplify the API, which right now is a hodge-podge of unrelated features to be able to handle both modes in one class.

In practice nothing but scrolling uses the Simulation-driven controller right now as far as I can tell.

[Hixie]

cc @abarth

[abarth]

We also use it for other fling effects, such as the drawer.

Seems like a reasonable idea.

[abarth]

AnimationController.fling is used in a bunch of places and goes down the simulation codepath.

[Hixie]

For Scrollable, what I did with that is split the class into two, ScrollPosition and ScrollActivity. Position owns an Activity. The Activity is what owns the AnimationController. The Activity that flings is different from the one that does the manual dragging.

[abarth]

It looks like all the places that use fling use it in a pattern with drag gestures to track the user's finger and then continue the animation after drag-end.

We could try a factoring of the problem where AnimationController only knows about linear timelines and the there's a separate Animation<double> subclass that handles the drag/fling pattern.

animateWith itself is used only by the (old) scrolling code.

Sounds like this issue will be ripe once the new scrolling code lands.

[Hixie]

It turns out that there's a bunch of places where we do weird things with animation controllers. I don't think it's worth doing this after all.