Sci-Fi Hi-Fi

The new release of PodWorks isn’t too exciting—even as bug fix releases go—but it was necessary nonetheless. Basically, it introduces a more fundamental solution to the “original” 1.3/2.0 iPod firmware compatibility issue—the one that prevented PodWorks from recognizing and displaying the iPod’s main song list. After 2.1.2 had been out for awhile, it became apparent that my previous (slightly hacky) fix didn’t work for a small subset of new firmware users, so I went back to the drawing board and came up with what I hope is a more solid solution.

For those who care, the bug was actually caused by a change in the way Apple distinguishes the main song list from the playlists in the iPod database. It used to be that the main song list had a type of “1”, while playlists had a type of “0.” Then, when Apple introduced smart playlists, it seemed that the main song list had a type of “1,” normal playlists had a type of “0,” and smart playlists could have any number of values. Now, with iTunes 4 and the new iPod firmware, it appears that the main song list itself can have unpredictable values—sometimes “1”, sometimes “257”, sometimes (and this is what prompted my 2.1.3 update) other things.

Rather than trying to decipher whatever scheme Apple now uses for those list types, I decided to make a fundamental change to my iPod DB parser: it now simply assumes that whichever list it encounters first is the main song list. I’m fairly sure that this is something I can rely on for two reasons:

1. The main song list invariably is ordered first (at least in my experience with parsing iPod database files).
2. The rest of the playlists appear in the database in alphabetical order, which suggests to me that their placement is not simply arbitrary, but rather is important to how they are displayed by the iPod itself.

Even if it turns out I can’t count on the main list being first, the worst case scenario of this solution is a lot better than trying to make sure I cover all the possible values the main song list type could have. At least this way PodWorks is always guaranteed to display all of the song and playlists—even if it makes a mistake as to which one is the main one.

Well, now that I’ve exhausted all of my serious complaints, we’ve come to the nitpicking phase of this little exercise. First in the dock: iSync.

Admittedly, I’m not a heavy user of PDAs, mobile phones, multiple computers, or any of the other devices that iSync is aimed at, so I’m probably not really equipped to comment on how iSync compares to other applications of its ilk. I do use iCal and Address Book regularly, however, and I have an iPod and a .Mac account, so I use iSync fairly frequently. When I do, the dialog pictured below (what Steven Frank has called the “giant scoreboard”) never fails to bewilder me.

I think my main complaint here is that this dialog, while inducing panic with its hazard-themed title bar, actually gives me very little information about what is going to happen to my data. Sure it tells me what general categories of things are going to be changed (calendars, To Do, contacts), how, and by how much, but you’d be surprised how little help this can be when you’re trying to sync two Macs and iSync matter-of-factly declares “Add: 30; Delete: 120; Modify: 1.” Maybe I’m just not that with it, but I usually can’t remember what I’ve changed lately well enough to make a judgement as to whether that is something I want to do or not. Most of the time when I see the scoreboard, I just shrug my shoulders and click “Proceed,” which sort of defeats its effectiveness as a “Safeguard.”

My remedy? Perhaps some context would be in order. If I could take a quick peek at some sort of summary view of which items iSync plans to add, delete, or modify, for example, I would personally feel a lot safer.

Frequent commentators upon this weblog will undoubtedly be thrilled to learn that my comments system now correctly supports cookies, effectively eliminating the need for people to constantly re-enter contact information when posting. It turns out that my comments CGI (Matt Gemmell’s modification (tar.gz, 12 Kb) of the Moveable Type implementation) supported this functionality correctly all along—I was evidently just specifying my cookie domain incorrectly.

Apologies to anyone who experienced weirdness while attempting to post earlier, and thanks to this morning’s surly, anonymous comment poster for bringing this issue to the fore.

Eric Blair posted a link last night to an interesting interview with Joshua Bloch, a major architect of the upcoming Java 1.5 release (a.k.a. Tiger). I must confess that, while I am an avid Java developer and fan, I hadn’t been following what was going on with Tiger. You can imagine my surprise, then, when I read about some of the language level changes Sun is poised to make! A few observations:

