Debugging NSNotifications on iOS

For iOS developers, this is a really cool technique.  Sometimes you want to see all the NSNotifications that get posted in your app, whether it is for debugging, or to see the timing of where listeners can be hooked in.  Using breakpoints in Xcode will allow us to inspect the notifications.

Xcode console
Some system notifications (both public and private), and some application notifications being generated at the boot of iTMAC

Follow this procedure to set it up:

  1. In Xcode, open the breakpoints panel on the left sidebar.
  2. Click the + icon at the bottom left of the panel.  Select “Add Symbolic Breakpoint…
  3. Enter the following details:
    Symbol: -[NSNotificationCenterpostNotificationName:object:userInfo:]
  4. Click Add Action and enter the following details:
    Debugger Command: po $r2
    This prints out the 3rd parameter (internally speaking) — the name of the notification.  The first two parameters if you’re curious are the NSNotificationCenter instance, and the command/message.
    Updated June 7, 2015: If you are getting error: use of undeclared identifier '$r2' try using po $arg3 instead.
  5. Select “Automatically continue after evaluating“.

Your breakpoint settings should look like this:
Xcode NSNotification breakpoint settings

You will then need to run the application on a device (sorry, this doesn’t work on the simulator). Note that if your application produces many notifications constantly, the speed of the application will be significantly slower, due to the breakpoints being processed. To work around this, you can disable the breakpoint until you get to the place where you want to analyze the notifications.

App Remote – Unleashing the Apple Remote

I’ve been using Sofa Control for my Apple Remote since I bought my Mac in 2009.  I use Sofa Control pretty much every week when I volunteer with the youth ministry at my church.  The Apple Remote by itself only works with certain programs that are designed to handle its input and it lacked support for other programs we were using such as OpenSong, which we use for song lyrics.  So I bought a license for Sofa Control.

Recently Sofa Control’s move to the App Store required all existing customers to repurchase the license.  I didn’t want to shell out another $20 for this small utility (as great as it has been, a total of $40 for this utility is a little pricy, considering the latest OS X Mountain Lion upgrade only cost $20), so I decided to see if I could program one myself.

I liked the feature that the application-specific handles were scripted.  I also liked how it was small and tucked away as a menu bar extra.  I definitely wanted to keep these features in my own version.

Yesterday (Labour Day, a statutory holiday) was the perfect day to work on this project.  I started off looking for some APIs to hook into the Apple Remote events.  Quite quickly, I found an Apple Remote wrapper written by Martin Kahr, the developer who created Sofa Control.  (Actually I lied; I looked for Apple Remote libraries weeks ago to determine the feasibility of the project, but I did have to find them again yesterday).

Then I looked for an easy scripting language to embed to receive the events generated from the Apple Remote.  I decided to go with AppleScript, the Mac OS built-in scripting language for two reasons.  First, AppleScript already has hooks to script actions in various applications.  Second, Cocoa already has classes to handle execution of AppleScript.

With two-thirds of my application already complete, I only needed to write a small delegate to receive events from the Apple Remote, and call the appropriate AppleScript.

About 200 lines later, I had a working prototype.  Honestly, there isn’t really much to show in terms of screenshots…

The source code and other technical stuff can be found on my GitHub account.  The binary can also be downloaded from Github (beware currently there isn’t much help or instruction with the package).

So with that, I conclude yesterday was a productive Labour Day 🙂