‘Old’ API now uses newer result builder logic behind the scenes. All tests now use new API albeit implicitly.

• added more tests to debug failing complexer tests
• renamed a lot or protocols to use Animatable instead of Animates
• completed RunningAnimation implementation

Add a RunningSequence class that keeps state of and actually performs all animations (skipping the old AnimationSequence). Adds a onComplete method that now handles a completion handler and even a stopAnimations() method that stops current and cancels future animations.

Also all protocols have been renamed with more conventional names, creating a much clearer code structure

Adding functionality to use result builders to plan your animations, resulting in a cleaner looking experience.

• Phase 1: New result builder API, lives next to ‘old' API
• Phase 2: Old API uses result builder structs behind the scenes
• Phase 3: Deprecate old API and fully move over to result builder API

Phase 1 introduces the new AnimationPlanner.plan API that lives alongside the current, or ‘old’ UIView.animateSteps method. Behind the scenes the result builder logic transforms the animations to the current implementation of actually performing these animations. The functionality should at least be on par with the current implementation, making sure no animations that should only be performed in a group to appear in a sequence and vice versa.

• [x] Build out new API, on par with current implementation
• [x] Separate out tests for both APIs
• [x] Write documentation for new API

Adding methods to add spring-based animations to sequences. Using UIView.animate(duration:delay:withSpringDamping:initialVelocity:) method instead of the standard animation method.

Added an actual DocC documentation catalog to the package, giving the package’s documentation an intro text and even a page showing and explaining example code.

Fixes #2. Animations that don’t actually change any animatable properties are ignored by UIView.animate, which means any delay that should incur is skipped as well. When finishing an animation, the actual duration is checked and when completed too soon the system now uses DispatchQueue to wait for the appropriate time.

Issue

When no actual value is changed in an animation, the delay leading up to that animation is ignored as well considering nothing actually needs to animate.

Proposed solution

1. Add test to confirm specific issue
2. Make sure actual animation has taken place (no good idea how yet), use DispatchQueue.asyncAfter() when delay needs to be manually added

Notes to follow, but this PR fixes #17 and totally changes how animations are performed. Sub-animations (like those containing within a Group or a Sequence) are now cancelled as well.

As AnimationPlanners knows exactly how long animations take, a CADisplayLink can be created for its duration set with the max framerate. Animations can also have a property to manually enable this behavior.

Source: https://github.com/duraidabdul/FrameRateRequest

Problem

Any animation containing multiple other animations aren’t passing the cancelling on to their sub-animations, only flat sequences are cancelled.

Proposed solution

Add func cancel() to Animatable (or a more appropriate protocol) so every animation can handle it for their specific case. ~Maybe create default implementation for Animation where it just immediately executes changes again, but making sure RunningSequence only calls this method when it’s the currently running animation.~ For years now (who new) UIView animations are ‘additive’, meaning they can’t be cancelled by performing the same changes as the animation. Either the currently running animations are played out and subsequent animations are cancelled, or a UIViewPropertyAnimators runs for each animations that can be cancelled.