How evil is a UIViewController?

Question

This is a somewhat open ended question about the UIViewController class, and their proper role in an iOS app.

I recently read this article, and I partially agree with the author. It's obviously important that every bit of logic related to your views and models doesn't end up getting dumped into the UIViewController, but it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.

I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)? As the author of the post pointed out, Apple doesn't seem to strongly advocate against putting logic in the UIViewController.

Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?

Answer 1

A view controller is not evil by nature, although it's common for them to grow into monolithic messes because they are so convenient to extend.

…it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.

Think of it as breaking up your program into smaller units, whatever that may be. Subclassing UIViews in every case isn't the best solution (as one example).

Each developer's tolerance is a bit different and it varies by program/case, but it's pretty easy to recognize and eliminate duplicate code, and to break your programs down into smaller units.

I think most classes:

• should not exceed a few ivars (e.g. 2)
• should not require more than 100 lines
• should favor composition over inheritance. in many cases where you think you need inheritance, protocols may be used.

Of course, there will be exceptions.

I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)?

It matters more that you will gain a lot by writing more reusable programs. Invest more time and effort into these reusable designs, reduce duplicate code, and focus on quality. Write performance and memory into your designs where it is a concern. Generally, this will result in a big win when compared to the dreaded freshly written, poorly tested, monolithic VCs.

Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?

Oversimplification: No, you don't have to go that far if you eliminate redundant code, focus on reusability where applicable, and ensure your units/classes maintain low complexity. Absolutely, fix those problems before they grow into monolithic classes, regardless of whether they are VCs or another type.

Answer 2

I've also read this article a year ago, when I was looking for better iOS coding practices than what you see everywhere (dumping all kinds of crap in view controllers...). I agree with its points, although unfortunately it doesn't provide any kind of solution to the problem. After a year of working on a fairly large iOS application, with complicated data model, remote services and highly nonlinear navigation, my experiences come down to these points:

• Use view controllers for a single unit of user interaction, like prompting for login credentials etc. Basic validation (e.g. checking for empty fields, number formats etc.) takes place in the view controller, but if validation is part of your business logic, it should be put in your model.
• I usually have a so-called controller object which orchestrates the UI flow, and connects it with the domain model. The controller receives user input from the view controllers via delegate mechanisms, so they're loosely coupled.
• A single monolithic controller should be avoided; so I usually try to split my controller functionality between simpler, modular parts. For example, I have a controller which manages a registration process with a mostly linear UI flow, and its embedded in the main controller of the application so its