CODEWITHSUNDEEP
iphonemodel-view-controlleruiview
Roy
Roy

Reputation: 3624

What is the proper rationale for subclassing UIView?

I mean this in compliance with OOP and MVC.

Specifically, I've planned out a UIView XIB file that has a lot of dynamically updated UILabels that change every time the user selects something: two timestamps, two durations, and two names. This is a "header" section of the interface that the user is seeing.

I see a few options 1. Create everything in the view controller, add the UIView as a subview to the main view, and keep track of the UILabel subviews with properties. But this forces me to add a lot of properties to the view controller. 2. Subclass UIView and add the UILabels as properties of the UIView, thus keeping the controller "cleaner." 3. Use the XIB file (but let's assume I want to do this programmatically).

I'm asking this because I keep getting the impression that UIView should be subclassed for "custom drawing," and my rationale is more along the lines of "keep my controller cleaner without 6 UILabel properties."

Upvotes: 1

Views: 97

Answers (2)

morningstar
morningstar

Reputation: 9132

Don't subclass UIView for this. You should subclass uIView for custom drawing or in some cases custom handling for touches (but there are often better ways to handle touches).

Putting everything in your view controller and subclassing UIView are not the only options. You can create a class to manage the group of views that make up the header. It would conceptually be a view controller, but you don't subclass UIViewController, just inherit from NSObject.

Upvotes: 2

Kinetic Stack
Kinetic Stack

Reputation: 798

In my personal opinion, I would make theUILabels as properties of the UIView, so option 2. You can then access them from the view easily through the controller.

This also gives you the advantage of reusability from the view to any controller, and since dealloc will get rid of those from the UIView, you only worry about cleanup once!

Upvotes: 1

Related Questions