Massive View Controller - IOS - Solutions

Question

I'm sure every new iOS developer has the following problem: The View Controllers get very fast crowded with code for various purposes, easily getting to 500 + lines of code.

This is how it looks like for two basic and common screens:

1) The Form Screen:

2) The Table View Controller Screen

So far I have read about two different solutions:

1. First Solution: https://bendyworks.com/single-responsibility-principle-ios/. This is based on Notifications, it completely separates the View Controller from the (Intentions) View Model and thus reduces code in the View Controller. I think that it has the downside of breaking code, similar to Go-To structures. It looks like this:

2. The second solution keeps the same crowded View Controllers (button actions are executed inside VC and so on). but uses libraries like TPKeyboardAvoiding, BlocksKit or other solutions most of them based on categories. With this second solution, code is drastically reduced but the view controller still has a lot of responsibility.

What do you think about these solutions? Which is better? Is there a better one?

Answer 1

We can use MVVM to resolve this issue.

The Model-View-ViewModel, or MVVM pattern as it’s commonly known, is a UI design pattern. VM takes all logic about preparing model data for UI from VC.

Example:
You have got model object with some fields, you want to format some of them, make calculation and combine them.

In MVC case all that logic located in ViewController.
In MVVM you move all of it from VC to VM.

VM will prepare all data for UI and VC just sets it like this.

(in VC class)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Tutorials and topics:

• Introduction to MVVM
• MVVM Tutorial with ReactiveCocoa
• iOS Design Patterns: MVC and MVVM

Answer 2

I've had to untangle code in massive-sized View Controllers before and it really impeded my ability to navigate content at first. One important thing I realized is that size alone of the View Controller wasn't reason enough to break things apart. There is complexity in having 1 large file and also complexity in having a bunch of little files. Here are some valid reasons to refactor to break a View Controller into smaller parts:

MVC

The View Controller shouldn't be doing much more than being the connecting glue between the View and the Model. If you a lot of network connection code, image manipulation code, etc, then consider breaking those out into helper classes.

Multiple Controls with the View Controller as a data source

If you have a bunch of controls on screen that have your View Controller as data source, consider breaking those into separate data source objects and have them be the data source. Or you can also break them into separate View Controllers (like if you View Controller has a table view in addition to other controller, you can break that into its own Table View Controller class).

Duplicate Code

If you have the exact same code in different View Controllers put that in 1 shared location. That will make your code reusable and help manage the complexity.

Here is some additional advice to minimize View Controller complexity:

Storyboard instead of Programmatic

Creating View elements is a lot of code and frame geometry code is a lot of work as well. If not already consider using auto layout constraints and putting as much of the View elements in the storyboard as possible.

Unnecessary code/comments

Also be sure to remove unnecessary code/comments. A lot of times a new View Controller file will come with methods you are not using. If you aren't using a method like didReceiveMemoryWarning then it is safe to take it out. Also, because the View Controller file is so big sometimes it is scary to remove old code or comments. Don't put that off! It only adds to the complexity.

Notifications

To answer your question about notifications: Notifications aren't a Golden Hammer to use with everything. I find notifications to be useful when multiple View Controllers need to update at the same time because of 1 particular action. Be careful with notifications though, overusing them can cause you a lot of pain trying to track them down.

Answer 3

There's one special architecture they call VIPER (View, Interactor, Presenter, Entity and Routing). I'll try resume here what you need know:

View

• they are dummy views;
• contain objects like UIView, UIViewController, UILabel, etc;
• waits the content from the Presenter;
• handle user interaction and pass it to Presenter layer.

Presenter

• doesn't know UI objects;
• get inputs from View layer;
• handle the view logic (add method will present other screen);

Routing

• handle the navigation logic and transition animations;
• knows objects like UINavigationController, UIWindow, etc;

So, what I think you will clean in your code:

• data validations will move to Presenter layer;

• navigation will move to Wireframe objects (Routing layer);

• split your view controller observing DRY principle;

• Complex screens will have two or more Views and Presenters.

You should see the follow link about VIPER architecture http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

Good lucky!