• The addition of “generics” is very interesting, especially inasmuch as it flies in the face of the growing enthusiasm (at least in the weblog world) for “dynamically-typed” languages (see recent posts by Robert C. Martin, Tim Bray and James Duncan Davidson, for example). While many seem to be concluding that “test driven development” has rendered traditional compile-time type checking obsolete, Sun seems to be making a bold statement in the opposite direction.
• The “enhanced for” loops are very nice, in that they take the idea of an iterator (or enumerator, as Cocoa calls it) to its logical extreme. This feature will undoubtedly be a huge timesaver.
• It looks to me like Java is about to get a bit more C-like. The new “static import” facility will allow the definition of application-wide constants in a central file in much the same way that C developers can use a header file for the same purpose (something similar to this was possible in previous versions of Java, but could not be accomplished without some ugliness). And, borrowing a frequently requested feature from C, Sun is apparently adding enumerated types to the Java language!

Now my only question about Tiger is how long those of us on OS X (who only recently got 1.4) will have to wait to get our hands on it! Hopefully Apple and Sun are working together closely to guarantee a reasonably timely release…

Unlike .Net (which has ADO) and Java (which has JDBC, JDO, and EJB) or even PHP (which has Pear DB), Cocoa is missing an important component of any modern development framework—a standardized programming interface to databases.

This wasn’t always the case. When NeXT released WebObjects, it included a robust, Objective-C-based data persistence framework known as EOF (Enterprise Objects Framework), which seems to have been fanatically appreciated by all who used it.

For those unfamiliar with the term, a data persistence framework is a tool which attempts to solve an age old programming annoyance: the fundamental mismatch between tables (of the kind contained in databases) and objects (of the kind used in object-oriented programming languages like Java and Objective-C). Essentially, tools like EOF attempt free programmers from the monotonous and unproductive work of writing code that maps information from database tables into objects. Rather than writing huge amounts of tedious SQL code, a programmer using EOF can forget the fact that the database even exists and deal with database tables as if it they are normal objects.

NeXT’s EOF was a major trailblazer in this area, and it almost certainly served as the model for Sun’s successful (though flawed) Enterprise JavaBeans framework. Unfortunately, after Apple acquired NeXT, the decision was made to port WebObjects to Java and drop the Objective-C version of EOF. This means Cocoa developers (at least ones who don’t want to use Cocoa-Java—which includes most that I know) are left without a standard data access API.

In my opinion, Apple made a mistake and demonstrated an uncharacteristic lack of vision when they decided to stop developing EOF for Objective-C. The fact that Cocoa lacks a standardized data access API denies Apple significant opportunities in the enterprise space, and robs Cocoa developers of a major part of NeXT’s innovative heritage.

Most people who have more than a passing acquaintance with Mac OS X are aware that there are two kinds of applications: Cocoa and Carbon. What probably isn’t apparent to people outside of the developer community, however, is that these two APIs are far from equivalent. That is, there are many things that can be done easily in Carbon but not in Cocoa, and vice-versa.

For example, NSFileManager, Cocoa’s object oriented facility for dealing with the file system, is extremely limited compared to the procedural Carbon File Manager API (which has extensive facilities for dealing with HFS metadata, forks, and so forth). Similarly, Apple has yet to provide what I consider to be a decent implementation of promised drags in Cocoa (they introduced the functionality in Jaguar, but it is crippled in that it doesn’t allow dragging of other information along with HFS promises). And, finally, NSMovieView is pretty flaky and lacks the full functionality of the procedural QuickTime APIs. All of these are problems that have made the development of PodWorks, for example, more difficult than it should have been.

To be fair, Apple has been closing the gap with every major OS X release (although most of their effort seems to have been toward bringing Cocoa functionality to Carbon rather than vice-versa). And, in all honesty, it’s often not that difficult to make Carbon calls from Cocoa (it’s usually easier than the other way around). Still, I believe developers should not be forced into workarounds (particularly when they involve calls to burdensome procedural APIs) to accomplish fundamental tasks.

Alright, I think its time Apple just admitted it: trying to base a backup program on WebDAV was a terrible idea. For that matter, doing any large, critical file transfer over WebDAV is a terrible idea. It’s based on HTTP, for crying out loud—it was meant to help people sync their website with a server, not archive their MP3 collection!

