Sequential timings without Core Animation

Question

My current iPad project-in-progress has the need for a sequence of events; It roughly reads like this:

→ User taps a button in a floating panel on top of a scroll view
→ floating panel animates to close
→ model reloads some data
→ scroll view displays new data
→ scroll view scrolls to a new content offset
→ new floating panel opens

This is not just a simple animation. Halfway through the sequence it needs to pause, the model needs to do some background processing and then report back when done, after which the sequence can be resumed. Also, the animation of the floating panels is achieved by using the convenient UIView animateWithDuration:animations:completion: method.

When I search stackoverflow and the rest of the web for sequencing solutions, the only thing that pops up is Core Animation. Yet this is not a case for CA.

What would be the best way to go about sequencing and timing method calls like this?

Cheers, EP.

Answer 1

CoreAnimation is a candidate, and is what is used internally by the UIView convenience class methods. As you say, it's not a complete solution, but is definitely worth keeping for the panel animations.

Otherwise, I'd imagine the overview would be:

1. User taps a button in a floating panel on top of a scroll view; view controller issues (i) a request for the animation on the floating panel; (ii) that the model begin to load data (I'll assume asynchronously)
2. At some point CoreAnimation reports that the animation is done. At some point the model reports that the new data has been loaded. The view controller waits until both things have occurred.
3. New data is pushed to the scroll view
4. The view controller scrolls the view, probably using either -scrollRectToVisible:animated: or -setContentOffset:animated: (I'll assume with animation set to 'YES')
5. the view controller also being the UIScrollViewDelegate, it waits to receive -scrollViewWillBeginDecelerating: or -scrollViewDidEndDecelerating:, or possibly checks the contentOffset in -scrollViewDidScroll:
6. at the right moment it then has CoreAnimation transition in the new floating panel.

So you're allowing the scroll view to handle its own animation and trusting it to report animation status, using CoreAnimation as your code already does for the panel and otherwise wiring everything together in the view controller. There's no need to use CoreAnimation explicitly, just stick with the UIView methods you're already using.

If your model is synchronous rather than asynchronous then just start the processing immediately after issuing the request to get rid of the first floating panel — CoreAnimation tasks continue even if the main thread is busy.