Quirks (or stuff not yet decided)

This section houses anything that may seem a bit odd such (fringe cases) that we just haven't yet decided what to do with (if anything).

Completion handlers for Tweens in a TweenFlow

This one is a bit tricky to explain. When there are Tweens inside a TweenFlow that is set to have more than 1 iteration it is possible that the onComplete handler of the final Tween inside the TweenFlow will not fire until the entire TweenFlow completes. The reason this occurs is that the TweenFlow is trying to keep animations as smooth as possible so it always uses deltaTime for its step increments and it could "step over" the case where elapsedTime is exactly equal to the inner Tweens duration.

As an example, lets say we have a TweenFlow with 3 Tweens in it that ends up with a duration of 4 seconds and has 2 iterations. If the current elapsed time is at 3.99s then the next iteration will push it over 4 causing the TweenFlow to move on to its second iteration. Lets assume the next deltaTime is 0.1s. This "wraps" the elapsed time back to 0.09s therefore skipping the completed step of the 3rd Tween in the TweenFlow. The possible solutions are:

1. when a wrap occurs clamp the elapsedTime to the full duration (4s in our example) for the current step
2. do nothing and let things happen as they do currently
3. remove support for onComplete handlers inside TweenFlows (not sure how useful they will be at this point)

Option 1 will cause animations to not be as smooth as they could be so it doesn't seem like a good solution. Option 2 leaves things in the current state which may cause some people confusion if they find the fringe case without having read this. Option 3 feels a bit heavy handed but begs the question: are onComplete handlers useful and required for TweenFlows?

DuplicatePropertyRuleTypes Discussion

Currently, any Tweens whether running or not are checked when the duplicate property rule kicks in. This may or may not be the best strategy. One alternative would be to only check against Tweens that are currently running. This can have some unintended side effects as well though. In the event a position Tween is running on someObject and it is paused for a second then a new position Tween is added the duplicate property rule would not kick in if it only checked running Tweens. That may or may not be the desired effect.

On the opposite spectrum, if the duplicate property rule doesn't ever check if a Tween is running (the current way it works) then it could remove Tweens that you have set to not be auto removed on completion that you may want to use again later. One way to work around that is to remove the Tween when it is complete (Go.removeTween) then re-add it when needed (Go.addTween). Another possibility is for GoKit to not destroy a Tween when it is removed and instead just remove it. That would allow you to simply re-add it at any time if you keep a reference to it around.