I wanted to like .Mac’s Backup application badly, and I think I gave it more than the benefit of the doubt, but in the end it all comes down to one thing: out of all the applications on your hard drive, your backup application is the one that you most need to be reliable. Ironically, during the time I tried to use it, Backup, with its near perfect record of locking up or complaining that I didn’t have a .Mac account in the middle of transfers, was almost certainly the least reliable application I knew of (at least among applications that haven’t been reviewed on PerversionTracker)! All in all, Backup is a conspicuous miss amid Apple’s many software hits (which is all the more galling since, unlike the iLife apps, it wasn’t free!).

The recent discussion about Eclipse on Erik’s, and Michael’s, and Jeff’s and my blog says it all: Project Builder simply does not stand up to comparison with the newest generation of development environments for Java and (dare I say it!) .NET.

I use Eclipse at work, in the development of J2EE applications, and I constantly marvel at how much of the unproductive, monotonous work it takes out of programming. While it’s certainly not without its flaws and occasional annoyances (the fact that there is no installer, for instance, makes upgrades kind of a pain), overall it is one of the most thoughtfully designed software tools I have used.

Project Builder, by contrast, can be a pill. It has:

• No refactoring capabilities (meaning that if I rename a class, I have to manually rename the two files associated with it and change all references to the files and class name in the code).
• No code completion.
• No automatic generation of code to catch exceptions or implement an interface (or, in the context of Objective-C, protocol) or automatically generate accessor methods.
• No visual hints in the editor about syntactic errors before compilation.
• No automatic builds to keep the project constantly up-to-date (unlike Eclipse, where everything is compiled—and errors reported—every time any file is saved).

I’m sure I could add a lot more to this list if I thought about it (Eclipse has so many wonderful little features), but I think I’ve made my point.

The issue here is not about Cocoa or Objective-C, mind you—I adore both, and still think Interface Builder beats the pants off any GUI development tool out there. Nor is the problem that I “hate” Project Builder, per-se. It’s not that bad. I just find it amazing that a design powerhouse like Apple is lagging behind Microsoft, IBM, and the open source community in producing a truly well-designed development environment.

Apple would do well to remember what Ken Arnold pointed out awhile ago: developers are people too, and they need usable software just like everyone else!

In my recent post about Cocoa bugs, I made reference to a flaw in NSMovieView (Cocoa’s object oriented hook into the procedural QuickTime APIs)—more specifically, an issue related to MP3 (and, presumably, AAC) playback. I first encountered this problem, which causes playback to simply stop at arbitrary points in the track, a couple of weeks ago while attempting to add a song preview feature to PodWorks.

Fortunately, my Apple Developer Connection membership came with two Developer Tech Support incidents. At first, the support engineer was convinced I was experiencing a common problem that arises when the window containing an NSMovieView instance is unable to become the main window. After his initial fix failed to solve the problem, and I sent him a project that contained an NSMovieView in the main window and still exhibited the behavior, he sent me the following (not wholly unexpected) reply:

It turns out this is a bug in Jaguar (a timer is not getting rescheduled). The good news is it is fixed in Panther.

Fortunately, this bug has a workaround—albeit one that involves some weird QuickTime juju that I never would have figured out on my own. For this reason, I have decided to post the solution, as given to me by Apple DTS, and hopefully save a fellow Cocoa developer an evening (or several) of frustration. It is downloadable as a Project Builder project:

- MP3Test.dmg (43k)

Use it in good health!

As a typical male, it is a rare occasion indeed when I actually become frustrated enough to ask for help with a problem. This being the case, I have only contacted Apple Developer Tech Support twice, and both times were in reference to problems that simply defied solution. As it turned out, there was a good reason for that: both problems had nothing to do with me, but rather were Cocoa bugs!

The Cocoa frameworks are full of such bugs—completely undocumented and just waiting to snare unsuspecting programmers. From the “sometimes promised drags cause icons to stop highlighting in the drop folder” bug to the “invariably, when playing MP3s, NSMovieView simply decides to stop playback arbitrarily in the middle of the song” bug, they are the sort of thing that drive even the best programmers mad. I pity developers who don’t have DTS to concoct arcane workarounds for them!