Friday, April 25, 2008

The Dangers of Beta

Okay, I'm debating whether to continue this series on Web Services using libxml. On one hand, I think there is a benefit to going through the process, and I'm guessing that a wrapper around libxml is going to be pretty fast and resource-efficient.

But... SDK4 introduced Cocoa's tree-based parser, NSXML, to the iPhone SDK, which is much easier and more pleasant to use in a Cocoa app. As a result, it might make sense to focus my energies on other iPhone technologies.

If you want an introduction to NSXML, you'll have to look in the Core Library docs, the iPhone docs have not yet been updated with these classes. I do not know yet if there are significant changes between the two versions or not. You can also check out this article over at MacTech from a few years ago written by yours truly which talks about using NSXML. It might be a little outdated at this point, but should give you at least a conceptual grounding. If I find they have completely change NSXML since then, I'll let you know; I'm going to try to find time today to play with the iPhone version of NSXML.

Friday, April 18, 2008

Web Services Fun

Before we work more with libxml, let's talk about web services. Web services are a good practical application of XML and, it would seem to me, many iPhone apps will need to work as web service clients, so it seems like a good detour.

The easiest way to access web services from Objective-C is by leveraging functionality found in Core Services, a framework that is available in both Cocoa and Cocoa Touch. For both platforms it needs to be manually linked into your project as it is not included by default in the Xcode templates.

For a Cocoa project, simply select Project -> Add to Project... then add the framework found at the following location to your project, making sure to uncheck the "copy into your project folder" option:
For the iPhone, well, you'll need to figure that one yourself; I've already gotten in trouble once with Apple for telling people where it is, but if you use Spotlight, you should be able to find it without too much difficulty.

Now once you've got the Core Services framework included in your project, how do you use it? Well, if the web service you want to access has a WSDL then it's really quite easy. As part of the Developer tool install, a little command line utility was installed on your machine called WSMakeStubs which will generate stubs with all the methods you need to access that web service. For a Cocoa project, the way to use it is as follows:
WSMakeStubs -x ObjC -name MyClassFileName -url http://server:port/path/to/wsdl
So, let's say that we wanted to create stubs for accessing the National Weather Service. For that, you would type this:
WSMakeStubs -x ObjC -name WeatherService -url
Once you issue that command, it will create four files for you:
  • WeatherService.m
  • WeatherService.h
  • WSGeneratedObj.m
  • WSGeneratedObj.h
The first two implement the class you'll actually use to interact with the web service, the second two are generic classes that you need in your project, but which will be generated every time you run WSMakeStubs. If you run WSMakeStubs again, you can just delete the new versions, as they will be exactly the same as the ones you already have.

No, go ahead and add these four files to any Xcode project where you want to access the web service. If you're playing along at home, I just created a Foundation Tool Xcode project and added the four files to it. We need to import the WeatherService.h file wherever we intend to use it, like so:
#import "WeatherService.h"
In order to use this service, we need to know what functions this web service exposes to us. So, how do we know what methods we can call? Well, you can look at the WSDL or documentation that goes along with the web service if those are available. If not you can simply open up WeatherService.h and scroll down toward the bottom. The last @interface declaration in the file — ndfdXMLService — is the class we'll be working with. You'll notice that it has several class methods which you (of course) remember are the methods that begin with a + rather than a -.  These class methods correspond to the functions exposed in the web service. Let's pick one to try out, shall we? How about:
+ (id) LatLonListZipCode:(CFTypeRef /* Complex type|zipCodeListType */) in_zipCodeList;
This is the simplest one in the web service, so that makes it good for showing the basics of accessing a web service. Now, whenever possible, WSMakeStubs uses known datatypes when constructing method calls. Sometimes, however, you'll see parameter specified as CFTypeRef, which is similar to id in that it's a generic pointer whose type is not specified. That means either that that parameter is more complex than a single datatype can hold OR that WSMakeStubs was unable to determine which datatype or object would be best for holding that parameter. Since it knows it doesn't know everything, WSMakeStubs includes a comment with a link to the XSD file where the parameter is defined to help you out. 

