Understanding a bit better Interface Builder

If you have been playing with Interface Builder for the iPhone development and you have found it a bit difficult to understand, here is a post with some basic ideas to help you to understand how it works and interact with your code.

As a newbie on the iPhone, but more on Mac development, this tool is a bit weird and difficult to understand from the beginning.
The basic difference is that when you load Xib files you create instances of the objects defined inside, in opposition to other tools, like let’s say Visual Basic, which generates code. Interface Builder also creates the links among the components and actions defined in the Xib file and your code when it is loaded.

The first point is the three objects that appears the first time you open a Xib file:
File’s Owner, First Responder and the Application delegate.
Not all classes included in the Xib file are instantiated, there are also Proxy Objects, these proxy objects are in fact references to instances in your code, these are the links between your code and the objects created out of the Xib file, when the file is loaded.

To understand what is the File’s owner you need to see the code uses to load the Xib file:
NSArray *nib = [[NSBundle mainBundle] loadNibNamed:@”CustomCell” owner:self options:nil];

In this line, self is the File’s owner. In the process of loading the file and creating the instances of the objects defined inside, this process also links the IBOutlets defined in the File’s Owner with the instances.
If you select File’s Owner and open the Connections Inspector (Tools->Connections Inspector (⌘ 2)) you will see the object names linked with the outlets of the selected object.

First Responder is also a proxy object, it points to the first responder in the responder chain. This allows you to send messages to the responder chain throw this element. With the Identity Inspector (Tools -> Identity Inspector (⌘ 4)) you can see and add new Actions to the First Responder. You can then link, for instance, the push of a button to these actions.

It is more frequent to send actions to functions in objects using the IBAction keywork, so the fact is that usually you don’t send messages to the First Responder but you link actions in buttons to specific functions in classes, defined this way:
- (IBAction)touchGo:(id)sender;

The Application delegate is another proxy object that only appears in the “MainWindow.xib” when an application is created by XCode, there is a link automatically created among the File’s owner delegate Outlet and this Application delegate (to see this select the File’s owner and push ⌘ 2).

You can also see (selecting the Connections of the application delegate) how the outlets defined in AppDelegate.h are linked with the window and the UINavigationController (in case of an application of this kind) with those elements in the MainWindow.xib

@interface CustomTable1AppDelegate : NSObject {

IBOutlet UIWindow *window;
IBOutlet UINavigationController *navigationController;
}




The main idea, again, is that the objects that you create on the Xib file are in fact instances, created when the Xib file is loaded. And to have access to those objects you have to create Outlet to link you code with those instances, or if you load directly a Xib file calling loadNibNamed:owner:options: you can go through the array returned to access directly the objects instanciated.

It is quite frequent to have custom UITableViewCell in a Xib file and load it programmatically and access the cell with this code:
NSArray *nib = [[NSBundle mainBundle] loadNibNamed:XibName owner:self options:nil];
cell = [nib objectAtIndex:1];

Hopefully this has help you to understand how IB works.