12 Random Things

Inspired by the 7 sins of objective-c, here is my unorganized list of random dos and dont’s for iOS development.

1. Don’t kitchen Sink the AppDelegate

Any code in here should relate to UIApplicationDelegate tasks: launching, quiting, backgrounding, and foregrounding the app.

I know, it’s tempting to use the AppDelegate instance as your “global” singleton instance, but don’t do this. Create specific and seperate singletons if that is what you need. Things I’ve seen in AppDelegate:

• CoreLocation code
• Analytics code
• Database access code
• etc..

Don’t get me wrong, AppDelegate is the place to initialize these guys, but making AppDelegate the primary class that will contain the logic for these services is bad idea.

See also: Single Responsibility Principle (SRP) pdf link.

2. Don’t use the UIView “tag” property

UIView has a property called “tag” which is intended for tracking a view for later use. The tag property might as well be called “lazyHackUsedHere”. The biggest problem with the tag property is that its use always starts out simple, but over time the logic (or lack thereof) evolves into a fat unreadable mess.

Instead of tags, put UIViews into collections (array or set). If you just need a single view, then rely upon instance variables.

Tags are not obvious; they make figuring out heirarchies difficult. The key with collections and instance variables is they have names, which are incredibly useful in figuring out intent and purpose of the views being tracked. Debuging is much easier as well: as it’s much easier to introspect variables in lldb then it is to query the heirarchy for tags.

3. Don’t check-in Commented-Out Code

Don’t leave commented out code in production builds. (Also, please don’t make redundent comments on code that could simply explain itself.)

4. Don’t over complicate it

Don’t make methods that are many 100’s of lines long. Code should be a bunch of short single purpose commands.

5. Do use UIViewControllers

I’ve worked on a two projects that for some reason did not use UIViewControllers. The previous enginner built the entire UI with only UIViews—this is very bad! View controllers are useful for many reasons (MVC comes to mind), but ultimately they serve three concrete purposes:

• Provide rotation events.
• Provide appearance events.
• Provide system memory warnings.

You could implement each of these behaviors in your views, but why reinvent something that is given to you for free. Not only is this wasteful, but UIViews shouldn’t ever know about rotation and appearance, that’s what controllers are for!

6. Do Learn How to Create Containment View Controllers

You know the classic view controllers: UITabBarViewController and UINavigationController, well you can make your own containment controllers, these puppies are the key to creating custom navigation in your apps. Once you crack this task the possibilities are endless. Containment view controllers allow you to abstract complex navigations (and animations) while using memory efficiently.

7. Do use the delegate pattern

The delegate pattern is pervasive across UIKit, and once you learn how it leads to simpler code you’ll see why it’s used so heavily. Avoid passing messages through NSNotificationCenter whenever possible, it does have its purpose, but I can almost gaurantee you if that is your first choice then you’re doing it wrong.

8. Do use singletons where they make sense

Singletons are quite the controversy, but they definitely serve valid purpose in iOS apps. As a side note, the best way to implement singletons these days is with GDC.

Here are some valid use cases where I’ve used singletons (it’s easy to tell what they do based on the name alone):

• CoreLocationService
• DatabaseService
• CachingService
• MasterNetworkRequestQueue
• etc..

9. Do use a standard code style

Using a standard code style is all about consistency, and this is something that will most likely benefit others more than yourself. (That doesn’t mean this is optional.)

Also, don’t just make up your own style, unless you are that “cool”—then by all means, do what you want. Probably would be best to pick K&R Style or 1TB Style. See wikipedia for details on each of these.

I have failed at this one over the years, but recently have settled on using K&R style.

10. Do abstract complex views

Abstracting complex views as much as possible by subclassing UIView. This seems trivial, but to the guy who inherits your project it will make his life so much easier!

11. Do use latest and greatest language features

Use ARC and modern property syntax. Retain, release, and @synthesize are so 2012.

12. Do explicitly reference Nibs

If you must use Nibs, always explicity reference them in your view controllers or views. For UIViewControllers, UIKit will automatically load correctly named nibs, but I’ve been bitten by this feature a few times, as the nib file was hidden far away from the view controller.

This solves to probems: 1) simplies public interface, and 2) explicity shows that nib is being used and shows what the filename is.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// instead of this:
- (id)initWithNibNamed:(NSString *)name bundle:(NSBundle *)bundle
{
  if (self = [super init]) {
  
  }
  
  return self;
}

// explicity load the nib, like this:
- (id)init
{
  if (self = [super initWithNibNamed:@"NibNameGoesHere" bundle:nil]) {
  
  }
  
  return self
}