iGlasses 2 Retrospective
September 8th, 2007 by ken
After a very long development cycle, we released iGlasses 2 on August 27th. The new version has so many exciting new features; my favorite being the ability to digitally pan and zoom your camera (and even cooler, this can be accomplished using the Apple Remote!). Another really nice feature is the precise control over the built-in iSight’s brightness and the ability to lock the iSight’s auto exposure.
Amazingly, we’ve had only a few bug reports and they are very minor problems. With software, major updates are usually followed by a point release udpate in less than 48 hours. (I’m looking at you iTunes.) Not so with iGlasses 2. However, iGlasses 2.0.1 will be coming at some point to fix those minor issues.
Probably the worst bug is that iGlasses 2 causes a crash for 10.3.9 users when they run the Bruji apps (DVDPedia, BookPedia, etc.) We always feel terrible when our plugins cause pain to other developers. We do try to test every situation and we do run a beta progam but somehow we missed this one. The cause of the crash is interesting:
Watch out for duplicate class names
It’s a rare problem, but you can run into duplicate Objective-C class names when the dynamic linker is loading bundles at run-time. It turns out that iGlasses and __Pedia both used the excellent and free AppleRemote library by Martin Kahr. It’s an Obj-C class wrapper around the Apple Remote, which makes it really simple to use a remote in your app. Since neither Bruji nor iGlasses changed the name of the class, the dynamic linker gets an error when trying to load iGlasses.
Now, typically, this won’t cause a crash. The linker will print an error message and then continue, using only one of the two available classes. (This would cause immediate problems if the two classes were actually different internally.) Even though these two classes were probably identical, in this case 10.3.9 doesn’t deal with it so well. This is what we found in the system.log (absolute pathnames and other nonsense removed for readability):
Bookpedia: objc: Both Pediabase and iGlasses have implementations of class AppleRemote.
Bookpedia: objc: Using implementation from iGlasses.
Bookpedia: objc: thread is already initializing this class!
crashdump: Started writing crash report to: Bookpedia.crash.log
Yikes! The lesson? NEVER use simple class names! Always use some unique company or library prefix, even for classes you’re borrowing! 
The easiest thing to do in this case is to just use a macro in your prefix file like this:
#define AppleRemote ECAppleRemote
