Hopefully most of you are familiar with the concept of the Container View Controller. It’s a really useful Cocoa feature that I find myself using more and more lately. I won’t go into its implementation details, though, since you can find it in Apple’s doc.
Let’s dive into some scenarios where I find it super useful.
UITableViewController. Everybody has been there. You have a table, and some other content around. Most people just add
UIViewControllersubclass. But this way you throw away a lot of the functionality that you get for free via
UITableViewController, such as:
- autoscroll to focused
UITextViewso that they are not hidden behind keyboard
- flawless pull to refresh
to name a few. If you put
UITableViewControllerinto container you get best of both worlds – flexibility of your own
UIViewControllersubclass for decorating content and built-in functionality of the
- autoscroll to focused
Shared screen portions – those which reappear in differents parts of the app. This is especially helpful if you use architectures such as
CleanSwift. You can easily reuse complete scenes, with all of their helpers (interactors, routers, workers) already set up.
Display error and empty states of the scene.
Use it for animating controllers because it’s easier to animate
UIViewControllerusing View Controller Transitions. Make a container view with the embedded controller and animate it around as you would with any other view. You can see this approach in DisplayInDrawer lib.
And there are many more scenarios where
UIViewController containment can simplify your programmer’s life. But – there is a caveat. Let’s say you have an embedded
UITableViewController. You just got the data, so you create a controller, inject the data, embed it, and display. So far so good. New data arrives. Many times on many projects I have seen that the same routine is used. “so you create a controller, inject data, …”. Wrong. You needlessly instantiate a new controller although you already have one. Except this can be expensive (
viewDidLoad tends to be quite busy, right?), you can bring in crazy bugs, e.g. register duplicate observers, completion handlers etc. This can get even worse if your controller is not deallocating properly. Although I am sure your controllers do deallocate 👮, because you check that diligently, don’t you?
The solution is to check every time, if the controller exists already, and if it does – just inject the data. Do not make a new instance.
But this can get tedious and you can easily forget to make this check.
UIViewController-DisplayChild extension which mitigates this problem by embedding (displaying) the type instead of instance. You give it controller’s type, configuration closure and a container view. The extension decides whether the controller needs to be instantiated, makes an instance if needed, runs your configuration closure on it and embeds it to the specified container view.