Playgrounds become more flexible and powerful when you add external controls and files. After messing around yesterday with drag and drop, I decided to see if I could come up with a really quick way to prototype an interface for a playground that didn’t involve a lot of work from the playground end.

I’ve added sliders and such before. It works although I haven’t been happy with how ugly the playground-side of the code is. Until now, I’ve added xib files to the playground resources, compiled them by hand, and then established bindings between UI elements and a playground delegate.

I felt there had to be a better solution. Today, I stepped back and completely re-thought the problem. What I ended up with is this:

This playground uses an external user interface built in an entirely separate app. My helper app posts notifications as I interact with its UI components. The playground responds by listening to NSDistributedNotificationCenter.

public let ToyboxNotification = "com.sadun.ToyboxNotification"

To support this design, I created a really simple system that could handle text fields, check boxes, sliders, radio button matrices, and buttons. Throw this code into an application delegate and you’re ready to rock and roll.

The component for success lies in Cocoa’s NSUserInterfaceItemIdentification protocol. By setting identifiers in Xcode’s identity inspector, the playground can determine which component triggered each update.

Identifiers enable multiple sliders to control a sprite’s pitch, yaw, and roll or apply actions across several buttons. Just create a new OS X app based on this delegate code and throw in a few controls. Add identifiers, connect the controls to the app delegate, and start listening from your playground. It really couldn’t be simpler and I’m kicking myself for not thinking of this sooner.