48	CHAPTER 3: Handling Basic Interaction

Looking at the View Controller

A little later in this chapter, we’ll design a view (or user interface) for our application using Interface Builder, just as we did in the previous chapter. Before we do that, we’re going to look at and make some changes to the source code files that were created for us. Yes, Virginia, we’re actually going to write some code in this chapter.

Before we make any changes, let’s look at the files that were created for us. In the project navigator, the Button Fun group should already be expanded, but if it’s not, click the disclosure triangle next to it (see Figure 3–3).

Figure 3–3. The project navigator showing the class files that were created for us by the project template. Note that our class prefix was automatically incorporated into the class file names.

The Button Fun folder should contain four source code files (the ones that end in .h or

.m) and a single nib file. These four source code files implement two classes that our application needs: our application delegate and the view controller for our application’s only view. Notice that Xcode automatically added the prefix we specified to all of our class names.

We’ll look at the application delegate a little later in the chapter. First, we’ll work with the view controller class that was created for us.

The controller class called BIDViewController is responsible for managing our application’s view. The BID part of the name is derived automatically from the class prefix we specified, and the ViewController part of the name identifies that this class is, well, a view controller. Click BIDViewController.h in the Groups & Files pane, and take a look at the contents of the class’s header file:

#import <UIKit/UIKit.h>

@interface BIDViewController : UIViewController

@end

Not much to it, is there? BIDViewController is a subclass of UIViewController, which is one of those generic controller classes we mentioned earlier. It is part of the UIKit and, by subclassing it, we get a bunch of functionality for free. Xcode doesn’t know what our application-specific functionality is going to be, but it does know that we’re going to

www.it-ebooks.info

CHAPTER 3: Handling Basic Interaction

49

have some, so it has created this class for us to write that application-specific functionality.

Understanding Outlets and Actions

In Chapter 2, you used Xcode’s Interface Builder to design a user interface. A moment ago, you saw the shell of a view controller class. There must be some way for the code in this view controller class to interact with the objects in the nib file, right?

Absolutely! A controller class can refer to objects in a nib file by using a special kind of property called an outlet. Think of an outlet as a pointer that points to an object within the nib. For example, suppose you created a text label in Interface Builder (as we did in Chapter 2) and wanted to change the label’s text from within your code. By declaring an outlet and connecting that outlet to the label object, you would then be able to use the outlet from within your code to change the text displayed by the label. You’ll see how to do just that in this chapter.

Going in the opposite direction, interface objects in our nib file can be set up to trigger special methods in our controller class. These special methods are known as action methods (or just actions). For example, you can tell Interface Builder that when the user taps a button, a specific action method within your code should be called. You could even tell Interface Builder that when the user first touches a button, it should call one action method, and then later when the finger is lifted off the button, it should call a different action method.

Prior to Xcode 4, we would have needed to create our outlets and actions here in the view controller’s header file before we could go to Interface Builder and start connecting outlets and actions. Xcode 4’s assistant view gives us a much faster and more intuitive approach that lets us create and connect outlets and actions simultaneously, a process we’re going to look at shortly. But before we start making connections, let’s talk about outlets and actions in a little more detail. Outlets and actions are two of the most basic building blocks you’ll use to create iOS apps, so it’s important that you understand what they are and how they work.

Outlets

Outlets are special Objective-C class properties that are declared using the keyword IBOutlet. Declaring an outlet is done in your controller class header file, and might look something like this:

@property (nonatomic, retain) IBOutlet UIButton *myButton;

This example is an outlet called myButton, which can be set to point to any button in Interface Builder.

The IBOutlet keyword is defined like this:

#ifndef IBOutlet #define IBOutlet #endif

www.it-ebooks.info

50 CHAPTER 3: Handling Basic Interaction

