Jan 082010

So there isn’t a real way to write private methods in Objective-C.

What I tried to for a while is to just write the methods in the .m file and simply omit the declarations in the .h file. This would be quite annoying when you call the private methods before they are defined in the .m file because Xcode would give warnings.

One convention we’re using to deal with this is to define a (Private) category at the top of .m file containing all the declarations of the private methods. By doing this, you’re letting the compiler know that  about the “private” functions that these functions will exist, so the warnings go away. It’s also a nice way to communicate to the readers of your code that the methods are private. The (Private) category is defined inside the .m file, so it really remains, well, private.

Here is a real example from our Say a Secret project:

#import “BadAssButtonController.h”
#import “ButtonUtil.h”
#import “Debug.h”

// Private methods

@interface BadAssButtonController(Private)

-(void) doneAnimating_;


@implementation BadAssButtonController

@synthesize overlayImage;
@synthesize button;
… blah blah

 Posted by at 9:09 pm
Jan 082010

holy crap I just realized that 2 in binary is 010. 2 + 010 = 2010. Do you know what this means? It’s the end of the world of course.

Well, whatever surfing that I missed out on during the summer of 2009 because I was too busy cutting PNGs for Say a Secret ™, I’m doing it these days. I’m actually going out to Pacifica tomorrow. There are swells coming in, and the conditions are supposed to be good. I’m feeling even better because I got home about 30 minutes ago and fixed a bug (that I created a few weeks ago which went unnoticed) without too much hassle. All thanks to a small bit of reading I did over the summer.

The book is Cocoa Programming for Mac OS X. This book is badass. It filled all the gap in my knowledge about Xcode, Cocoa, Objective C in one schbang. Thanks Aaron, you’re awesome. Chapter 1 even ends with a little motivational section on “How to Learn.”

Besides the general badassery of the book, I want to point out one of the strongest aspects, in my opinion of course, of this book – it is very hands-on. It doesn’t try to sugar-coat with dense jargon or make you feel itty-bitty by using theoretical mumbo jumbo. It even tells you *gasp* how to debug. And it was what I learned from this section of the book on how to debug that saved the day.

We’ve all seen it – the cryptic stack traces you see in Xcode when things foobar:

2008-08-01 21:10:20.138 Tomatoes[151:20b] *** Terminating app due to uncaught exception ‘NSRangeException’, reason: ‘*** -[NSCFString replaceCharactersInRange:withString:]: Range or index out of bounds’
2008-08-01 21:10:20.213 Foobar[151:20b] Stack: (
terminate called after throwing an instance of ‘NSException’

I’ve seen some tips on how to decode this stack trace using ‘atos’ or whatnot. Guess what, I’m too lazy for that. I’d rather sprinkle NSLog statements than cut & paste some numbers around.

News flash! There is an easier way folks!

Step 1: From the menu go to Run -> Manage Breakpoints -> Add Symbolic Breakpoint, and add “objc_exception_throw”. Now you’re all set – your Xcode is now badassified to automatically break whenever you write crappy code that throws an uncaught exception.

Step 2:  Write crappy code and make your code crash. C’mon, you know how to do this.

Step 3: Run your code – when it craps out, you’ll see the ‘(gdb)’ prompt and your program has auto-suspended.

Step 4: Find that little spray can icon back in your Xcode IDE. It’s somewhere right above the editor.

Voila, now your see the stacktrace right in your IDE. No commandline incantation or nuttin. Now let’s go back to life & surfing.

 Posted by at 8:52 pm