Interactive Animations

[NickEntin]

This adds support for interactive animations.

Very much still a draft a this point. The exact requirements are still TBD (see #34). This is a proposal for one potential API, to give us something to play around with and see if it works well.

[NickEntin]

There are still some areas I need to explore on this. Top of mind right now:

• Figure out an approach to handling infinitely repeating animations. It becomes meaningless to "animate to the end" of an infinitely long animation, so that opens a lot of questions (how does the curve get applied, etc.).
• Establish clear documentation on where the animation ends. Currently, by design, it will always be "animating" until you call cancel, even if it hits the end of the animation. This has some nice usability advantages, but can lead to some confusion.
• Make sure all of the state is getting updated properly. Right now, for example, the status is not updated properly, and we don't verify the status before performing actions internally.

[NickEntin]

Figure out an approach to handling infinitely repeating animations. It becomes meaningless to "animate to the end" of an infinitely long animation, so that opens a lot of questions (how does the curve get applied, etc.).

I think the easiest way to handle this would be to not support repeating interactive animations. Moving the source of truth for the repeat style to the execution phase (#43) would make this fairly straightforward, allowing us to simply exclude the repeatStyle parameter from the Animation.performInteractive(...) method (and ignore the animation's defaultRepeatStyle).

If we then decide to add support for repeating interactive animations in the future, we could add a repeatStyle parameter with a different value type that does not include an infinitely-repeating option.

[NickEntin]

Ideas from chatting with @lukebradford a few weeks ago:

• We should add an optional duration parameter to the animateTo* methods to specify a duration for only the remaining segment of the animation. We then have a preference order of: (1) explicit segment duration, (2) portion of explicit end-to-end duration, (3) portion of implicit end-to-end duration.
• Rather than only being able to animate to the extremities (animateToBeginning() and animateToEnd()), we should allow animating to a specific relative timestamp.

We also discussed what the expected behavior when the animation reaches the end, and landed on the animation not automatically completing when it hits the end of the animation. To avoid a permanent retain cycle if the animation is not explicitly ended, though, we talked about only holding onto the instance in the driver while it is in automatic mode. I think this solves most use cases (if you have a reference to the instance, you can control it still; if you don't, then it doesn't matter). The one thing I just thought of is the case of holding a weak reference to the instance. I think it's probably still a reasonable choice, but we'll need to be very clear in the documentation to avoid unexpected behavior.