IOS - When to create a child ViewController and a subclass of UIView?

Question

This may be a dumb question, but I often came across it during iOS development.

Sometimes I create a view component that I want to use on several screens, so I will go to a subclass of UIView and make it something that I can use in several places.

Then I start adding functionality to it. Perhaps he needs to respond to NSNotification , or he should respond to user touches.

At some point, I start wondering if I really need to subclass the UIViewController and add it to my user interface as a child of the ViewController.

Is there any consensus as to where to draw the line between adding some types of behavior to a UIView and when to create a full UIViewController ?

Answer 1

You must use the controller anytime you need to process or manage data. Looks should be as stupid as possible, not knowing what they represent, but rather where. You can easily subclass and reuse ViewControllers. A good example is, let's say you need to get a string (or text) from a user in an entire application through a popover and modal controller. Create a generic subclass of UIViewController that has a view with a text box and a button. Then you can use this view and its controller in any required capacity. Reuse in popover, modal, or elsewhere (and usually transfer data back through delegation). Since you are dealing with data, you should not use a single subclass of UIView.

From my experience, I have subclassed UIViewControllers more often than UIViews . It’s a little difficult for me to understand if you are talking only about containers or reusing views in the overall application workflow. In any case, although it should be the same thing.

Answer 2

I can’t tell you about consensus, but here is my opinion:

A subclass of UIView only when ...

• Do you want to make a custom drawing
• You need to customize some behavior of an existing UIView subclass
• You have special needs for the layout of subheadings. However, most layouts can be done with the UIViewController .
• Maybe for special touch processing that you cannot do with gesture recognizers.

Subclass of UIViewController in all other cases. In any case, you almost always need a controller to write glue code that connects looks and models, or to interact with the user. Consequently, Apple has simplified work at UIKit to allow controllers to do all the work and keep the views as "dumb" as possible. For example, it’s very easy to embed controllers to create complex view hierarchies, without having to have one view subclass.

An indicator that a subclass of UIView not the first thing to do is a section called “Alternatives to subclassing” into a reference to the UIView class . An indicator that is a subclass of UIViewController is that such a section is not in the link of the UIViewController class :-)

Answer 3

I used the built-in view controllers to occasionally load reusable table views. I have found that this is useful sometimes, but not always. Communication between them can be cumbersome, for example, if you want the integrated controller to connect back to the container. Delegation is simple but cumbersome. It also limits you to iOS 6, if I remember that the correct ones of iOS 5 and below do not support the built-in controllers.

If he simply adds methods, you can use a category to store additional methods. I do a lot in NSManagedObjects that I don’t want to subclass, and if I regenerate NSManagedObject from the datamodel, I won’t lose the code in my categories. Gives me added functionality, such as computed fields or conversion methods, without a subclass. If you do not need these methods for a specific instance, simply exclude the link to the category.

A subclass is never bad, although IMO.