子类UIViewController或在非全屏视图时创建自定义NSObject

Question

I need to create a class controller to manage the behavior of a custom view I created. The standard approach is to subclass UIViewController, but in my case I instead decided to subclass the NSObject essentially for three reasons:

• my view needs to be added as small subview of the main view controller (it will not be displayed using something like presentModalViewController or pushViewController...) and it does not require any kind of toolbar or navigation control inside of it
• Most probably my controller will not need to be notified for device orientation because its view will be always used in portrait format, so I'm not interested to receive the usual rotation messages willRotateToInterfaceOrientation etc...
• I need to keep this class as lightweight as possible minimizing memory consumption. Not subclassing UIViewController have the advantage to obtain a lighter class without a bunch of methods that I will never need to use

The interface of my controller is pretty simple, example:

@interface MyScrollTabBarController : NSObject <MyTabBarViewDelegate> { }

/**
 * The view is created internally by the controller and the client class
 * can access to it in readonly mode
 */
@property (nonatomic, readonly) UIView *view;

/**
 * A Property to change the view appearance
 */
@property (nonatomic, assign) MyScrollTabBarViewState viewState;

/**
 * Others properties used to construct the view's subviews
 */
@property (nonatomic, retain) Location *rootLocation;
@property (nonatomic, readonly, retain) Place *place;

/**
 * Designated initializer
 */
- (id)initWithPlace:(Place *)aPlace;

- (void)setRootLocation:(Location *)location animated:(BOOL)animated;

@end

To display its internal view from the parent view controller, I will use something like this:

tabBarController = [[MyScrollTabBarController alloc] initWithPlace:aPlace];
tabBarController.viewState = MyScrollTabBarViewStateXX;
tabBarController.view.frame = CGRectMake(...); 
[self.view addSubview:tabBarController.view];

I'd like to know what do you think about my choice, if you think that there could be drawbacks in it and what do you usually do when you need to write a controller for a view which is not fullscreen like mine.

Thanks

Answer 1

I think this is an acceptable solution.

Another solution would be creating a "fat" view that does its controlling itself (like, for instance, MKMapView, UITextView etc.). This might make things a little more manageable, and if the view is very specialized, and its controller is intended to only work with this one class of view, you don't really lose any reusability (because there isn't much).

Answer 2

Yes, this is the correct approach.

UIViewControllers are specifically for controlling full-screen views, not for sub-screens. In iOS5 there is a mechanism for composing sub-screen viewcontrollers in this way, but that's not available in iOS4 without lots of hackery.

In cases where the view and controller are inherently coupled, you could also consider making a custom view subclass that is its own controller, so for example you could have a self-contained table view subclass that managed its own data and could just be dropped into a page.

Answer 3

what do you usually do when you need to write a controller for a view which is not fullscreen like mine

It is not important that your view is not displayed full screen. It is possible (and usual) to have views consisting of subviews which each have their own controller.

I need to keep this class as lightweight as possible minimizing memory consumption. Not subclassing UIViewController have the advantage to obtain a lighter class without a bunch of methods that I will never need to use

Subclassing UIViewController does not consume an unreasonable amount of memory, so this should not be part of the consideration.

[...] if you think that there could be drawbacks in it [...]

With your solution you loose flexibility. It is likely that you will reuse your solution in a context where you need to respond to UILifecyle-Messages or use other UIViewController features.

If your views shall be lightweight you could consider using a UIView subclass and use a delegate for the logic behind your view.

Answer 4

Hi You are subclassing NSObject and declaring a UIView inside it

@interface MyScrollTabBarController : NSObject <MyTabBarViewDelegate> { }

@property (nonatomic, readonly) UIView *view;

I Suggest you should subclass UIView, so you will not have to declare an additional view object.

so instead of self.view you can simply refer as self

tabBarController = [[MyScrollTabBarController alloc] initWithPlace:aPlace];
tabBarController.viewState = MyScrollTabBarViewStateXX;
tabBarController.frame = CGRectMake(...); 
[self.view addSubview:tabBarController];