miekd

First things first, I am not a ‘hardcore programmer’, I pretend to know what I’m doing when I have a bunch of code in front of me, and stuff seems to work out quite well (and if it doesn’t, I’ll waste twenty hours trying to find the file I should’ve included) Let’s just settle on the fact that I code from a user perspective, which will not end me up with the ‘best project structure’ award, but does give me an insight into programming with a totally different view.

So after about 100 hours in Xcode and about half that time searching Google for ways to do stuff with the iPhone SDK, it came to one thing bothering me; the Interface Builder.

Apple provides the Interface Builder as part of the iPhone SDK, yet it’s effective use towards iPhone development is questionable. If you take your time looking at the Interface Builder, it seems to be quite an exquisite addition to the IDE. Yet if you think in a structural sense, the Interface Builder doesn’t really fit in. Yet since I have this masochistic tendency towards finding out how the different ways of developing work, I’ve tried to find a spot for the Interface Builder in my workflow.

This has led me to the following conclusions:

1. Don’t create the basic flow of your App in the Interface Builder. Sure, all the examples have a bunch of NIBs with a lot of stuff in them, but stay away from this practice. The basic flow of an iPhone app isn’t that complicated anyway, so just build your basic flow by code, inside your App Delegate. This way the core code of your applications stays in a single place.

   
   	// Create a Tab Bar
   	// You can also define it in your interface and synthesize it.
   	UITabBarController * tabBarController = [[UITabBarController alloc] init];
   
   	// Create a View Controller
   	UIViewController * firstViewController = [[UIViewController alloc] initWithNibName:nil bundle:nil];
   		
   	firstViewController.view = [[UIView alloc] initWithFrame:CGRectZero]; // Add a view to the ViewController
   	firstViewController.title = @"Title 1";
   	firstViewController.tabBarItem.image = [UIImage imageNamed:@"FILENAME"];
   
   	// Create a Nav Controller to put the View Controller in
   	UINavigationController *firstNavController = [[[UINavigationController alloc] initWithRootViewController:firstViewController] autorelease];
   	[firstViewController release]; 
   
   	// Add Nav Controller to the Tab Bar
   	tabBarController.viewControllers = [NSArray arrayWithObjects:firstNavController, nil]; 
   	
   	// Make sure you have a window synthesized!
   	[window addSubview:tabBarController.view];
   	[window makeKeyAndVisible];
   

2. Refrain from creating simple views in the Interface Builder. If it’s simple, it’s easy to code. This way you … * .. keep your Xcode project clean.
   * .. have a single way of working with these views, therefore never have to search for random references you had to create with the Interface Builder
   * .. can replicate this views easily, by just copy pasting code; no references = no strings attached.
   

So what is the Interface Builder good for?

1. It is good for creating rich, modular elements of interface. For example: the creation – and replication – of visually complex UITableViewCell’s. Here the Interface Builder services the developer by having an easy way to visually replicate the design delivered to him by the designer, while allowing for a structured hook-in with the code by adding a few IBOutlet’s.

   An example I implemented recently. What I needed was a structured way of creating table cells, with the ability to easily visually improve it in a later stage.

   

2. Next to that, you can’t beat the Interface Builder when we talk about “Static Views”. If you have an “Info View” that displays static information about the app and the parties involved, there is no reason to code this all by hand.\
   

Bottom line: Don’t define your App Structure in the Interface Builder. As long as you follow this guideline, you will be fine. If you prefer a properly structured project, keep away from the Interface Builder except when creating small modular parts of an interface.