Generic Objects

Although most objects in the library are provided by the platform and have a known type, the library also contains generic objects (Figure 8-1) that you can use to represent any class in your project. Using these generic objects lets you incorporate custom code that is not otherwise part of the Interface Builder library. Placeholder objects, like File’s Owner, are another type of generic object whose class you must set prior to use.

To add a custom view or object to your Interface Builder document, do the following:

1. Drag the desired object from the library.

   • For a generic view, drop it onto your window’s design surface. (You can also drop views onto the Interface Builder document window if you just want a view resource without a surrounding window.)

   • For a generic object, drop it into your Interface Builder document window.

2. Select the view or object.

3. Open the identity inspector.

4. Use the available controls to configure the class information.

   • In Cocoa and Cocoa Touch nib files, configure the class name using the Class Identity section of the identity inspector; see Figure 8-2. Type the name of your class in the Class field or use the combo box control to select the class from the current list of known classes.

     

   • In Carbon nib files, specify the Class ID of the class in the Class Identity section of the identity inspector.

If your nib file is associated with an Xcode project, Interface Builder attempts to complete the class name automatically as you type it. When the class is set, Interface Builder displays the known outlets and actions for that class in the inspector. If your nib file is not associated with an Xcode project, Interface Builder displays the class name but does not display any outlets or actions initially. You can add outlet and action information using the appropriate sections of the inspector if you like. If you do so, however, you must manually add those same outlets and actions to your source files later. For information about using Interface Builder to define outlets and actions, see Defining Outlets and Actions in Interface Builder.

Custom Objects

Because the Classes library makes it easy to instantiate your custom classes, the recommended workflow is:

1. Create your custom classes in Xcode.

2. Instantiate them in Interface Builder by dragging them out of the Classes library.

This eliminates the need to drag out a generic view or object and then set its custom class.

Defining Outlets

The IBOutlet and IBOutletCollection keywords signal to Interface Builder that you want to populate a variable with real objects when a nib file is loaded. Outlets can be weakly typed or strongly typed in your code. Weakly typed outlets (those whose type is id) can be connected to any object in your nib file. Strongly typed outlets can be connected only to an object whose class matches the type of the outlet.

To add an outlet to a class, you can insert the IBOutlet keyword in front of its instance variable declaration, as shown in the following example:

@interface MyClass : NSObject

{

    IBOutlet id        aGenericOutlet;

    IBOutlet NSView*   aViewOutlet;

}

@end

If you use this approach, you should define accessor methods that ensure the objects are retained at runtime.

In Mac OS X and in iOS 3.2 and earlier, you can connect an outlet to only a single object. However, starting with iOS 4.0, you can connect an outlet to multiple objects. To do so, use the IBOutletCollection keyword. For example, to connect a view controller to multiple objects of type UILabel, you could add the following code in Xcode:

@interface MyController : UIViewController {

    IBOutletCollection (UILabel) NSArray* multipleLabels;

}

@end

If the output targets are not all the same kind of object, use id for the object type in the declaration, or omit the object type in the parentheses following IBObjectCollection; for example:

@interface MyController : UIViewController {

    IBOutletCollection (id) NSArray* multipleObjects;

}

@end

A better approach is to declare each outlet as a property. The IBOutlet or IBOutletCollection keyword goes immediately before the property’s type information and after any parenthetical attributes, as shown in this example:

@interface MyClass : NSObject

{

    id        aGenericOutlet;

    NSView*   aViewOutlet;

    NSArray*  multipleLabels;

    NSArray*  multipleObjects;

}

@property (nonatomic, retain) IBOutlet id aGenericOutlet;

@property (nonatomic, retain) IBOutlet NSView* aViewOutlet;

@property (nonatomic, retain) IBOutletCollection (UILabel) NSArray *mutipleLabels;

@property (nonatomic, retain) IBOutletCollection (id) NSArray *mutipleObjects;

@end

For more information about properties, see The Objective-C Programming Language.

Defining Action Methods

An action message sent by an object to its target results in the invocation of an action method on the target object. In essence, this is just another way of saying that the object that sends an action message does so simply by calling a method of its target object. Therefore, in order to define an action, you actually define an action method on the corresponding target object. The definition of this method is where you respond to the action. For example, if the user clicks or taps a button, the corresponding action method is where you would write the code to respond to the button interaction.

