Presentation Controls, custom views and lighter UIViewControllers (Part 2)

So we now have MVVM, MVP, VIPER, VIP, but what about the other part? Where should the complex UI logic be placed?

Fernando Martín Ortiz
iOS App Development

--

In the previous post, I introduced a way to split your UIViewController to have your UITableViews and UICollectionViews driven by a new component that I called TableViewDriver or CollectionViewDriver. This time, I will go further and abstract your UIViewController from the way that your items are being displayed, so from the view controller, you can’t figure out if your items are being displayed using a UITableView, a UICollectionView or a UIStackView, or whatever. In this post, I will introduce you to a very powerful technique: Presentation Controls.

Presentation Controls assumes that you are using Interface builder either by using storyboards or by using xibs, since they are created in that way.

The problem

Using table view drivers, your code becomes cleaner, but the view controller still has a lot of IBOutlet members, making the drivers something like a workaround to the root problem.

The root problem is that your UIViewController is the heart of the presentation logic. It knows so much about its members and how they are displaying the data. You can’t modify the way that the data is displayed without modifying the code of the view controller.

Presentation Controls

A Presentation Control is an object that is responsible of handling a little part of the view controller’s presentation logic. It can have IBOutlets and can be included in the view controller as an IBOutlet.

They are very powerful and can abstract the view controller from the low level presentation logic, making it a coordinator of the presentation controls that it manages.

The plan

The view controller will be simplified by using Presentation Controls that will be responsible of handling the presentation details and will be included in the view controller using IBOutlets.

Presentation controls abstracting UIViewController from the views’ raw representation.

The Solution

Interface builder is a vital part of this technique. In case that you didn’t notice this, you can add Objects to a view controller using Interface Builder.

This object widget will represent the Presentation Control in our solution.

So the first thing you have to do in order to use Presentation Controls is adding a new Object to the view controller using Interface builder:

This Object will be a subclass of NSObject. So here we have to create a new NSObject subclass that we will call {Whatever}PresentationControl, and assign it to the recently added object.

Please, note that now that we have that object assigned to the scene, a new option is displayed when you automatic look for the counterpart using interface builder:

Now that we have the presentation control in the scene we can connect IBOutlets to it, in the same way that we use to connect IBOutlets to the UIViewController subclass:

And finally, this Presentation Control can be connected via IBOutlet to the view controller:

Conclusion

Once you have the presentation control handling a part of the view, the view controller becomes agnostic of how the data is actually being displayed, and that is great.

However, with great power comes great responsibility. This is not a silver bullet and you have to evaluate all the alternatives before choosing this. You can split your UIViewControllers using child view controllers or custom views, for example.

I personally found this very convenient and useful to have my view controllers thinner than ever.

If you are doing this in another way, I will be pleased of hearing about it. Please, leave your comments below! Thanks!

--

--