ADC Home > Reference Library > Technical Notes > Legacy Documents > Cocoa >
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
|
What Is SimpleCocoaApp?SimpleCocoaApp is a really simple application. No, really. SimpleCocoaApp consists of less than 20 lines of code, but that is all it takes to get a whole truckload of features. This application admittedly doesn't do very much useful work, but it does handle radio buttons, Pop-Up menus, the Help menu, window processing, button clicks, text field input, and an About Box. Here's a screen shot of the application in action (see figure 1):
SimpleCocoaApp uses three main objects, instantiated (created) from three different custom classes:
Here's how the different objects interact: Most controls in Cocoa have a target object associated with them, which is sent an action message (a message is similar to a method call) when the control is triggered. How the control looks on the screen and functions as a widget is handled by the Cocoa infrastructure, so that all you have to implement are the target objects and their action messages. Such is the case here.
Now let's explore the process of writing this application. Setting Things Up in Interface BuilderAfter creating a new Cocoa application in Project Builder, typically the first thing you will do is open MainMenu.nib to design your user interface and classes in Interface Builder. Since SimpleCocoaApp has already been written for you, you can simply double-click the Project Builder .pbproj file to open the project and then double-click MainMenu.nib in the left-hand-side file list. In MainMenu.nib, you will find the Hello1, Hello2, and HelloController classes under the Classes tab in the nib window, and the instances of Hello1, Hello2, HelloController and MyWindow under the Instances tab. The first step taken in SimpleCocoaApp was to create the Hello1, Hello2, and HelloController custom classes (by hitting return while a class like NSObject was selected under the Classes tab). Further steps included instantiating instances of these custom classes, and dragging controls/views into place on the window (MyWindow in this case). Apple encourages developers to adopt Aqua user interface guidelines for a consistent user experience; a link to further documentation can be found at the end of this technote. Once you've reached this stage in your application, you will want to connect up UI and your custom classes so they can send each other messages and tell each other to do things (grab values, set values, change behavior, whatever). This is done graphically here in Interface Builder, so there is often no need to do any of it in code. Instantiated objects are connected in two main ways in Interface Builder:
To establish either of these connections, you control-click on the object that will be the source of messages, and drag the cursor to the object that will be the destination of the messages. This creates a gray line between the two objects. Then you can navigate the outlets and actions in the inspector, and click "Connect" to establish the connection. You will find that establishing outlet connections involves dragging one way, and establishing target-action connections involves dragging back the other way between objects. The key thing to remember is to always control-drag in the direction that messages will flow.
For example, in Figure 2 you can see that we are connecting an outlet called "messageTextField" in the instantiated Hello1 object to the NSTextField object that will hold the text to display for Hello1's
On the other hand, Figure 3 shows us setting up the target-action connection for the "Say Hello..." button. Since the button will send the action message to its target when the button is clicked, we can see that messages flow from button to target, and thus we control-drag from the button to Hello1. Then we choose the action "message1:" and click "Connect" in the inspector.
Though it takes time to graphically setup the user interface, in the long run it saves time over trying to accomplish the same thing in pure source code. A this point, hitting Command-R (Test Interface in the File menu) will run a great deal of the user-interface portion of the application, without any code. Controls will work, buttons will click (though no actions wired to your custom code objects will be called), menus will appear, and so on. All this is the functionality you get for free in Cocoa without writing one line of code! The final step to take before turning to the source code is to create skeleton header/source files for your custom classes by control-clicking on them in the "Classes" tab and choosing "Create Files...". Then, with the user interface designed, the custom objects instantiated, and the connections all made, we can turn to the source code for SimpleCocoaApp that implements our custom functionality. Main.m
Listing 1. short and sweet! As can be seen in Listing 1, nothing much goes in The Hello1 and Hello2 ObjectsThe Hello1 and Hello2 classes are virtually identical, the only difference being in the identifying title string placed on the dialog they present. The description here of Hello1 applies equally to Hello2 - the point of having the two classes is to demonstrate how to switch a control's target on the fly, so that only at runtime can you know for sure what lines of code will be executed when the "Say Hello..." button is pressed. We turn now to Hello1.m, the implementation file for the Hello1 class. Although a class skeleton with empty methods can be easily generated by Interface Builder, it is up to the programmer to write the method implementations. Hello1 has three methods to implement:
Listing 2. -message1: and -message2: are both implemented like so.
Listing 3. -message3: is a little more clever than the other two message routines. In Listing 3 above, The HelloController ObjectHelloController is the real "brains" class behind SimpleCocoaApp. It does whatever processing is needed when the app starts up, it handles switching action messages and targets, and makes sure that help is displayed properly. It does all this in two short methods.
Listing 4. - switchMessage: is called when the user picks a different message to display by clicking a different radio button. The really important line in Listing 4 above is the last one.
Listing 5. -switchObject: is called when the user picks a different object to receive messages using the PopUp menu.
So that is all the source code. But what is powering the Help menu for SimpleCocoaApp? Where is the code for that? It turns out that with Cocoa you don't need any code to do it! By putting your html help files in the Resources folder in the application bundle, setting the "AppleTitle" html metatag to list the title of your "help book," and tweaking your Info.plist file (that goes automatically in the app bundle and is editable from Project Builder), you can get automatic Help Menu support - Help Viewer will be launched at the appropriate time, and your help book (merely an html file titled "ReadMe.html" in this case) will be opened.
SummaryAll in all, about 10 lines of source code - and look at all the functionality you get! The real challenge for you the developer going on from here is to learn as much of the Cocoa frameworks as possible, so that you don't reimplement something yourself which is already done for you by Cocoa. Below are some links to documentation and the sample code this technote is based on.
Online DocumentationMac OS X Developer Documentation (as well as Adopting Aqua documentation)
Downloadables
|
|