Parallelizing

Basic Use

Multiple move calls will sequence animations one after the other at the order the calls are made:

aView.move(to: ["x": 300], during: 1.0).easeInOut() // this will happen first
    .move(to: ["a": 0], during: 0.2).easeOut()    // and then this

The result of the code above will be a move to x=300 and then a quick fade out after the move was completed. When in need to combine the two so that they run in parallel we must use the parallel function:

aView.move(to: ["x": 300], during: 1.0).easeInOut()  
    .move(to: ["a": 0.5], during: 0.2).easeOut()   
    .parallel()

This will start the move as the view fades to half its opacity in the first few steps and then continue half faded until it reaches to x=300. Here is how it looks:

If we wanted to have the fade happen at the end we must use delay

aView.move(to: ["x": 300], during: 1.0).easeInOut()  
    .move(to: ["a": 0.5], during: 0.2).delay(for: 0.8).easeOut()   
    .parallel()

Delay and Wait in Parallel Actions

While the two snippets below have equivalent results:

aView.move(to: ["x": 300], during: 1.0).delay(for: 0.5)
aView.wait(for: 0.5).move(to: ["x": 300], during: 1.0)

There is a subtle yet important difference between wait and delay which becomes apparent when parallelising the actions. That is that wait is considered a standalone action while delay is considered part of the action it is acting on.

aView.move(to: ["x": 300], during: 1.0).easeInOut()   // 1: move
    .wait(for: 0.8).move(to: ["a": 0.5], during: 0.2) // 2: wait, 3: move
    .parallel()                                       // parallelize => (1, 2, 3)

aView.move(to: ["x": 300], during: 1.0).easeInOut()    // 1: move
    .move(to: ["a": 0.5], during: 0.2).delay(for: 0.8) // 2: move with delay  
    .parallel()                                        // parallelize => (1, 2)

In the first case from the code above, we have 3 distinct moves that will run in parallel and the wait be ignored (although it will technically still be running).

In the second example we have just 2 moves, with the second having a delay attached to it, which will keep it's effect when parallelised.

Selectively Combining Groups

What .parallel() does is to create an internal group with all the actions that preceded the call added inside. This might cause a problem when two or more parallel groups need to be run sequencially. For example:

aView.move(to: ["x": 300], during: 1.0).easeInOut() // this needs to run first,
    .move(to: ["x": 200], during: 1.0).easeInOut() // then this...
    .move(to: ["a": 0], during: 0.2).easeOut()     // ...parallel with this!
    .parallel()

The code above will take all three moves and run then in parallel, essentially ignoring the first due to the fact that it will be overridden by the second as they share the same key. Let's say that what we wanted was for the first move to run on its own followed by the other 2 in parallel. To achieve this we could group the first on it's own and the other two following that.

aView.move(to: ["x": 300], during: 1.0).easeInOut() 
    .parallel()       
    .move(to: ["x": 200], during: 1.0).easeInOut() 
    .move(to: ["a": 0], during: 0.2).easeOut()     
    .parallel()

A shorthand method for doing the same is using the then property:

aView.move(to: ["x": 300], during: 1.0).easeInOut() 
    .then        
    .move(to: ["x": 200], during: 1.0).easeInOut() 
    .move(to: ["a": 0], during: 0.2).easeOut()     
    .parallel()