The problem is, it's not obvious nor well-documented how to use web service methods that take CFTypeRef parameters. It's easy enough to figure out how to pass in a raw datatype, but not so easy otherwise.

Now, unlike this particular one, a great many web services will take only simple parameters and will be relatively easy to use. Here is an example of how you might call such a web service function:
id result = [myWebService callMethodThatTakesInt:1];
The value of result will either be an NSString or an NSData instance depending on the web service. Ordinarily, the result will contain XML data with the web services response to your call.

But what do we do in this case since we have a complex type? Well, unfortunately, we have to read the documentation and poke around the stubs and experiment a little. In many cases, complex objects expect an NSDictionary with the xml tag name used as the key and the tag's contents as the corresponding object. For complex types where there are nested tags, some of the objects in the NSDictionary you create might themselves be NSDictionary instances. Because of this, building your parameter objecs can get fairly complex in some instances. 

Fortunately for us, it turns out that this web service function just takes a single string containing a space-separated list of zip codes. Well, we can do that. Heck, we can do that in one line of code:
id result = [ndfdXMLService LatLonListZipCode:@"13413 94588 12901"]; 
Notice that we are using NSString, and not c strings here. You could also use CFString because they are toll-free bridged to NSString but since we're in Cocoa, let's stick with Cocoa, shall we?

After running this code, result will be a string that contains XML with tags representing the longitude and latitude for each of the zip codes passed in. Blogger won't let me paste that XML in - it keeps thinking the XML is HTML and if I change the tags to use > and < it helpfully converts those back to angle brackets. *sigh* Well, the price is right. Anyway, you can see the XML here if you want.

Now, we have the server's response in XML... if only we had an easy way to parse XML in Cocoa and Cocoa Touch. Oh, wait... I, um...  promised you something vaguely similar to that yesterday, didn't I? :)

Coming next: The libxml wrapper and a little practical application of it.

Thursday, April 17, 2008

Simplifying libxml

As I mentioned in my previous post, XML handling on the iPhone is through the open source libxml library, which is a procedural C-based API. We can also use libxml in Cocoa, and if you have an eye toward re-using your code on the iPhone, it's probably not a bad idea to use libxml instead of NSXML. It also means I can show you how to use libxml without using the iPhone SDK and violating the NDA. 

