Tristan O’Tierney | Mac Geek

This post was inspired by a recent twitter that I thought I might elaborate on a bit more. One of the nice new features of Objective-C 2.0 is dot-syntax for read/write proprerties. For example:

Person *person = [[Person alloc] init];
person.mobileNumber = @"1-555-123-1234";

This is uber nifty, and can save you a load of time and redundant code. However it’s often the case that I want to hide access to certain private member variables, but still expose accessors/mutators to attributes on those private variables. Let’s say mobileNumber is actually an accessor/mutator on a sub-object, let’s call it PhoneBook. Under the hood, this is implemented like so:

@interface Person {
    PhoneBook *phoneBook;
}

@property (nonatomic, rertain) NSString *mobileNumber;
@end

@implementation Person
- (void)setMobileNumber:(NSString *)number {
    phoneBook.mobileNumber = number;
}

- (NSString *)mobileNumber {
    return phoneBook.mobileNumber;
}
@end

This seems far from ideal, when really I just want to pass through the implementation of this accessor/mutator to one of my instance variables. A more clean and hypothetical implementation could look like this:

@interface Person {
    PhoneBook *phoneBook;
}

@property (nonatomic, retain) NSString *mobileNumber;
@end

@implementation Person
@synthesize mobileNumber=phoneNumber.mobileNumber;
@end

So I had time tonight to package what I’ve got working, and would like to get some more eyeballs looking at it. Please check it out! Download available at Google Code.

So after going through all the trouble of writing a generic multipart form generator, and screen scraping youtube, etc I’ve completely rewritten it to use the new spiffy YouTube write apis that came out literally a day after I completed all that prior work. Oh well, the good news is this library will be shielded from things like YouTube updating their website since I no longer have to screen scrape. So the downsides are the lib will only handle authentication and uploading, mostly because those are all I need right now. I may let the community fix that problem if anyone else needs that functionality. Look out for a post in the next couple days while I finish up the readme/licensing.

So I know I shouldn’t complain too much, coming from Safari not too long ago, but I felt I must rant about something. In my quest to bring YouTube support to FlickrBooth (is that app name even going to make sense after such a feature?) I’ve come to the sad realization that NSURL sucks. It doesn’t have a feature-rich enough API, making you have to break down to CF functions. It makes you use important to forget string functions like [NSString stringByAddingPercentEscapes] which have fun ways of creating bugs you didn’t anticipate. It lacks any sort of GET/POST automatic query generation. It has no helper functions for cookies, which are this entirely separate-but-shared entity. I feel like Apple ported (or did they write it from scratch?) it on top of WebKit for Panther and basically let it wither without any substantial feature additions since. I suppose on one hand you could argue that it means the API will remain stable, making it easier for future development but Apple does seem to have a hit and run policy of releasing a new awesome library, then basically never touching it again except for bug fixes. WebKit in particular I would not account such harsh words to. The API adapts quite rapidly, despite many additional functions winding up on the “Unofficial but available” headers. But this is by virtue of it’s OpenSource facing policy. AppKit/Foundation doesn’t exactly have the same liberal policy.

I know Wil Shipley talked about this awhile back (hell if I can find the post though) but it bothers me often enough to bring the discussion back up — Why don’t we have more Cocoa libraries for C based stuff in Mac OS X? Everytime some unfortunate functionality requires me to link in some archaic Carbon or C based Mac OS X library I cringe. My first attempt is to check CocoaDev or CocoaBuilder praying that someone’s been annoyed enough by the lack of a Cocoa wrapper for their favorite library to go write one, and maybe the license is something I can use freely. Sometimes I get lucky, sometimes I come up short. What does bother me is I feel like sourceforge, freshmeat, etc just aren’t quite the places to go for this sort of code and I think other mac devs feel the same way. We need something like macosxforge where Cocoa devs can go, without going on a google hunt, to find native cocoa libraries that take the headache out of dealing with this relic of Mac OS 9 style coding. Anyone with me?

People who don’t know a thing about Objective-C are always asking me why I’d want to learn a special language “just for Mac programming” or why I like it more than most other programming languages in general. I think this is a great code snippet that made me stop and say you could NOT do this so elegantly in C++ or many other languages.

NSArray *participants = [archive valueForKey:@"participants"];
NSEnumerator *en = [participants objectEnumerator];
User *user = nil;

while (user = [en nextObject]) {                    
    // do stuff with the user
}

So what’s fascinating about this simple block of code? Let me explain. Lets say archive is a regular NSDictionary object, and participants is an OPTIONAL key/value in this dictionary which could contain an array of Users. How does that affect the rest of our code? Well that means the NSArray participants will be nil. So what happens when you call objectEnumerator on a nil object? An error? Nope! calling a message (any message) on an nil object returns nil. So that means en, our enumerator, becomes nil. Now when we get to our while loop calling nextObject on en will also return nil. Thus the loop terminates gracefully without any error checking code, an no sig-faults from calling our “nil” objects. I’ve just written code that not only performs it’s task but gracefully degrades even under optional conditions.