Playlister Case Study

Published June 17th, 2009 by Matt Andersen for Arevit Solutions, Inc.

Overview

This case study uses the example of a radio station playlist to demonstrate the performance benefits that you can experience when you create a custom iPhone application for an existing web service.

Playlister simply displays the last five songs played on Seattle radio station KEXP. If a given song on the playlist is available on Apple's iTunes Music Store, you can tap a button that will let you buy that song on your iPhone.

These screenshots show the list view and song detail view from the Playlister application:

The finished Playlister application is available for free at Apple's iTunes Music Store.

Requirements

First, I'll state the general use case for the app:

When an iPhone is the only handy computer, I want a quick way to identify songs that were recently played on KEXP without a bunch of tapping and pinching at Mobile Safari.

Next I'll list some measurable problems with the status quo that will be solved after I ship the project.

1. App-launch to song info display in 7 seconds over EDGE
   When I averaged three EDGE page-loads of http://www.kexp.org/playlist/playlist.aspx, the result was 109 seconds. Way too long. Even with a full-bars WiFi connection it takes 21 seconds. And after the page loads, I still have to tap, pinch, and drag to zoom the text to a legible size, then line up the playlist data with the iPhone's viewport. So there is room for mobile performance improvement. But why a 7 second target value rather than say 2 seconds? That was the best time I measured for Apple's Weather App to load over EDGE. So that tells me that 7 seconds is a reasonable performance target for an app that relies on similar small nuggets of remote data.
2. Rolling playlist, i.e. last X songs regardless of hour margins
   If I load http://www.kexp.org/playlist/playlist.aspx playlist page at 7:03 AM, the list sometimes includes only the one song that has played since 7:00 AM. As opposed to the last e.g. 5 songs that have played regardless of the hour they were played in. I don't want to deal with any browser navigation to view a prior hour, I just want to see the 5 most recent songs, so the Playlister application should handle that.
3. Direct iTunes Links
   KEXP plays a lot of music that is not available on the iTunes Music Store. But when a song is available on iTunes, I like the instant gratification of an immediate purchase. So I'd like the Playlister application to let me buy songs directly on the iPhone. It would also be nice to know at a glance if a given song is available on the iTunes Music Store (i.e. without leaving the app to search the ITMS). So the application should tell me that it found an iTunes match by showing the album cover art from Apple.

That's it for requirements.

There are lots of cool features that could go into a radio playlist app, but the ones above address my favorite personal use case. And they will provide a nice example of the performance benefits possible with an iPhone App interface to an existing web service.

Now that I have my use case and some measurable feature requirements, it is time to build the Playlister web service.

The Web Service

This page of the Playlister case study describes the "cloud" web service that provides playlist data to the iPhone application.

I built the web service on the symfony PHP framework and deployed it on one of Dreamhost's private server instances.

The web service infrastructure for the Playlister application is what makes the ten-fold improvement in load times possible. It applies two simple approaches:

1. Resource-intensive tasks are off-loaded to the fast server where the web service runs, e.g. determining whether a song is available on the iTunes Music Store, finding album cover art, etc.
2. Only the minimum info needed to tell me what song is playing is sent to the iPhone.

Regarding the first point, here is a diagram that depicts the flow of Playlister data on its way to the iPhone. The Playlister iPhone application would be very slow if it had to make separate requests to KEXP and Apple and then process that data. So the Playlister Web Service takes care of all that, allowing the iPhone application to get all the data it needs in a single, concise, request.

And the next image below is a graphic comparison of the amount of data sent from the Playlister web service versus the full playlist page to illustrate the second point from above. The page load time difference between these examples are small on a desktop or laptop computer, but it makes a huge difference for mobile applications where your audience may be using EDGE for network access. Even when your users have WiFi access, it taxes the limited resources of the iPhone to render complicated markup and Javascript, and that shows in slow page load times.

So I have a web service that is ready to provide quick-to-load nuggets of song data. Time to look at the iPhone application itself.

The iPhone App

This page of the Playlister case study describes the iPhone application itself.

The Playlister Web Service has already taken care of all the resource-intensive work, so the Playlister iPhone application only has to receive the song data and put it on the screen.

Song data arrives at the iPhone in a lightweight format called JSON. All the application has to do is take each piece of song data from that JSON format and stick it into the appropriate iPhone UI element. This low overhead makes the application interface nice and snappy.

There is one part of the song detail view that has the potential to slow things down: the album cover art. A 100px by 100px album cover might weigh 16KB, which will load over EDGE in about 3 seconds. If I had to wait three seconds between tapping a song in the playlist and seeing the details, I would get impatient. But there is a solution for this slowdown. The iPhone SDK allows me to move the album art request to a separate processing thread. This means the song detail will load immediately when I tap a playlist entry, while the iPhone works on loading the album cover in the background. So my user experience stays snappy.

The diagram below shows the simple mapping between JSON data and iPhone UI elements. It also indicates the hyperlinked buttons that take you to destinations outside of the Playlister application.

And that's it!

Now I have a iPhone app that satisfies my general use case and all my specific requirements.

Thanks for reading the case study.