Question

Coming from a web development background, doing mainly MVC-based applications, I am used to have the components of my code separated in three groups of files: the controllers, the models and the views.

But in a iOS application, even also using the MVC pattern, does it make sense to follow the same technique?

An UIViewController provides you with a default view where you can add the rest of the subviews (UILabel, UIButton,…) and have immediate access to them. And the language is the same, it’s not like having to deal with HTML/CSS and something else.

But I have came across some iOS applications where an UIView is subclassed and maintained in a separate file, even when it’s only going to be used in an UIViewController. Thus, you have to code custom accessors to deal with internal subviews.

I do not see the need for doing that, unless of course you are reusing the same UIView in several places or doing custom drawing.

Answer 1

Many of us will admittedly blur the MVC lines a little and will slip a tiny amount of view-related code into our controllers. I personally think that is fine. It does not diminish the fact that we’re still largely following the MVC pattern (and that the Cocoa classes are doing the heavy lifting for the view). But, for me, if the view-related code expands beyond the trivial, I find myself electing to subclass the view.

There will be people who religiously subclass UIView, but I think a little pragmatism is warranted. If you’re adding a trivial amount of view-related code, is your code legibility improved by abstracting that away into a new UIView subclass? Not always. But I think this situation (where someone subclasses when they probably didn’t need to) is far less common than the opposite problem (where someone failed to subclass when they probably should have).

So, you asked:

I do not see the need for doing that [subclassing UIView], unless of course you are reusing the same UIView in several places or doing custom drawing.

I agree that reuse and custom drawing (e.g. drawRect) are two great examples. But I would also add a principle that if subclassing would improve code legibility because a view is sufficiently complicated (admittedly a subjective call), then I will subclass. Two examples:

1. I had a calendar view in an app and the view controller was getting unwieldy, managing all of the cells for the various days in the month, etc. So by subclassing the UIView, I was able to abstract the ugly details of all of the subviews that composed by calendar view. I subclassed not only the main “month” view, but also the “day” views within the “month” view. No reuse per se. No custom drawing. But it was obviously the right thing to do. The code is infinitely more legible.

2. I increasingly subclass UITableViewCell for my table views. In my first projects, I’d have the table view controller’s cellForRowAtIndexPath do all of the complicated composition and layout of that cell. My code is far easier to follow now that I routinely subclass the UITableViewCell in any situation that I’m not using one of the standard cell types.

In short, while I agree that one shouldn’t feel forced to subclass a UIView for every view controller, I personally try to do so when a view reaches a certain level of complexity. I let the code legibility govern my practices. I find that I’m subclassing views more than I used to, but by no means am I doing it all the time.

Bottom line, while you don’t need to subclass views all the time, I personally think many developers are guilty of failing to subclass views (or models) when they should have. They shouldn’t do so out of some fanatical desire to conform to MVC, but rather they should be asking themselves if their code would be easier to read and maintain if they subclassed the view or model as appropriate.