A What?!

Objective-C has a concept called "Categories" - I just learned about these things a couple of days ago listening to a podcast and wasn't quite sure when or where it would be appropriate to use something like this.

At a high level a "Category" is a way to change (add or modify) the behavior of an existing object. For example - if you needed to print a string backwards in your application; one option would be to subclass the string object. Another option would be to create a category to add a method to perform this operation.

The benefit of a category is that the new method is available to all of the Objects of that type. Another cool benefit is that you don't have to change any code at all to take advantage of the behavior change. All types of the categorized object get the new behavior.

The downside to this? I'm not sure it seems pretty powerful but as they say "with great power comes a great responsibility"

Here is the problem and the solution I solved by using categories:

(IMHO) The Apple API has a bug in the MapKit. If you add a MKPinAnnotationView the CallOut has a (seemingly) random z-index defined which causes the following to happen:

You can see the red pins are on top of the call out window. Very irritating - I was about to give up when I googled one last time and found this posting. Here is how I fixed it by using a category:

Here is the header:

#import <MapKit/MapKit.h>

@interface MKPinAnnotationView (ZIndexFix)
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;
@end

and here is the Implementation:

#import "AEBMapViewCategory.h"

@implementation MKPinAnnotationView (ZIndexFix)
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
[self.superview bringSubviewToFront:self];
[super touchesBegan:touches withEvent:event];
}
@end

So basically I overrode the default behavior of the [touchesBegan: withEvent:] method.

That is all the code I changed to make the picture above look like this:

Pretty sweet huh?

If anyone else solved this problem differently I'd love to hear about it.

-Aaron

Testing and xCode

Java developers are spoiled.

I was a late comer to the testing band wagon. I'm not a test nazi by any stretch but there is a certain amount of confidence that testing gives you.

I miss that when I'm coding in Objective-C.

I was so happy today when I found out today that xCode has built in support for unit testing. But it sucks horribly. Granted much of my problem may be that I have not fully grokked the underpinnings of this environment. But I have spent all day and most of the night trying to figure it out and this is the extent of what I have figured out.

Unit tests that exercise simple parts of the application (non-framework/Cocoa stuff) can be tested after a build is performed. However:

• Debugging is not an option
• Capturing output from sysout is not an option
• Decent reports don't seem to be available
• Decent error reporting doesn't seem to be available

It's hard to believe that unit testing is so far behind on this platform. Java developers don't know how good they have it.