Confused? IBOutlet does absolutely nothing as far as the compiler is concerned. Its sole purpose is to act as a hint to tell Xcode that this is a property that we’re going to want to connect to an object in a nib file. Any property that you create and want to connect to an object in a nib file must be preceded by the IBOutlet keyword. Fortunately, Xcode will now create outlets for us automatically.

OUTLET CHANGES

Over time, Apple has changed the way that outlets are declared and used. Since you are likely to run across older code at some point, let’s look at how outlets have changed.

In the first version of this book, we declared both a property and its underlying instance variable for our outlets. At that time, properties were a new construct in the Objective-C language, and they required you to declare a corresponding instance variable, like this:

@interface MyViewController : UIViewController

{

UIButton *myButton;

}

@property (nonatomic, retain) UIButton *myButton; @end

Back then, we placed the IBOutlet keyword before the instance variable declaration, like this:

IBOutlet UIButton *myButton;

This was how Apple’s sample code was written at the time, and also how the IBOutlet keyword had traditionally been used in Cocoa and NeXTSTEP.

By the time we wrote the second edition of the book, Apple had moved away from placing the IBOutlet keyword in front of the instance variable, and it became standard to place it within the property declaration, like this:

@property (nonatomic, retain) IBOutlet UIButton *myButton;

Even though both approaches continued to work (and still do), we followed Apple’s lead and changed the book code so that the IBOutlet keyword was in the property declaration rather than in the instance variable declaration.

When Apple switched the default compiler from GCC to LLVM recently, it stopped being necessary to declare instance variables for properties. If LLVM finds a property without a matching instance variable, it will create one automatically. As a result, in this edition of the book, we’ve stopped declaring instance variables for our outlets altogether.

All of these approaches do exactly the same thing, which is to tell Interface Builder about the existence of an outlet. Placing the IBOutlet keyword on the property declaration is Apple’s current recommendation, so that’s what we’re going to use. But we wanted to make you aware of the history in case you come across older code that has the IBOutlet keyword on the instance variable.

You can read more about Objective-C properties in the book Learn Objective-C on the Mac by Mark Dalrymple and Scott Knaster (Apress, 2009) and in the document called Introduction to the Objective-C Programming Language, available from Apple’s Developer web site at http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC.

www.it-ebooks.info

CHAPTER 3: Handling Basic Interaction

51

Actions

In a nutshell, actions are methods that are declared with a special return type, IBAction, which tells Interface Builder that this method can be triggered by a control in a nib file. The declaration for an action method will usually look like this:

- (IBAction)doSomething:(id)sender;

or like this:

- (IBAction)doSomething;

The actual name of the method can be anything you want, but it must have a return type of IBAction, which is the same as declaring a return type of void. A void return type is how you specify that a method does not return a value. Also, the method must either take no arguments or take a single argument, usually called sender. When the action method is called, sender will contain a pointer to the object that called it. For example, if this action method was triggered when the user taps a button, sender would point to the button that was tapped. The sender argument exists so that you can respond to multiple controls using a single action method. It gives you a way to identify which control called the action method.

TIP There’s actually a third, lesser-used type of IBAction declaration that looks like this:

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

We’ll talk about control events starting in the next chapter.

It won’t hurt anything if you declare an action method with a sender argument and then ignore it. You will likely see a lot of code that does just that. Action methods in Cocoa and NeXTSTEP needed to accept sender whether they used it or not, so a lot of iOS code, especially early iOS code, was written that way.

Now that you understand what actions and outlets are, you’ll see how they work as we design our user interface. Before we start doing that, however, we have one quick piece of housekeeping to do to keep everything neat and orderly.

Cleaning Up the View Controller

Single-click BIDViewController.m in the project navigator to open the implementation file. As you can see, there’s a fair bit of boilerplate code that was provided for us by the project template we chose. These methods are ones that are commonly used in UIViewController subclasses, so Xcode gave us stub implementations of them, and we can just add our code there. However, we don’t need most of these stub implementations for this project, so all they’re doing is taking up space and making our

www.it-ebooks.info