To use libxml in your Cocoa projects, you just need to do one thing in your Xcode project settings, which is to add /usr/include/libxml2/** to your Header Search Paths build settings:
This will tell your project where to find the header files for libxml.

Now, to use libxml to parse XML data contained in an instance of NSString, say we had:
NSString *xml; // string containing XML
We need to make sure we import the necessary header file:
#import <libxml/xmlmemory.h>
Next, we have to tell the library to parse this data. Being a procedural C library, libxml knows nothing about NSString, which is an objective-C class class cluster, so we have to convert our NSString into a c string, like this:
xmlDocPtr doc = xmlParseMemory([xml UTF8String], [xml lengthOfBytesUsingEncoding:NSUTF8StringEncoding]);
If this was successful doc will not be NULL. Now, how do we get values from this? Well, we can get the root node like this:
xmlNodePtr root = xmlDocGetRootElement(doc);
xmlNodes are implemented as doubly linked lists, a construct that we don't use much in Objective-C, although it's likely used under the hood in the implementation of some of the collection classes. This abstraction is different from how we commonly work in Objective-C. Ordinarily, we have an object that represents the collection and we call methods on that collection object to get to the objects that it contains. In an old-school linked list like this, the xmlNode object pointed at by an xmlNodePtr represents both the node itself and the collection. Now, there is only going to be one root node in most situations but let's look at how we would get to the children of the root node.

It's actually pretty easy. We declare another node pointer and point it at the nodes's children like so:
xmlNodePtr node = root->children;
Now, the children pointer gives us a single node, but that node is also our access to all of the node's siblings and children. To iterate through all the nodes at this level, we can loop like this:
xmlNodePtr cur_node;
for (cur_node = node; cur_node; cur_node = cur_node->next)
 // Do something
This loop keeps going until it gets to the last item in the linked list. The last item has NULL as its pointer to next, so the loop stops. Similarly, we can loop through a node's children like this:
xmlNodePtr children;
for (children = node->children; children; children = children->next)
 // Do something
To get a node's name, we just look at the name member of the xmlNode struct, which is a c string. So, if we want to find a node with a specific name among a node's children, we would do it like this:
NSString *nameToSearchFor = @"Id";
xmlNode *child = NULL;
for (child = node->children; child; child = child->next)
if (strcmp((char *)child->name, [aName cStringUsingEncoding:NSUTF8StringEncoding])==0)
// Do something with the node
To determine the value of a node - the value between the begin and end tab in your XML like this: 
It's a little more complicated, but not much. To obtain its value as a string:
xmlChar *ret = xmlNodeListGetString(doc, node->children, 1);
Notice that we pass not the node, but the node's children pointer. This is because the text between the begin and end tags counts as a child.

At this point, I think you can see how mixing a procedural C API with Objective-C code looks a little ugly. On the other hand, I believe that Apple must have had good reason to not port NSXML to the iPhone, probably having to do with performance, but that is just conjecture on my part. So, how can we make our code look nicer without imposing significant additional overhead? 

Well, we can create a very low-overhead Objective-C wrapper. In the internals of the class, we use libxml for performance, but then convert to and from Objective-C objects in our accessors and mutators. This gives us a nice compromise between performance and readability, so our code can look like this without adding significant processing overhead:
 NKDLibXMLDocument *doc = [NKDLibXMLDocument documentWithRawXML:result];
NKDLibXMLNode *root = [doc rootNode];
NKDLibXMLNode *user = [root childNamed:@"User"];
NSLog(@"Id: %@", [user valueForChildNamed:@"Id"]);
NSLog(@"FirstName: %@", [user valueForChildNamed:@"FirstName"]);
NSLog(@"LastName: %@", [user valueForChildNamed:@"LastName"]);
Doesn't that look nicer? Isn't it easy to tell what's going on in that code? We hide all the nastiness away in a couple of classes and then never have to deal with it again. Yeah, that's the ticket.

I've still got some work to do on on the wrapper class, but I'll post it in the next day or two.

Tuesday, April 15, 2008

Web Services Fun

Well, I got a proof of concept iPhone application working today. It's not ready to show off yet, as it's little more than a command-line application running in an iPhone window, but I was able to authenticate against a Tririga web service, pass in a username and password, then parse the results.

The iPhone does not have support for NSXML, unfortunately, so we're stuck using the procedural libxml api. Using libxml inside of an OO environment is like pulling teeth. It's a great procedural API, but compared to what you can do with a good high-level language, it's just downright ugly. I'm sure the performance is much better than NSXML, but the code it takes to use it is really, really ugly looking.

It took me longer than I expected, but I've now got the hang of using libXML, and have written a few utility functions to make my life easier. I may try wrapping it up into a low-overhead objective-C wrapper. If I do, I'll post the results here.

In the next day or so, I hope to have a full proof-of-concept iPhone app to submit a work request through Tririga.

Golden Ticket

I still have not gotten an acceptance letter from the iPhone developer program, much to my dismay, but I am finding great amusement in the fact that the iPhone dev community has taken to calling these acceptance letters "Golden Tickets" which is, of course, a reference to the great Roald Dahl's Charlie and the Chocolate Factory. I must admit that anticipation for getting the ability to test my apps on an actual iPhone makes me feel much the same way as Charlie must have when peeling back the wrapper of that Wonka Bar.


If you're new to the platform, the best thing you can do is go to WWDC this year. Yes, it's expensive, especially if, like me, you no longer live in the Bay Area (or perhaps, never did). But WWDC is an unparalleled chance to learn about the iPhone. There will be a huge number of sessions and hands-on labs, and it's a great opportunity to meet other programmers. The labs are an unparalleled opportunity to have your code looked at by Apple engineer.

If you are a company looking to build iPhone apps or port your existing apps to the iPhone, you really, really, really, really (and really) should send your iPhone programmers to WWDC. The return on your investment will be astounding. Don't bother sending project managers or non-technical folk - this isn't a marketing, lovey-dovey kind of convention. This is a hardcore technical crowd, but there's an awful lot of smart people there and a lot of good information to be gotten.

Friday, April 11, 2008

Idiocy Can Come with Many Letters After Its Name

The iPhoneDevSDK Blog blogged about an interesting article today. And by interesting I mean, of course, startlingly idiotic, as you can probably tell just from the sensationalist title "How the iPhone is killing the Net".

It just goes to show that you can be professor at a prestigious school and still be clueless concerning topics on which you believe yourself to be an expert.

Thursday, April 10, 2008

The Root of All Evil: Introduction to Optimizing Objective C

Donald Knuth has a very famous quote: "[P]remature optimization is the root of all evil"1. This is a valuable idea to keep in your head while programing. It's actually okay to write inefficient code at times. In the context of Objective-C, this means it's okay to use provided methods and objects in your first pass at writing algorithms, even if you know that those objects or methods might not be the optimal way to do the task in terms of performance. Get the code working, and get it working right, and then go back and optimize intelligently where it make sense. In many places small inefficiencies will have no noticeable affect on your application, and by leveraging thoroughly-tested code from Cocoa which was written by knowledgeable Apple and NeXT engineers, you likely saved yourself considerable time and maintenance headaches.

But, there are times when inefficient code has an impact and needs to be addressed. In Java, Visual Basic, Ruby, and the other high-level languages, there is a lot you can do to optimize your code, but there is a limit to what you can do because those languages insulate you from the inner workings using mechanisms such as garbage collection, and a lot of the code that is running when you run your code is completely outside of your control. In all of those languages, you can help the runtime know when it's okay to free up memory that you're done with it by following good coding practices, but memory management is mostly out of your hands. Other optimizations like loop unrolling can be used in these languages, but the performance yield tends to be less than from the same optimizations in a low-level language compiled directly to machine code.

Here's where Objective-C really has a leg up. It is a high-level language and has a lot in common with Java, VB, and C#. It has garbage collection (well, not on the iPhone, yet) and exception handling and it shields you from many low-level implementation details as a good high-level language should. But, Objective-C is a super-set of C, and even though it does have a small runtime engine to enable object messaging and other features, most of your code gets compiled down to machine language. You are shielded from the low-level implementation details, but not prevented from getting to them. When you have exhausted your options for optimizing using Objective-C and Cocoa, you always have the option to lift up the hood and use good old-fashioned procedural C to optimize even more. A great Objective-C programmer needs to be at least a good C programmer.

Let's take a look at an example of optimizing a small chunk of Objective-C code.

Let's say that we have an NSData that contains encoded binary data stored as 8-bit ASCII characters. In this encoded data,  we need to look for certain sequences of characters to make sure that it contains the type of data it's supposed to. These tags are simple sequences of ASCII characters (aka c-strings). 

Here is my first, quickly written version leveraging built-in Cocoa objects. This was written as part of a category on NSData, so any reference to self is a reference to the NSData object holding the encoded binary data.

I apologize for the code formatting. Blogger is not cooperating and refuses to believe me when I tell it that my code is preformatted using the pre tag.

The Original, Horribly Non-Optimized Version

-(BOOL)containsCString:(char *)cmp
NSUInteger offset = 0;
char * byte;
const char * bytes = [self bytes];

while (offset < [self length])
byte = (char *)bytes ;
NSString * checkString = [NSString stringWithCString:byte length:strlen(cmp)];
if ([checkString isEqualToString:[NSString stringWithCString:cmp length:strlen(cmp)]])
return YES;

return NO;

Shall I leave it as an exercise for the student to identify just why this code is poor from an optimization standpoint? I'd better not, though the problems are likely obvious to many of you.

First of all, I'm allocating autoreleased objects inside of a loop. And that loop goes byte by byte through a potentially large chunk of data. None of the memory for those objects will be released until the end of the current pass through the run loop, which won't happen until after my loop finishes. I create two autoreleased NSString instances for every byte in the data and then run a string compare between them. NSString is a complex class cluster designed to deal with a multitude of string encodings, and could potentially be using multi-byte characters to represent these strings, meaning that each compare could be comparing two or even three bytes rather than just one. Now, the NSString class cluster is smart and probably won't use multi-byte encoding unless it needs to, but since that's not our code and the algorithms are not documented, we can't know for sure what it's going to do, and it's possible that something in our data could trigger the use of multi-byte encoding

So, basically, I'm being very, very inefficient with both memory and processing power here. That may not be important, depending on how I'm using this in my application, and this version only took me a couple of minutes to write, so if I do this rarely and the chunks of encoded data are small, perhaps this is going to be fine just the way it is. But there's the potential for real problems with this code in an application. 

One way to find out if it's going to be a real problem is to set up unit tests (you do use unit tests, right?) that use representative situations similar to what the code will face in the actual application.

For grins and giggles, let's run MY unit test on this method, which takes two three-megabyte chunks of encoded data - one that contains the tags being searched for and one that doesn't - and do two searches on both chunks. The result? 6.8  seconds to do the two searches on each of the two three-megabyte chunks running it on a a 2.6ghz MacBook Pro. That's definitely a potential Spinning Beachball of Death situation. I guess we'd better look at optimizing, huh?

Note that the amount of time it takes to run this code will depend on a number of factors, and it will not be the same every time, but it only varied by a few milliseconds over a dozen runs, so I'm pretty confident it's the algorithm that's slow and not something else running at the same time2.

First Optimization

The first and most obvious optimization here is getting the comparison string allocation out of the loop. That value does not change at all during the loop, so let's move it up to before the while statement so that only happens once per call to this method. In theory that should significantly reduce memory overhead and probably reduce the processing time significantly as well. Here's the new version:

-(BOOL)containsCString:(char *)cmp
NSUInteger offset = 0;
char * byte;
const char * bytes = [self bytes];
NSString *compareString = [NSString stringWithCString:cmp length:strlen(cmp)];
while (offset < [self length])
byte = (char *)bytes ;
NSString * checkString = [NSString stringWithCString:byte length:strlen(cmp)];
if ([checkString isEqualToString:compareString])
return YES;

return NO;

Let's run the unit test and see what happens. And the result? This time it runs in a little faster, clocking in at 3.7 seconds. A significant improvement, but not fast enough to avoid that spinning beach ball. Perhaps I'm going to have to spawn threads. I'm going to be doing this encoding a lot in my application. 

So, is there a way I can improve it more? Is there any way for me to avoid autoreleasing so many NSStrings, or even creating them at all? Well, there are a couple of options. I could manually allocate and release the string objects. That would be considerably more efficient than filling up the autorelease pool, in theory. 

The Second Optimization

Here's what we get if we manually allocate and release our NSString instances rather than letting them go into the autorelease pool. This should help with our memory overhead, but it's unclear how much of a speed increase it will give us:

-(BOOL)containsCString:(char *)cmp
NSUInteger offset = 0;
char * byte;
const char * bytes = [self bytes];
NSString *compareString = [NSString stringWithCString:cmp length:strlen(cmp)];
while (offset < [self length])
byte = (char *)bytes ;
NSString *checkString = [[NSString alloc] initWithCString:byte length:strlen(cmp)];
if ([checkString isEqualToString:compareString])
return YES;
[checkString release];
return NO;
We run it and? 3.44 seconds. Hm.. An improvement, but not a huge one by any means. It does appear that creating strings is one of our bottlenecks. In a more complex method, we would probably have to resort to using Shark or Instruments to identify where our bottlenecks were, but in this case, it's pretty obvious where the problem is.

So, let's look at doing this in straight C. After all, we're just comparing chunks of memory. C can do that, and it can do it fast without the overhead of objects or string encodings or anything else.

The Final Optimization

Instead, let's forget about using NSString or NSMutableString, and just use C. We'll work with pointers, and use some old-school techniques for comparing buffers.

-(BOOL)containsCString:(const char *)cmp
NSUInteger offset = 0;
const unsigned char * bytes = [self bytes];

while (offset < [self length])
if (memcmp(bytes++, cmp, strlen(cmp))==0)
return YES;

return NO;

This version doesn't create any new Objective-C objects, it simply uses a C function that compares to chunks of memory. Now there is no overhead due to the objects, and none due to string encodings or conversions. 

So, just how much faster is this? Let's run our unit test and find out. How about 0.4 seconds? Not terrible at all for doing a byte-by-byte search through 12 megs of data, especially when half of the data it had to search didn't contain the thing it was looking for.

Concluding Thoughts

We could take this further. There are optimizations we could do to this that would eke out several more milliseconds, and if our code needed to process huge chunks of data, that would probably be worth investigating (and might be a good idea for a future posting), but for my purposes, I've decided that this is good enough performance for my needs. The point of this article was not really to teach you how to optimize your code, and certainly is not showing you the fastest possible implementation of this algorithm, but I did want to drive home the point that Objective-C is C, and that as nice as all the object-oriented goodness is, there are times when it makes sense to roll up your sleeves and do things old school, an option that most high-level languages don't offer, but Objective-C does. I also wanted you to see some of the rather common kinds of mistakes you often see in high-level languages that cause memory bloat and performance bottlenecks so that you'll be less likely to make them in the future.

The timings in this article were all done using the Debug target. The final optimization dropped down to .1 seconds by switching to the Release target, and I was able to drop it even lower by implementing a reverse iterator for the end tag.

1 - Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268
2 - It does, indeed, help to know that I intentionally wrote this inefficiently.

Wednesday, April 9, 2008

SDK Beta 3 is Out

iPhone SDK Beta 3 came out last night. You can, if you're a registered iPhone developer of course, download it from Apple's iPhone Dev Center.  The "Cocoa Touch Application" Xcode template now includes an xib file, and they've added a main nib file key to the property list file. There is also a nice new tutorial on creating Apps that use IB. The tutorial is not easy to find on the Dev Center web site, but they included a link to it in the notification e-mail that went out last night.

Tuesday, April 8, 2008

You're Doing it Wrong! A Brief Discussion of Categories and the Cocoa Way

Let's talk about a part of the Objective-C language that is somewhat unique: Categories. Well, not completely unique: the latest edition of C# has added something called Extension Methods, which is very similar, but it hasn't been around long enough to have really sunk into the collective psyche of .Net developers yet. Other than this recent addition to C# and the obscure language TOM, I don't personally know of any programming languages that have an equivalent to Objective-C categories. There probably are some floating out there, but the "biggie" languages in the world of object-oriented programming - Java, Ruby, Python, C++ - do not have an equivalent construct. 

Categories are ├╝ber-cool, and almost universally underused by programmers new to Objective-C. Although I'm not a big fan of C# or .net, I have to give Microsoft kudos for recognizing awesomeness and incorporating it. Let's keep our fingers crossed that they use it as effectively as the NeXT and Apple engineers have in Cocoa.

A lot of people who come to Cocoa from other languages and read Apple's reference book on Objective-C  skim over the section on Categories, say "cool," and then move on. Heck, Apple's own Objective-C primer makes no mention of categories, which is just a shame, because Cocoa programmers use categories a lot. So, what are they, you ask?

Simply put, categories allow you to add methods to existing classes without subclassing them. You can't add instance variables (colloquially called "iVars" or "ivars" in the Cocoa world) or properties, but you can add both class and instance methods with impunity.

So why is this cool? Let's take an example, and look at the design choices available to us in Objective-C versus other languages. I'll use a real-world but very simple example here, but there are countless examples in a programmer's day-to-day life where categories can make your overall code base more elegant, many of which are more complex and more compelling than this one.

One of my current side projects is building two Cocoa-based NNTP clients (for accessing Usenet ): one for the Mac and the other for the iPhone. Now, NNTP servers expects date information to be passed into it in a very specific way - in the format specified in RFC 822. A date string for NNTP needs to look something like this:
08 Apr 2008 12:14:40 -0500
Formatting dates with Objective-C/Cocoa is relatively easy, so I can create a string in this format from an NSDate object relatively easily, by doing this:

NSString *dateString = [theDate descriptionWithCalendarFormat:@"%d %b %Y %H:%M:%S %z" timezone:nil locale:nil];
But where does this code go? Do I really want to put this code everywhere I need to use it? Well, maybe... like I said, this is a simple example for purposes of illustration, and not as compelling as many other real-world examples, but play along with me here, okay?

In an NNTP client, this same long line of code would probably need to be put into dozens or maybe even hundreds of places. But what if RFC822 were to change? Or what if, after using similar code in dozens of places, I realize that I have made a mistake? What a pain!

There are many ways of dealing with this problem in other languages. I could, for example, create a private static method or a function (depending on language)  that takes a date and returns a correctly formatted string. In C or any of its supersets, I could choose to create a preprocessor macro using #define to avoid having the same logic in multiple places. I could also choose to subclass NSDate and add a method in the subclass to return this method. In some cases, that might be appropriate, but in a strongly-typed language like C++ or Java, I probably don't want to do that just to get a single method because it would force a lot of type coercion and messiness into my code.

Without categories, subclassing might be a good choice in Objective-C because it is weakly-typed and could be done with minimal messiness. But we can do it with NO messiness thanks to categories. In Objective-C, I can simply add a method to the existing NSDate class to do what I need. Anywhere I need to use this new method, I just make sure to include the header file from my category. In my simple example, the category header file (.h) would look like this:
#import cocoa/cocoa.h
#import appkit/appkit.h
@interface NSDate(NNTP)

-(NSString *)rfc822DateString;
and my implementation (.m) file would look like this:
#import "NSDate-NNTP.h"

@implementation NSDate(NNTP)
-(NSString *)rfc822DateString
return [self descriptionWithCalendarFormat:@"%d %b %Y %H:%M:%S %z" timeZone:nil locale:nil];
Once I have this, anywhere I need a date formatted in this particular way, I simply call this new method right on the date object, like this:
NSString *dateString = [myDate rfc822DateString];
The result? Very readable and much shorter code, and it places the actual logic into a single place making it easy to maintain. 

If you want to see a more complex use of Objective-C categories, check out this this earlier blog posting where I showed how to add network socket support to the delivered NSFileHandle class.

Categories make it easier to stick with the overriding design philosphy used throughout Cocoa, and its presence allows the Application Kit and UI Kit to have much shallower class hierarchies than you find in other object-oriented application toolkits. If you're working in Cocoa/Objective-C, you really, really should get into the habit of using Categories whenever it makes sense. When does it make sense? Any time you think to yourself, "Gee, I wish the delivered class [X] had a method that does [Y]".

Pink Screen of Death

Looks like the beta of the iPhone OS 2.0 expired today. I don't have this problem yet because I haven't gotten my acceptance letter yet, but for those of you who have, apparently you can just re-download the SDK. Apple hasn't announced it, but apparently the disk image there is updated with a new version of the firmware that is not expired.