{"id":666,"date":"2010-08-15T22:09:40","date_gmt":"2010-08-16T03:09:40","guid":{"rendered":"http:\/\/vgable.com\/blog\/?p=666"},"modified":"2010-08-15T22:09:43","modified_gmt":"2010-08-16T03:09:43","slug":"my-uiviewcontroller-template","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2010\/08\/15\/my-uiviewcontroller-template\/","title":{"rendered":"My UIViewController Template"},"content":{"rendered":"

I haven’t formalized this as a proper Xcode template, but this is what’s in my PrototypeViewController.m<\/code> file that I copy\/paste over the UIViewController<\/code> subclasses Xcode makes.<\/p>\n

\n
\n\n@interface MyViewController ()\n@end\n\n@implementation MyViewController\n- (void) releaseViewObjects;\n{\n\tif([[self superclass] instancesRespondToSelector:@selector(releaseViewObjects)])\n\t\t[(id)super releaseViewObjects];\n}\n\n- (void)viewDidUnload;\n{\n    [super viewDidUnload];\n    [self releaseViewObjects];\n}\n\n- (void)dealloc;\n{\n    [self releaseViewObjects];\n    [super dealloc];\n}\n\n@end\n<\/pre>\n<\/div>\n
Here are the reasons why, in no particular order:<\/p>\n
Commented-Out Code is Evil<\/h3>\n
Littering source code with “comments” full of crufty, obsolete, or unimplemented code is not a good thing. Xcode’s default template is full of commented-out code<\/strong>. If you’re totally new to the platform, starting from the templates aren’t a bad way to learn.  But in my experiance, they do harm to a production code-base, by injecting hundreds of lines of commented-out code into a project.<\/p>\n
Share code between viewDidUnload<\/code> and dealloc<\/code> With  releaseViewObjects <\/code><\/h3>\n
In my world, releaseViewObjects<\/code> is solely responsible<\/strong> for cleaning up every IBOutlet<\/code>, and any objects created in viewDidLoad<\/code>.<\/p>\n
There are technical reasons why this is a little scary. Calling a method in dealloc<\/code> is potentially risky, because the object may be in an invalid half-torn-down state, and because Dark Runtime Magicks<\/a> could be afoot (see Using Accessors in Init and Dealloc<\/cite><\/a>.)<\/p>\n
But in my experience, such bugs, although as scary as they sound, are rare corner-cases and still quite fixable. But every<\/em> UIViewController<\/code> needs to clean up after itself, so simplifying the universally common case is a net win.<\/p>\n
The if([[self superclass] instancesRespondToSelector:@selector(releaseViewObjects)])<\/code> test wouldn’t be necessary if I added another class between UIViewController<\/code> and my real code, so that I was sure my class’ super<\/code> implemented releaseViewObjects<\/code>. But adding a subclass just to implement one empty method, to avoid a two-line test, isn’t worth it.<\/p>\n
The (id)super<\/code> cast is intentional, to prevent compiler warnings.<\/p>\n
I have to use the more complex [[self superclass] instancesRespondToSelector:<\/code> test, because -[super respondsToSelector:]<\/code> doesn’t work<\/a>.<\/p>\n
I Won’t Really<\/em> Get To didReceiveMemoryWarning<\/code><\/h3>\n
I’m not proud to admit this, but it’s true. We’ve all been told that a good iPhone program must<\/em> release resources when it gets a memory warning, or else it will be killed. But in practice, there have always been better places to spend my time (or at least it sure feels that way!) Spending a few hours in Instruments to fix leaks prevents memory warnings in the first place, and that’s a bigger win.<\/p>\n
Besides, 80% of what didReceiveMemoryWarning<\/code> would do is handled in  releaseViewObjects<\/code><\/strong>, which is automatically called by the default implementation.<\/p>\n
So I break with Xcode and leave didReceiveMemoryWarning<\/code> out of my template, because the default class won’t use it<\/em>.<\/p>\n
What About init<\/code>?<\/h3>\n
I don’t have a default init(With\u2026)<\/code> method. I try to use autorelease<\/code>-ed objects everywhere I can<\/strong>, so I’m more comfortable implementing +[MyViewController viewControllerForFoo:]<\/code>.<\/p>\n
But I don’t have a default constructor of any<\/em> kind, because a constructor should take every value it needs<\/em><\/strong>, and I don’t know what these values are until I’ve written a bit more of the class. It’s a chicken and egg problem.<\/p>\n
Once I’ve written out a bit more of the class, I’ll usually build something that looks like:<\/p>\n
\n
\n+ (RouteMapViewController*) routeMapViewControllerWithWaypoints:(NSArray*)waypoints mapRegion:(MKCoordinateRegion)region;\n{\n\tRouteMapViewController *vc = [[[self class] new] autorelease];\n\tvc.title = NSLocalizedString(@\"The Path\",@\"\");\n\tvc.hidesBottomBarWhenPushed = YES;\n\tvc.waypoints = waypoints;\n\tvc.mapRegion = region;\n\treturn vc;\n}\n<\/pre>\n<\/div>\n
For what it’s worth I use this pattern to implement a 0-argument -init<\/code><\/a>.<\/p>\n
Empty Class Extension<\/h3>\n
Class extensions<\/a> are the best way to have “private” things in Objective-C. They let the compiler catch objects using another object’s private methods. They let a class have publicly readonly<\/code>, but internally readwrite<\/code>, properties.<\/p>\n
Bottom line: every nontrivial object I’ve written uses them, so they’re in my template.<\/p>\n
Nothing Else (For Now)<\/h3>\n
My template is smaller than Xcode’s. That is by design. Outside of esoteric contests<\/a>, having less code to maintain is a good thing. So I prefer a template that tries very hard to avoid adding code I don’t need.<\/strong><\/p>\n
Do you disagree with any of my choices? Please leave a comment explaining why<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"
I haven’t formalized this as a proper Xcode template, but this is what’s in my PrototypeViewController.m file that I copy\/paste over the UIViewController subclasses Xcode makes. @interface MyViewController () @end @implementation MyViewController – (void) releaseViewObjects; { if([[self superclass] instancesRespondToSelector:@selector(releaseViewObjects)]) [(id)super releaseViewObjects]; } – (void)viewDidUnload; { [super viewDidUnload]; [self releaseViewObjects]; } – (void)dealloc; { [self releaseViewObjects]; […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[203,5,4,13],"tags":[241,609,610,134],"class_list":["post-666","post","type-post","status-publish","format-standard","hentry","category-iphone","category-objective-c","category-programming","category-sample-code","tag-best-practices","tag-template","tag-uiviewcontroller","tag-xcode"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/666","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=666"}],"version-history":[{"count":1,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/666\/revisions"}],"predecessor-version":[{"id":667,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/666\/revisions\/667"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=666"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=666"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=666"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}