3 Ways to Make Your ViewControllers Skinny With MVC in iOS Applications

DZone 's Guide to

3 Ways to Make Your ViewControllers Skinny With MVC in iOS Applications

Are your apps looking a little bloated? Help them thin up using these three architectural patterns for iOS apps.

· Web Dev Zone ·
Free Resource

If you are someone who has been developing iOS apps for a while, you might be familiar with the UIViewController subclass. For those who aren’t that familiar, UIViewController is a class that contains most of your app’s logic. We often overburden the View Controller with everything we get as our application size increases. From transforming model objects into some view-friendly states to handling user input for fetching data to blah...blah...blah, this class is expected to do a lot. 

Unfair, isn’t it?

The same View Controller later on becomes a Massive View Controller, increasingly making it difficult to unit test your iOS application.

Huh! So, only unit tests would be impacted?

Well, not just the testability. This it also impacts maintainability and refactoring capabilities as well.

If you have ever faced View Controllers as a bottleneck, don’t worry, I will be covering how to deal with a massive view controller in detail. As you read through the article, you'll find it's actuall pretty easy to make your View Controller very thin.

1: Set Model-View-ViewModel as Your Default Architecture

As mentioned above, feeding your ViewControllers with almost everything related or unrelated to a view or a model layer is the root of a lot of known or unknown issues in iOS app development. While this seems appropriate when we look at the diagrammatic representations, in practical terms it sucks, literally!

A good way to deal with this is to use the MVVM architectural pattern, which lays off the burden of writing the same redundant code every time you write code while developing iOS apps.

ViewModel from MVVM solves this challenge as the ViewController no longer communicates with the model. While the model still represents data, it now communicates only with the ViewModel. The ViewController will then interact with the view and ViewModel.

Let’s take some example code that formats date implemented in MVC. If you implement the same code with MVVM, the controllers will no longer be responsible for converting the date into a string. The controller won't know about the model where we have our data stored. The model will simply return data to the ViewModel and output it in the desired format.

A closer look at this also shows that it provides much better decoupling of our UI and logic. This results in thin, flexible, and easy to read ViewControllers that you can actually control.

2: View Controller Containment

This is one of my favorite methods to lean out ViewControllers and make your code more reusable.

The idea is simple — you can have multiple child ViewControllers for a single parent ViewController in applications with complex UIs.

This means that your user interface can be split into multiple sections, each managed by a parent ViewController.

The child ViewControllers will be responsible for handling the various sections of the user interface. Think of your parent ViewController as a single ViewController which is managing the main view. Now, your main ViewController will have three different views, such as map view, table view, and canvas view.

These ViewControllers are responsible for implementing their own functionality, e.g. the map view functionality will be controlled by a MapView controller, table functionality will be controlled by TableView controller, and the canvas view be controlled by your CanvasView controller.

By breaking up your UI in this way, you will distribute the responsibilities of the parent ViewController to two or more child controllers. In this way, you can reuse the different functionalities of your ViewController (such as MapView, TableView, andCanvasView) in different parts of your project. This will make your code clean and eventually thin out your ViewControllers.

3: Outsourcing TableViews

TableViews are easily to separate and reuse, as they don’t know anything about the data they are showcasing and the user interaction of the objects. In iOS, TableViews are often implemented inside ViewControllers.

More often, a separate subclass of UIViewControllerUITableViewController, automatically sets itself as the data source of the table view.

A better approach towards implementing this is by separating these behaviors into separate classes. For instance: think of a datasource as an example in which data for a table view is presented through an array.

You can write a data source object that will handle the array. Doing so will provide all the behavior specific functionalities to implement the TableView, such as fetching the object at the appropriate index, inserting and deleting objects in an array, and returning the count of the array equivalent to the number of rows in the TableView.

This will remove lots of boilerplate code from the ViewController and also improve code reusability.


If there’s one point that I want to emphasize here is that it is extremely easy for anyone to miss these things and put all of their code within the controller, making it extremely large. And, when this happens, it defeats the purpose of usuing this architectural pattern. A general rule of thumb is to refactor your code and move towards a slightly better structure, like MVVM, rather than just trying to fix things up quickly. By implementing a structure such as ViewController containment, you can better implement skinny controllers in your iOS project.

ios application development, mobile application architecture, mobile application develop, mobile application development, web dev

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}