Some Practical Tips for Cocoa Programming

Okay, so you've read the essential book on Cocoa programming, read the PDF on the Objective C programming language that tells you about Categories and Protocols, and you're now well into your second application and you wonder if there is no way to make this easier for you.

Surely, the pros aren't spending half their day Googling for "Cocoa this" and "Cocoa that", or fighting the navigation of Apple's Cocoa docs to find out what to do next, or to recover information you looked up yesterday and have already forgotten again?

Here's a few tips about essential shortcuts and handy tricks that make Cocoa development in xCode (and the 10.2 version of Project Builder) a pleasure:

• xCode contains all of Apple's developer docs. See the "Help" menu for the Cocoa documentation. This window is a little on the slow side to come up, but works quite nicely when you leave it open in the background and be sure to always choose "Cocoa Help" and not xCode's help menu item (of course, reading xCode's docs and especially the FAQ is handy, too, but you usually only need to do that once, while Cocoa's docs are a constantly flowing source of enlightenment... sort of).
   
• Want to know what methods a class has, or what parameters a function you're using rarely took again? Open its header file for a quick reminder. Use the Open Quickly... menu item and enter the name of its header file, and it'll come up in a snap. Typically this is the class name followed by ".h" (e.g. "NSString.h"), but the mutable versions usually go with their immutable counterpart (i.e. NSMutableSet is in "NSSet.h"). You can also select the name of any header file (e.g. as part of a #import statement) and choose Open Quickly... to have it jump there immediately.
   
• Want the header or docs for a class, struct, constant, function or method, but don't remember what header it was in? Hold down the command key and double-click it to bring up the header. Hold down the option key instead to bring up the docs.
   
• Your application has an error that throws an exception, but you don't know where it is actually being caused? Yeah, wish there were an ObjC-equivalent to the Break on C++ exception menu item...
  Well, you can do it manually in GDB: After your application has started up (e.g. set a breakpoint in main(), or click Pause in the debugger after it's loaded the frameworks), bring up the Debugger Console. You'll see a (gdb) prompt. Type:
   
  (gdb) fb [NSException raise]
   
  You're telling the Unix-style GDB debugger to set a breakpoint on NSException's raise method. As you'll probably know, this method is what's called whenever an exception is thrown (or raised in Cocoa parlance). As soon as someone raises an exception, your app will break into the debugger, and you can look at the stack backtrace and the variable list to find out where it actually occurred.
   
• Looking for clarifications? Sample code? Tutorials? There are a few great places for that:
• Apple's documentation
  
• Apple's new Mailing List Search
  
• The third-party Cocoa-Dev and MacOS X-Dev archives at CocoaBuilder and Mamasam and of course the mailing lists themselves at lists.apple.com and OmniGroup
  
• Cocoa DevCentral - numerous wonderful tutorials
  
• O'Reilly's MacDevCenter - lots of articles and a few tutorials as well
  
• The CocoaDev Wiki - slightly unstructured like most Wikis, but a treasure trove of information - like most Wikis. Especially check out the ObjectLibrary page, with a list of pre-fabricated Cocoa objects available.