In Cocoa applications, an action method takes a single parameter of type id and returns the type IBAction, which is defined as void. The name of the action method can be anything you want but is typically evocative of the action being performed. For example, to respond to a click in a button, you might define the following method in the controller object that manages the button:

- (IBAction)respondToButtonClick:(id)sender;

In Cocoa Touch applications, an action method can take one of three forms, shown here:

- (IBAction)respondToButtonClick;

- (IBAction)respondToButtonClick:(id)sender;

- (IBAction)respondToButtonClick:(id)sender forEvent:(UIEvent*)event;

Action methods do not require a one-to-one correspondence with the controls in your interface. You can define one action method for each control in your interface or several controls can share a single action method. When present, the sender parameter in an action method contains the object that sent the action and can be used to help process the action. In iOS, the optional event parameter conveys additional details about the specific type of event that triggered the action.

If you subclass standard system classes, you should check the definitions for any parent class before adding your own custom action methods. For example, many Cocoa classes already implement cut:, copy:, and paste: action methods to respond to pasteboard actions. Using inherited action methods lets you respond to messages sent by your own code and also messages sent by the system. In general, you should implement custom action methods only when the action methods provided by parent classes are insufficient or do not provide the behavior you need.

Defining New Classes in Interface Builder

The ability to reference unknown classes in Interface Builder lets you rapidly prototype your user interface without worrying about the underlying code. You can change the class name and change the names of outlets and actions as needed. Once you are satisfied with your prototype, you can generate source files for any unknown classes from Interface Builder and begin writing the code for those classes. After generating the source files, you can also specify the superclass for your class. For information about generating class files, see Generating Source Files for New Classes.

Defining Outlets and Actions in Interface Builder

When present, the Class Outlets and Class Actions sections of the Library window display the known outlets and actions of the currently selected class. In addition to viewing the existing list of outlets and actions, you can also add new ones using the controls found in these sections. You would typically use this feature during prototyping, when your nib file does not yet have an associated Xcode project. For example, you might create a new class for your prototype and add outlets and actions to get a sense of what behaviors you would need in your code.

To add an outlet or action, do the following:

1. Click the plus (+) button in the appropriate section to add the new action or outlet.

2. Type a new name.

   As you type the name of an action method, Interface Builder displays warnings in the Class Actions section of the inspector to let you know if you are specifying an invalid method name.

   In Mac OS X, action methods take a single parameter and therefore the method name must end with a colon (“:”) character.

   In iOS, action methods may take zero, one, or two parameters.

3. Optionally, specify a custom type for outlets by typing the appropriate class name. (You can also change the parameter type of action methods, although id is the standard parameter type.)

To remove a custom defined outlet or action, select it in the identity inspector and click the minus (-) button. You can remove only those outlets and actions you previously added using Interface Builder. You cannot remove outlets and actions you created in your Xcode source files or those defined in a Cocoa parent class.

The outlets and actions you add using the Library window remain local to Interface Builder and your Interface Builder document. Interface Builder does not attempt to merge these outlets and actions back into your Xcode source files; you must do that manually. You can write out source and header files containing the outlet and action definitions for your class by choosing File > Write Class Files. You can then use the generated files as your initial source or merge their contents in with your existing source files using your favorite merge tool, such as the FileMerge application.

Generating Source Files for New Classes

If you create new classes using the Library window, you can ask Interface Builder to create an initial set of source files for those classes. When generating source files, Interface Builder also generates the appropriate set of member variables and methods corresponding to the outlets and actions of the class. This feature helps your prototyping efforts by eliminating the need to recreate your class definitions manually in Xcode.

To generate source files for a class you defined in Interface Builder:

1. Select the object that uses the desired class.

2. Choose File > Write Class Files.

   Interface Builder prompts you to save the new source files.

3. Open the header file.

4. Specify the superclass information for the class.

Beginning in Interface Builder 3.2, you can generate or update source files using the classes tab in the Library window:

1. Select the class for which you want to generate or update source files.

2. Display the action menu and choose Write Updated Class Files or Generate Class Files.

After generating the source files, you should add them to your Xcode project and make any future changes from there. Changes made to source files in your Xcode project are automatically picked up by Interface Builder, but the reverse is not true. Interface Builder does not update source files after it generates them. Instead, you must incorporate any additional changes into the source files manually from Xcode.