Tutorials 

by Dr. John Timmer, Contributing Editor

Introduction

Although the majority of the concepts that are necessary for using Cocoa will be built up as we go through our projects, there are a few basic techniques that will be recurring themes throughout these tutorials. This introduction will cover them so that they don't surprise you when they come up in the future.

Using Objective-C

Currently, there's a variety of languages that give access to the Cocoa toolkit, including Java, AppleScript, and Python. Natively, however, Cocoa is implemented in Objective-C; the rest of these languages access Cocoa's classes through a bridge, which wraps Obj-C classes into something that can be accessed by the protocols of a different language. Although these bridges work remarkably well, they invariably seem to lead to occasional problems, either unexpected behavior or limitations in what can be accomplished. Like most things, there are tradeoffs - many people find the syntax of these languages simpler, and they definitely handle all the memory management for you. Given these trade-offs, how do we choose? Objective-C offers one thing that the others don't - if Cocoa doesn't provide the capabilities you need, using Obj-C provides you with access to Unix capabilities and the guts of the OS in a way that the others can't. In the end, syntax is a matter of taste, and memory management isn't so painful in Obj-C, so it won't be that bad.

Given that, it's worth describing a bit of Obj-C syntax for those people familiar with other languages. Most of Obj-C is just like standard C, with if, while, and for statements, all ending in semicolons. There are two big differences between how you'd work with Obj-C and standard C. First, since this is an Object-oriented language, most of what you'll find yourself working with are pointers, or variables which hold a reference to an object's location in memory. This gets a bit tricky, since setting one object equal to another with a statement like:
object1 = object2;
doesn't leave you with two copies of the object, but rather makes both point to the same object. As a result, doing something to alter object2 would alter the same memory that object1 points to. Instead, you have to explicitly create a copy:
object1 = [object2 copy];

The other difference is that having an object perform a method (a.k.a. function) requires you to send it a message enclosed in brackets:
[anObject doMethod];
To send variables to that method (a.k.a. arguments), you precede the argument with a colon:
[myObject doMethodWithArgument: theArgument];
and multiple arguments are always preceded by descriptive text in the method name:
[myObject doMethodWithArgument: theArgument andOtherArguemnt: theOtherArg];


Finding Information

The first stop should always be the documentation included with Apple's Developer Tools, which you should already have bookmarked in your browser of choice. It's worthwhile noting one aspect of these docs that isn't necessarily obvious: many of the Cocoa classes are subclasses of another Cocoa class, and all of them are subclasses of NSObject. A result of this is that not all of the methods that work with any class are in the documentation for that class. Fortunately, Apple's included links to all the other classes at the top of the documentation page (an example appears below); if you can't find the method to do what you need, keep looking further up the inheritance chain - you may find that it's implemented by a super class.

Looking at the Inheritance chain of a Cocoa class:


Beyond that, like most things, finding what you need can simply be a matter of going to Google. Searching for terms that may apply outside of computing (ie - "wake from sleep") or OS'es in addition to Apple's, however, will get you a lot of irrelevant information. To confuse matters a bit further, Apple's Developer site has a Google-powered search engine. Where do you do your searching? There is a simple way to decide what's worth using Google for and when to try Apple: If you can use a specific Cocoa or Core Foundation class name in your search, go with Google. You're likely to get mailing list entries, and the replies to questions there are likely to include cogent explanations and sample code. There's also not a lot in the world other than Cocoa classes that start with "NS", so other results won't overwhelm the useful information there. For something more general, like "Network available", Google will return lots of irrelevant information; at that point, going to Apple's search is more likely to get you what you want.

In addition to information on the web, there's also a couple of useful mailing lists for Cocoa programming. One is from Apple - it's worth signing up for. To prevent spammers from harvesting addresses from the list archives, they're password protected. This has the unfortunate side effect of keeping them from showing up in Google. Apple does, however, provide its own search interface. Some others are available through the OmniGroup - these have been scanned by Google, so you don't have to do anything special to get their postings to show up in your searches.

There are several websites that are also worth following for their frequently helpful tutorials. I'll just list them as links below; this list may expand based on reader feedback, so you may want to check back on occasion:
Stepwise
Cocoa Dev Central
O'Reilly's Mac Dev Central


Catching Problems:

There are three techniques that I typically use to track down problems in ProjectBuilder projects. The first is simply using the debugger, Project Builder's GUI for the gdb debugger. You can find detailed information on how to use it in the Developer Documentation, at /Developer/Documentation/DeveloperTools/ProjectBuilder. The debugger is especially useful for situations where your code is crashing or not producing the expected value. You can set a debugging breakpoint above the region of code you suspect is causing the problem, then step through the code one line at a time, following how values change and seeing which line of your code is defective.

In some cases, however, your code will behave in unexpected ways or cause crashes at points which are hard to identify using the debugger. In these cases, you may want to try keeping track of what code your program is executing by logging. You can insert the command "NSLog(@"your text here");" anywhere you'd like (and with any text) in order to keep track of which code gets executed when you run the program from Project Builder. This is a great way to keep track of whether a section of your code is getting executed, or which methods are called before a program crashes.

The last technique I frequently use is the combination of two command line utilities, top and leaks. top is useful for finding out information on your program's memory use: typing "top -l1 | grep "your program name" into the terminal will return information on its current memory use. Repeating that over the course of a couple of days or after some intensive user interaction can give you a feel for whether your memory use is stable. If it's not, you can repeat the process, this time checking the memory situation after time and use with the program leaks. Type "leaks " and the process id number (the first number in the line that top returned), and it will give you information on the status of allocated memory that the program's lost track of. If you do this right after the program launches, you'll often get a list of a few things that were used during initialization, which are harmless, since you only initialize once. Repeating this after a while or heavy interaction, and you'll often get a few more. Many of these will shortly be culled by the Obj-C runtime. If a lot of these new items stay around after a few minutes of further inactivity, you know you have a problem. leaks also gives you the memory contents and class information, you may even be able to tell which part of your code is likely to be causing the leak, though many of the Cocoa classes are registered as their underlying Core Foundation equivalents.



If you've made it this far, you're familiar with several of the things which will recur throughout these tutorials. You're probably ready to get started with a little programming, so tomorrow we will move on to the next section, where we'll build a GUI-less application that will help familiarize us with some of the things that Cocoa offers.

If you have any questions or comments about this article, feel free to e-mail me at john_timmer@osxfaq.com