Learn Objective-C on the Mac - Mark Dalrymple [19]
CAUTION: Action methods are one area where Cocoa and Cocoa Touch are different. In Cocoa Touch, action methods can have one of three different method signatures, taking either zero, one, or two arguments. This is not the case for actions in Cocoa, which must take one and only one argument.
BUT WHAT ARE THEY?
You might be wondering just what IBAction and IBOutlet are. Are they part of the Objective-C language?
Nope. They’re good old-fashioned C pre-processor macros. If you go into the AppKit.framework and look at the NSNibDeclarations.h header file, you’ll see that they’re defined like this:
Confused? These two keywords do absolutely nothing as far as the compiler is concerned. IBOutlet gets entirely removed from the code before the compiler ever sees it. IBAction resolves to a void return type, which just means that action methods do not return a value. So, what’s going on here?
The answer is simple, really: IBOutlet and IBAction are not used by the compiler. They are used by Interface Builder. Interface Builder uses these keywords to parse out the outlets and actions available to it. Interface Builder can only see methods that are prefaced with IBAction and can only see variables or properties that are prefaced with IBOutlet. Also, the presence of these keywords tells other programmers, looking at your code in the future, that the variables and methods in question aren’t dealt with entirely in code. They’ll need to delve into the relevant nib file to see how things are hooked up and used.
Outlets and Actions in Action
That’s enough theory, let’s get our hands dirty by writing another Cocoa application. If you’re not still in Xcode, open it back up. Now, press ⌘N or select New Project… from the File menu. Select the Cocoa Application template again (if you’re running Snow Leopard, make sure the checkboxes for Core Data and Document-based application are turned off), and when prompted for a project name, type “Buttons.”
Enabling Garbage Collection
We mentioned earlier that Objective-C 2.0 includes support for garbage collection (usually abbreviated “GC”). By using GC, you’ll be able to write your applications more quickly and maintain them more easily, because you won’t have to worry about managing the memory your objects occupy. We’re going to use GC in nearly every application in this book, so try to dedicate the following steps to memory as you perform them. In the Groups & Files pane in Xcode, double-click the top-most item called Buttons. Double-clicking the root node in the Groups & Files pane brings up the Project Info window (Figure 3-2). This is where we can set a whole bunch of project-wide configuration options.
Figure 3-2. The Project Info window, where project-wide configurations can be set.
Select the tab labeled Build. Choose All Configurations from the Configuration popup list, so that the change we’re about to make will be applied to every way we might build our application (with or without code optimizing, and so on). Scroll down until you see a heading that reads GCC 4.0 - Code Generation. If you’re running Snow Leopard, it will instead refer to GCC 4.2. Underneath that heading, you should see an entry in the left-hand column that reads Objective-C Garbage Collection. Set the value next to it to Required. As of this writing, the default value for this setting is Unsupported, though that may change at some point.
We just turned on garbage collection for our project. Garbage collection is a relatively new feature in the Objective-C language that frees you from having to worry about most aspects of memory management, because the runtime keeps track of when objects are no longer being used and releases their memory on your behalf.
Garbage collection is not available on older versions of the Mac OS prior to Leopard (10.5), nor is it available on the iPhone. For Cocoa development that doesn’t need to support legacy versions of the operating