Since it’s not exactly obvious how to narrow down the focus to particular development topic, I wanted to share a bookmark I use to browse recent Mac and iPhone development questions:

Stack Overflow: Mac/iPhone

This works by browsing a combination of tags and has turned out to be a great addition to my list of time killers.

The Apple examples for handling this situation recommend creating two separate views sets: one set for 10.4 and earlier and another set for 10.5 and later. Unless your layout is significantly altered between the two OS versions this has some drawbacks. You now have two sets of views to build and maintain, and if a future version of OS X alters the System Preferences window size again you’re going to need yet another set.

Luckily there is a simple solution. Although System Preferences does not resize the width of our view for us we can do this ourselves quite easily by matching the content width of the System Preferences window.

- (void)mainViewDidLoad {
    NSRect rect = [[self mainView] frame];
    NSWindow *systemPrefsWindow = [[NSApplication sharedApplication] mainWindow];
    rect.size.width = [systemPrefsWindow contentRectForFrameRect:[systemPrefsWindow frame]].size.width;
    [[self mainView] setFrame:rect];
}

We could simplify this code a bit by using the superview’s frame or the contentView of systemPrefsWindow, but contentRectForFrameRect: is used for a couple of reasons. We need to resize the view before it is first displayed, but the superview will not have valid size information until didSelect, at which point our view is already on the screen. In addition, by obtaining the content rect from the window rather than the frame of the contentView we are making no assumptions about the size of whatever contentView currently represents.

This simple change sizes our main view to the width of the System Preferences window, our autoresizing rules are now applied, and viola: a single set of views that scales to a System Preferences window of any width.

When the AirPort Express first came out, I was incredibly excited. Here was a way to put together a whole-house audio system that integrated seamlessly with iTunes, all that was missing was a slick way to control it via Wi-Fi. Of course, I soon discovered that there was in fact no way to control AirTunes through the iTunes API. Ok, no problem, I’ll just file a feature request (rdar://problem/3821346 for any Apple folks). I’m sure they’ll add it soon.

That was nearly four years ago. It’s still not there.

Meanwhile, the requests for AirTunes support kept pouring in, sometimes on a daily basis. Finally I had to relent. So with no support from Apple, and no clever back-door into iTunes available, how can we add support for this feature? Really, there’s only one way: Simulate the user’s input in the iTunes interface. In other words, send mouse clicks exactly at the positions where you would make them to select a speaker through iTunes. This is known as UI scripting and should make every developer who hears those words cringe.

At first glance UI scripting doesn’t seem like such a bad thing. Simulate a click on the speaker selection drop-down, how hard can it be? There’s just one problem. That drop-down? It moves. Try clicking around between different playlists and source types and you’ll see how its position changes. What’s more, in order to send those mouse clicks iTunes has to be the foreground window and there are all kinds of reasons why that might not be the case. Here are just a few of the things that Signal has to account for in order to make those simulated clicks work reliably:

• The user’s language
• The type of playlist selected
• The iTunes window being hidden
• The iTunes window being minimized
• The Mini Player view being selected
• The screen saver being active

And of course, my personal favorite:

• The user’s language not being English, with the radio tuner playlist selected, with iTunes in the Mini Player view, minimized, with the screen saver active, plus some random process that just happens to act up right then and slow everything down.

You have no idea how much cursing was involved in the creation of this feature.

The worst part is that despite all the efforts to make this work as smoothly as possible, it’s still based on a broken model. If Apple decides to update the iTunes interface and move the speaker selection drop-down to a new location it will break. If there is some odd mouse or application behavior that Signal doesn’t account for it will break. And of course, although Signal can send the mouse clicks it can’t get any information back about whether those clicks worked or what speakers are actually turned on.

Sure, Signal could start taking little screenshots of iTunes and try to figure this out from the image. “Well, that kind of looks like ‘Computer’ in Simplified Chinese, I guess we can check the box”. But then I would go insane and then there would be no further product development.

Applications will always have bugs, but a good application tries to be as reliable as possible so that it “just works”. When the limitations of an API prevent your application from doing that, it’s incredibly frustrating. All of which is to say to Apple: Please, please, for the love of shiny plastic, put AirTunes control in the iTunes API.