A few weeks ago, I wrote about listening to iPhone inter-application notifications. Several readers contacted me, through the post comments and through private mail, asking if I could explain how to create the list of notifications that was omitted from the original post. So today, I'm going to walk you through the basics of doing that.

First, let me point out that Apple seems to use reverse domain name notation for its notification scheme. That means that most standard inter-app notifications look something like this: com.apple.notificationname. The "reversed domain" is com.apple rather than apple.com. Knowing that this is Apple's preferred way of sending notifications makes hunting for them much easier.

I created my list for the notificationWatcher application by looking in three standard locations: Core Services, Frameworks and Private Frameworks. As on the Macintosh, the iPhone uses these three folders to store many of the services and libraries that power the platform.

The UNIX strings command lets you search through binary files for text-based elements. To assemble my list, I ran strings over every file I could find and then I searched using grep for that reverse-domain styling, i.e. grep "^com.apple" *.

To automate the process in both frameworks folders, I created shell scripts to iterate through each framework. An easy way to do this is to run the ls command in each folder and then use regular-expression-fu to convert the file names into commands that run strings and grep. To do this, I usually use ed as my preferred line editor of choice. After deleting the current and parent directories in the listing (. and ..) plus the name of the listing itself (usually "doit"), you can then issue some strategic edit commands, such as:

1,$s/.framework//p

1,$s/.*/strings &.framework\/& | grep ^com.apple\/p

These ed commands remove the ".framework" extension from each file name and then replaces each framework name with the appropriate strings command, so CoreFoundation.framework becomes strings CoreFoundation.framework/CoreFoundation | grep ^com.apple.

After doing this edit, you can then make the listing executable and run it as a shell script.

In CoreServices, the only file you really need to worry about is SpringBoard.app/SpringBoard and it's easy enough to run the strings/grep commands on that by hand.

After collecting the results of all these searches, you can clean your results by running them through sort and uniq. This produces a nicely ordered list of notification candidates.

There's little drawback in listening to items that aren't actually notifications along with the real notifications, so don't feel that you have to clean up your list too much.

Be aware that the notifications found this way are (a) not complete; and (b) strictly for application-to-application messaging. Internal notifications, ones that are meant to communicate only within an application are another matter and one that I'll talk about next week.