posted by Jared White on Wed 7th May 2003 07:13 UTC

"Page 4"

Here we come to the final bit of code for the MyPerson implementation:

- (void)sendPostcardWithMessage:(NSString *)message toAddress:(NSString *)address
  fromName:(NSString *)name returnAddress:(NSString *)returnAddress
{
    // send postcard code goes here
}

- (void)dealloc
{
    [fullName release];
    [address release];
    [dateOfBirth release];
    [hairColor release];
    [super dealloc];
}

@end

See that @end at the end there? That tells the compiler that your implementation code has ended. Good thing too, because we don't want this article to get too long! All kidding aside, there really isn't too much going on here. Obviously, I haven't implemented the send postcard code because, well, that would be quite a feat, wouldn't it? Moving right along to the dealloc method: this method is called automatically by the NSObject class itself when the object's retain count has gone down to 0, allowing you to take care of any "cleanup" needed before the object is deallocated. Since we want to be good citizens, we'll release all of our instance variables before the object is deallocated. We also don't want to forget to allow the superclass to get its cleanup work done too, so we'll send it a dealloc message at the end.

So there you have it. A more-or-less fully complete Objective-C class that employs several other Cocoa classes. Where do we go from here? I think this would be a good time to give a brief overview of what actually is in the Cocoa framework and what tools Apple makes available to use in creating Cocoa applications. Then I'll wrap up Part 2 by giving you a few more Internet resources to check out as well as some books that I've found to be very valuable.

As I've said before, the Cocoa framework is made up of two "sub-frameworks", or kits known as the Foundation Kit and the Application Kit (Apple now calls the Foundation Kit just "Foundation", but I prefer to call it the Foundation Kit). Why the two kits, rather than twenty, or one? Generally, the Foundation Kit contains all the basic data classes, classes that enhance the Objective-C language, and classes that allow access to low-level system services. The Application Kit contains all high-level application services classes, all the view (GUI) classes, multimedia services classes, and additional data classes (like color classes).

So how many classes are in these kits? Lots, and when you put them to work, they will save you a huge amount of precious time which would be better spent building the real guts of your application. The Foundation Kit contains classes for many different types of values (numbers for instance), strings (there are a number of classes that provide nifty ways of storing and manipulating text), binary data, dates, and even time zones. Another group of classes that are very useful are the container classes, such as arrays (similar to regular C arrays, these objects "contain" multiple objects ordered by number), dictionaries (objects that allow access to contained objects via associated key objects), and sets (which contain multiple, unique objects in an unordered fashion). Other classes include a file manager, a notification center (notifications are used all over the Cocoa framework; they allow you to easily broadcast different types of messages to any objects that have registered themselves with the notification center to receive those types of messages), a timer (an object that will send a message repeatedly at certain intervals to any object you specify), and many more.

The beautiful thing about the Cocoa data classes is the easy yet extremely powerful way in which they can save and open files. For example, you can create a string object, put some text in it, send it one single message, and poof! A text file is saved on your hard drive. Loading a text file back into a string object is similarly a no-brainer. But it gets even better. You can add a bunch of standard data objects to an array object, sent it a save message, and it will actually generate an XML-based "property list" file containing an entire tree structure of your data objects. You can nest the objects too: put some string objects in an array object, put that array object along with some other objects in a dictionary object, put that dictionary object along with another array object in another dictionary object, and then save that dictionary object. It will all be saved as a human-readable XML file that can be parsed using any XML parser on the planet. This method of data storage is so easy to use, so open, and so seamless that most Cocoa developers use it all the time, even Apple. In fact, Safari uses a property list file to store all of its bookmarks, and iTunes and iPhoto export a copy of their data libraries as property lists so that all the new iLife applications can access each other's data. The default format for storing application preferences is an XML property list as well.

Now what about the Application Kit? What kind of groovy things can we find there? How about windows, menus, buttons, sliders, tables, outline views, combo boxes, text boxes, rich text editors, toolbars, multiple-column data browsers, image views, and a whole lot more! The Application Kit is chock full of classes that are subclasses of the abstract class known as NSView. An abstract class is a class which, on its own, is fairly useless; it only does something interesting when it's subclassed. NSView provides a clean and simple interface to the display of graphics. It doesn't feature any drawing capabilities itself; it simply provides a "canvas" on which you can draw using other Cocoa classes. NSView is actually a subclass of NSResponder, which provides event handling such as for mouse and keyboard events. There's also a number of classes which stem off of the NSCell class. Many view objects use lightweight cell objects to perform the actual drawing for display and handling of events. Some view objects, like tables, use multiple cells at once. The Application Kit also contains numerous other classes which help with tasks such as printing, managing the clipboard, using standard interface elements such as Open and Save File panels, and the like.

That gives you a very rough idea of what kind of things you'll find in the Cocoa framework. But, in the end, the main question is this: how do you actually create a Cocoa application? Apple provides two main tools: Project Builder and Interface Builder. Project Builder is an IDE (Integrated Development Environment) that you use to create and edit application projects. Cocoa is but one of the many programming frameworks supported by Project Builder, and you can use Project Builder to build applications written in standard C, Java, and other languages as well. Project Builder handles all of the mundane tasks of creating a basic Cocoa application, setting up a build process for compiling the application, loading up debugging tools, etc. for you. In fact, you can literally go into Project Builder, select New Project from the File menu, choose a folder to save it in, and then press the Build & Run button in the toolbar to run your new Cocoa application. A blank window will appear along with a menu bar that really works -- all with you having written no code at all! Where does this window and menu bar come from? Read on...

Interface Builder, the other main tool I mentioned above, is one of the more brilliant aspects of the Cocoa development environment. Interface Builder allows you to access many of the Application Kit classes graphically. More to the point, it allows you to create the graphical interfaces for your applications and "hook up" your base application objects with your interface objects. Basically, what happens is that Interface Builder creates all these objects and "saves" them into a single package called a nib file ("nib" used to stand for NeXT Interface Builder, but now it just stands for nib). Just about every Cocoa application on the planet uses at least one nib file for storing all of the interface and related base objects. Nib files are loaded dynamically when your application is run, which means that all of the objects in the nib files are loaded into memory and are available for use. In some cases, all of the custom objects you use in your application can be loaded from a nib. Applications can also dynamically load nib files stored in "bundles" while the app is running, which lets you create an entire plug-in architecture for your application with a minimum of hassle.

So to answer the question of where does the window and menu bar of a brand new Cooca application come from: it is loaded from the default nib file that Project Builder automatically generates. Project Builder and Interface Builder are somewhat integrated; they can talk to each other and cooperate on how your project's code and its interface are glued together. I won't go into all of the details here, but, suffice it to say, you'll be toggling back and forth between Project Builder and Interface Builder a lot while developing Cocoa applications.

Table of contents
  1. "Page 1"
  2. "Page 2"
  3. "Page 3"
  4. "Page 4"
  5. "Page 5"
e p (0)    24 Comment(s)

Technology White Papers

See More