Understanding the value of UIViewController transitions

Question

I am trying to learn some new iOS programming patterns. I have read a bunch about the UIViewController transitioning APIs added in iOS 7. They look cool but also feel pretty heavy for what seems like a simpler task.

Consider this use case: I have a custom container view controller that manages "slides". It holds an array of slide view controllers and the user can move forward and backward though them by tapping a button.

I can implement the transition for this as follows:

private func transitionToViewController(viewController: UIViewController, direction: TransitionDirection = .Forward, animated: Bool = true) {
    currentViewController.willMove(toParentViewController: nil)
    addChildViewController(viewController)
    // ... set up frames, other animation prep ...
    contentContainerView.addSubview(comingView)
    UIView.animate(duration: 0.5, animations: { 
        // do the animations
    }) { (finished) in
        leavingView.removeFromSuperview()
        self.currentViewController.removeFromParentViewController()
        viewController.didMove(toParentViewController: self)
        // final clean up
    } 
}

How would the newer transitioning APIs improve this? From what I understand, these APIs are even more complicated to use if you are rolling your own container view controllers (see custom-container view controller transitions.

Is the value in the transitioning APIs mostly for interactive transitions?

Thanks for clarifying

Snobbish

Answer 1

I think the new transitioning API (UIViewControllerTransitioningDelegate and friends) is simply a final step in the generalization of view transitions between controllers.

In first versions of UIKit we had to hack the system transition code to get any custom transitions at all. Years later we got controller containment that made it possible to manage view controllers as first-class citizens and create our own interactive transitions. The final step is having a full-featured general system API for any transition that you can dream of – that’s the new transition API.

The new API makes it possible to extract the transitions into standalone classes. Which, in turn, makes it finally possible to just download a transition library off GitHub and plug it into your existing code as a simple transition delegate. No need to derive your view controllers from some particular superclass, no need to use a third-party controller container, no need to add extensions to UIKit classes. Now the transitions are finally first-class citizens in UIKit, too.

Kirkuk

I agree that there are many separate classes involved and at first glance the API looks daunting. However, Apple's documentation covers all the basses and the ammount of code you would have to write for each of those classes to (say) replicate the behaviour of UIAlertController is not very much. – Pharmacology

Answer 2

How would the newer transitioning APIs improve this?

TL;DR Maintainability via Encapsulation, Reusability, Testability.

Encapsulation: The comments indicate that there's logic to set up and state to track with the animation. Your view controller is probably plenty big enough already; putting transition logic somewhere else makes each piece smaller and therefore more maintainable.

Reusability: What's the next thing you'll do after this? Set up the transition back from the transitioned to controller, no doubt. And is it likely to be a reversal of this animation? Pretty likely. So you'll copy and paste this code to that controller and reverse it there, probably. Now you've got two copies. One copy using the transitions would be more maintainable. (Also note the existence of pods of custom transitions, as reusability and shareability go hand in hand.)

Testability: Code embedded in a heavyweight view controller is notoriously difficult to test. A custom transition can be tested in isolation without the state overhead of the live views.

So for any code you intend to look at more than once, the transitioning APIs are probably worth the effort!

Spadiceous