The simplest use of an action is probably adding a button to an application and then responding to the press of that button. As you’ll see, this turns out to be a lot easier than digging through individual touches.
We’ve opted to show you how to work with a button in two ways: first by using the addTarget:action:forControlEvents: method that we just introduced and then visually by using an IBAction declaration.
Both of these examples begin with your existing eventreporter program. You’ll add a simple UIButton to it visually. Place the button atop the label at the bottom of your page and use the attributes tag to label it Reset. With it in place and defined, it’s ready to be linked into your program by one of two different ways.
Both examples will call a method called resetPage:, which restores the three changeable objects in your eventreporter to their default states. It’s in eventreporter-ViewController.m, and as you can see it’s entirely elementary:
We can now look at the two ways you can call this method.
Using addTarget:action:forControlEvents: with a button
On the one hand, you may wish to add actions to your button programmatically. This could be the case if you created your button from within Xcode or if you created your button visually but want to change its behavior during runtime.
Your first step is bringing your button into Xcode. If you created your button visually, as we suggested earlier, you need to create an IBOutlet for the button, which should be old hat by now. If you didn’t create your button visually, you can do so pro-grammatically in Xcode. This probably means using the factory class method button-WithType:, which lets you create either a rounded rectangle button or one of a few special buttons, like the info button. By either means, you should now have a button object available in Xcode.
Your second step is to send the addTarget: action: forControlEvents : message as part of your application’s startup. Assuming that you’re having your view controller manage the button’s action, this message should be sent from the view controller’s loadView method (if your controller was created in Xcode) or in its viewDidLoad method (if you created the controller in Interface Builder).
Here’s what the viewDidLoad method of your view controller looks like when applied to a button called myButton:
This real-life example of addTarget:action: forControlEvents: looks much like the sample in the previous section. You’re sending a message to your button that tells it to send the view controller a resetPage: message when the user takes their finger off the screen while touching the button.
That single line of code is all that’s required; from there on out, your button will connect to your resetPage: method whenever it’s pushed (and released).
Using an IBAction with a button
The other way you can link up actions to methods is to do everything visually. This is the preferred choice if you’ve created your object visually (as we’ve suggested) and you’re not planning to change its behavior at runtime.
When you use this procedure, you don’t need to make your button into an IBOutlet. It’s effectively invisible from Xcode, which is fine, because all you care about is what happens when the button is pushed. You also don’t use the somewhat complex addTarget:action:forControlEvents: method that we just ran through; instead, you connect things via intuitive visual means.
For the purposes of this example, start with a clean slate: with a button freshly crafted inside the interface pane and no connections yet built.
To link an interface object to an action, you must declare the method you’re using as having a return of IBAction. This means adding the following declaration to the header file of your view controller:
The implementation of the method should share the same return.
Afterward, you can go into Interface Builder and create a connection, as shown in figure 6.7.
As shown, when you’re connecting a control, you’re given access to the entire palette of possible control events. You select the one (or ones) that you want to connect to IBActions, and then you drag over to the top-level object containing your IBAction. In this case, that’s once again the file’s owner object, which represents your view controller.
Figure 6.7 With an IBAction, there’s no code, just a link.
As usual, a menu pops up, this time showing possible IBActions to which you can link your control event.
The results are almost magical. With that single graphical link, you replace the addTarget:action:forControlEvents: call and any code of any type. The button now links to the targeted action automagically.
What we’ve described so far covers the broad strokes of actions; everything else lies in the details. If we spent less time on actions than events, it’s not because actions are less important than events, but because they’re a lot simpler.
From here on, your challenge in using controls will be figuring out how individual controls work. See topic A for an overview of classes and the Apple Class References for specifics. But there are a few controls that we’d like to give more attention to because they vary from the norm.
