This morning, after spending some time pondering how I wanted to go about making iTunesCheck better, I decided to look into something I had only previously glanced at: song change notifications. I’m glad I did, too, because it only took about an hour to research, test, and implement. Warning: the majority of you should stop reading now. You will likely be bored to tears by this post. I present it only because I’m so excited about it I can hardly sit still.

Let’s talk about notifications. What are they, and why are they so good? An example is a good place to start, and fortunately I’ve got one handy: Imagine, if you will, that you are trying to write a program that detects when iTunes changes songs. We’ll talk about why you’d want to do this later. How would you go about detecting such a thing?

You could use some AppleScript mojo and a timer to ask iTunes what’s playing, and then compare it to what you thought was playing, and if the two are different, then the song obviously changed. This method is known as “polling”, because you’re polling to figure out if what you’re trying to accomplish should take place. It is easy to see, however, that this is a terribly inefficient method, because you’re eating up processor time by continually asking iTunes for information and by doing comparisons, and memory by keeping the previous track around so that you can compare against it. Let me emphasize that asking iTunes what’s playing is not a cheap task, it is computationally very expensive to perform (which makes it slow). By doing this constantly, you are eating up the user’s processor time and degrading their computer’s performance considerably – which is a terrible, terrible thing for a “background task” like figuring out if iTunes changed tracks to be doing. So instead you compromise: instead of asking all the time, you only ask every so often. Say, every two seconds. That way you give the user most of their processor time back, and you’re much less intrusive. But now you’ve got the problem that you don’t know exactly when the track changed, and so whatever you’re doing upon figuring out that the song is different is delayed, potentially by up to two seconds (or however long your interval is). Maybe this is a big deal or maybe it’s not, but it stands to reason that some people might like to know right away.

So polling sucks: it takes up way too many resources and it’s inaccurate to boot! Let’s consider a different method. If the programmers of iTunes were nice enough to tell you when the song changed, it would make things a lot easier. Instead of always going to iTunes to see what’s playing, and then figuring out if it’s different from what you thought was playing, you could just wait around until iTunes told you that the song changed, and then do whatever it is you wanted to do. Simple! This method is known as “event-driven”, since what you’re trying to accomplish takes place when an event occurs. The main benefit here is that it takes up very few extra resources, since presumably iTunes doesn’t have to do any extra calculations to figure out when the song changes (this is information it probably already knows). The secondary benefit is that it’s much more accurate: you find out right away when the song changes, instead of at your next poll interval. Plus you don’t have to do any strange comparisons to find out which song is playing and whether it’s different from the last one. Enter notifications. Notifications are the implementation of this event-driven method of doing things.

Until now, polling was the method by which iTunesCheck did the “display upon song change” bit. For a long time iTunes wasn’t nice enough to tell you when it changed songs, so the only possible method was polling. During my various wanderings about the web, I became aware that somebody was saying that iTunes was now sending notifications upon song change, but I couldn’t immediately find much information about it. Then, when Tiger came out and I saw the new iChat-iTunes integration, I knew that Apple had started sending out notification from iTunes, because there was no way they were going to have their IM client poll their music player.

A quick bout of Googling led me to a program that can glom onto all system-wide notifications and look at them, and from there it was easy to see what iTunes was sending out and then write two lines of code to start receiving the messages (com.apple.iTunes.playerInfo, if you’re wondering).

What all this means for you, dear reader, is that the next version of iTunesCheck will be lighter, faster, and more accurate. I will also, if you order now, throw in the special gangrene-prevention module, which Stop Gangrene Before It Starts™.

This entry was posted on Monday, May 30th, 2005 at 12:10 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.