Update 9/30/11: This blog post isn’t quite complete. Have a look at Description Isn’t Enough, and remember to use debugDescription as well.
Joel and I have been discussing the kinds of content we’d like to work on putting in our quaint little corner of the internet, and I feel like, along with other content, it will be quite useful if we make an effort to include beginner level tips.
Everyone wants a log*
I first got started with Objective-C and Cocoa when my first generation iPhone was still running 1.x.x. The jail breakers had made the toolkits easy to use, and running home brew applications on the device was finally a reality. Unfortunately, this reality had one major pit fall – there was no tethered development, which meant there was no debugger. My debugging existence was made up entirely of log statements, and NSLog() had become my right hand man.
And this is where the good stuff starts:
NSObject, the class that sits under every Obj-C object you will ever create, has a method named description that returns a string. This is the string you will see if you use GDB to print the object, or reference the object using the %@ specifier in a formatted string.
From the documentation for NSObject
A string that represents the contents of the receiving class.
The debugger’s print-object command invokes this method to produce a textual description of an object.
NSObject’s implementation of this method simply prints the name of the class.
Common ways this method comes into play.
(gdb)po myObject
<MYObjectClass: 0x683c320>
NSLog(@"%@", myObject);
2011-07-26 08:50:43.975 MyApplication[19148:ef03] <MYObjectClass: 0x6a97ea0>
NSString *myDescription = [NSString stringWithFormat:@"%@", myObject];
Make It Yours
At this point, I’m sure everyone either knows where I’m going with this, or has already quit reading and set off to make their debugging logs more awesome. For those of you still with me, here’s the magic moment: You can make the log messages say whatever you want by simply overriding description in your classes! Amazing, isn’t it?
A lot of times, logged objects are pretty boring – you get a class name and a memory address *yawn*. But if you’ve ever logged an NSArray or UIView, it’s easy to see how things could be made much more interesting. For example:
<UIView: 0x6a991a0; frame = (0 20; 768 1004); autoresize = W+H; layer = <CALayer: 0x6a992c0>>
Classes, pointers, frames, autoresizing masks – oh my! Imagine you had a class with a few properties that were essential bits of information for debugging, rather than creating complex NSLog statements or multiple gdb commands, you could wrap them all up in a nice and pretty description.
+ (NSString *)description
{
// Abreviating variables like this is awful, don't do it!
// This is merely and effort to fit everything in
// this stupid narrow window.
NSString *format = @"<%@: %p; A = %@; B = %i>";
NSString *cStr = NSStringFromClass([self class]);
id a = self.A;
int b = self.B;
return [NSString stringWithFormat:format, cStr, self, a, b];
}
Voila – just like that, and you’ve got yourself with one hell of an informative log message.
note: If you aren’t yet comfortable with the various output options for formatted strings, I highly recommend bookmarking the String Format Specifiers
Console Spam
Now that you’ve got this fancy new tool for logging gobs of data to the console, TRY NOT TO BE A LOG SPAMMER! Be succinct in your object descriptions – a flood of data is no better than a dearth of it. Unless of course, your goal is to annoy coworkers, in which case I suggest using the following: Capital letters, symbols (the wider the better – @ is a good choice), and as many newlines as you can manage.
*It’s inappropriate to make references to the Ren & Stimpy “Log” song without a link, so here it is
Tweet