iPhone Dev Tip #3: Using New Symbols While Preserving Backwards Compatibility

Recently, I was presented with an issue with backwards compatibility: we want to use the new UILocalNotifications API but still preserve compatibility with 3.x devices. I haven't really had a problem doing this with objects that existed in 3.x (check for respondsToSelector:) but I was presented with a new problem: UILocalNotification doesn't exist in 3.x! When you try to run the app, you get something like this:

dyld: Symbol not found: _OBJC_CLASS_$_UILocalNotification
Referenced from: /var/mobile/Applications/3BB86986-88EB-4AF5-9FCF-12C7040889F5/MyApp.app/MyApp
Expected in: /System/Library/Frameworks/UIKit.framework/UIKit
in /var/mobile/Applications/3BB86986-88EB-4AF5-9FCF-12C7040889F5/MyApp.app/MyApp

Not too surprising that it didn't work! So how did I fix it? Basically you have to treat it like an id and instantiate it with a Class queried at runtime:


id localNotif = [[NSClassFromString(@"UILocalNotification") alloc] init];


You cannot use properties (of course) but you can operate on the notification object just like you would normally. Pretty simple solution to a complex linking problem!

Last.FM is back up and running!

With Rhapsody, of course. I decided to finish my Rails implementation of the Rhapsody scrobbler. The problem with the OSX RhapsodyX was always that it was running on multiple computers all the time for me (which caused contention with last.fm) and I never added a DB-backed cache to make sure all files are sent to the server.

So, it's now running on my server as a cron job every 15 minutes and is DB backed! Provided the server doesn't go down it'll be scrobbling everything from playback in the web Rhapsody player to the iPhone version!

Check it out on the right of the main page -- you can follow what I listen to.

iPhone Dev Tip #2: Static Libraries and Categories

So, you've just finished abstracting a bunch of your code but are getting a bunch of 'does not respond to selector exceptions. Of course, you've gotten no warning of these things, the code compiles fine, and you've done the normal stuff (like add -ObjC) to your linker flags.

So what gives? You've done everything right up until this point!

It turns out that apple has a problem with the current build of ldd. Therefore, you must do one of two things: add a small object interface and implementation in the same files as your category (this hints the compiler to look at the implementation) or add the -all_load flag in your linker flags.

Apple has a technote about this here: http://developer.apple.com/mac/library/qa/qa2006/qa1490.html And they also indicate that it's fixed in XCode 4 already so if you want to brave the new (buggy) XCode go for it!

This one took me a few hours to figure out so I hope it helps someone out there!

NSXMLParser, initWithContentsOfURL:, OSX 10.4 and 5 and you

So, API does change between OSX versions.

RhapsodyX has been released for a total of 24 hours, and it turns out that there was a huge Tiger bug -- it didn't even load. Apparently a new message was added to NSMenuItems allowing you to get the view of an item. I was using this to ensure that nothing was updated while the view was visible. If you do, this can cause crashes.

That fix worked -- I hadn't gotten a crash related to that problem since I made the change. Unfortunately, it also turned out that this message doesn't exist in Tiger. Of course since I did a basic usability test on Tiger before release (without connecting) I figured everything was good to go considering I was compiling on a 10.4uSDK (Tiger API). Well, I was wrong.

One thing that I missed is that there was a problem with NSXMLParser's class method initWithContentsOfURL. I believe that the Tiger version of this API does not have the capability to use a web URL to go through the steps of opening up a socket, making a HTTP request, downloading and then parsing, thus giving a fantastic null result. It took a good amount of time to figure out the problem because I was effectively Black Box testing my app since the Tiger machine I was using had no XCode installed. I figured it was a different method of the NSAutoreleasePool possibly releasing things earlier on Tiger than I had expected, but it was the URLs all along.

I moved to another set of APIs that leverage WebKit - thus the 1mb increase in executable size. The program now uses NSURLRequests and NSURLConnection to download the data from Rhapsody's servers. Here's the set I used instead:

NSURLRequest* chRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:url] cachePolicy: NSURLRequestReloadIgnoringCacheData timeoutInterval:10];
NSError* theError;
NSData* response = [NSURLConnection sendSynchronousRequest:chRequest returningResponse:nil error:&theError];

Pretty simple. A few things to note are that this method would also fail provided the program did not get new data every time; this was fixed by the NSURLRequestReloadIgnoringCacheData constant, forcing it to reload every time. Additionally, I changed the timeOut interval just in case so that the program didn't get stuck waiting for a response on a slow server. This minimizes problems, hopefully.

Well, there you have it. Thankfully, it works now. At least on my Tiger test computer... hopefully it also works on yours!

RhapsodyX is 1.0! Well, actually 1.01…

UPDATE 3/28: Fixed a crasher for Tiger users, and problems with URL downloading. Whoops!

Well, the last few things that needed to get done are now done. RhapsodyX is 1.0! The you can download the dmg here:

RhapsodyX 1.01n (DMG, 2.5mb) http://www.elrepositorio.com/rhapsodyx/RhapsodyX_1.01n.dmg

A quick refresher: RX is a program that resides in your menubar that scrubs your "Recently Played Tracks" on Rhapsody.com and submits them to last.fm. Why do we want to do this? Last.fm is a neat social networking service that allows you to meet people with similar tastes to you, and also to get recommendations for new music based on what you listen to. It's pretty neat and since we do most of my listening on Rhapsody we miss out on the social networking fun.

Well, not anymore! With this app (which should be Universal and 10.4/10.5 compatible) you don't have to be left out in the cold A real webpage is forthcoming, but in the meantime this blog post will do.

Also: Friend me on Last.FM! http://www.last.fm/user/MasterJeef/

RhapsodyX – A menu extra for last.fm and Rhapsody.com

Something I'm going to be doing a lot in the next few months is *gasp* programming things that I want to make. I'm finishing up a very simple program that submits songs to http://www.last.fm using the RSS feeds on http://rhapsody.com. It checks the feed periodically (at your setting), and formats the songs for submission to last.fm. There are a few states unhandled by the app, but I'm hoping I can throw it up tomorrow to consumption by the masses.

While simple, it does the job quite well and with enough customizability such that it can be run resident at all times and be stable enough so it won't crash on you all the time. This was a nice exersise for me as it leveraged Cocoa APIs which I hadn't used -- NSStatusItems, NSXMLParser, and NSUserDefaults. I was clued into writing to NSUserDefaults by Nick Pike (http://www.npike.net) which allows you to write to a user preference without actually loading up the plist yourself. Really, really convenient, as a program I wrote awhile back I did the writing directly which is much, much less fun.

Have a screenshot: Update 3/21 - New Screenshot reflects new look