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.
-
Embed
UITableViewController. Everybody has been there. You have a table, and some other content around. Most people just addUITableViewinto theirUIViewControllersubclass. But this way you throw away a lot of the functionality that you get for free viaUITableViewController, such as:- autoscroll to focused
UITextFieldandUITextViewso that they are not hidden behind keyboard - default
UITableViewDatasourceandUITableViewDelegateimplementations - flawless pull to refresh
to name a few. If you put
UITableViewControllerinto container you get best of both worlds – flexibility of your ownUIViewControllersubclass for decorating content and built-in functionality of theUITableViewController - 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
UIViewwithUIViewPropertyAnimatorandUIGestureRecognizerthanUIViewControllerusing 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.
Enter 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.
