NSStringinfying enums from AppCode

I added a --text option to nsstringfromenumgen so it can be used with JetBrains' excellent Objective-C IDE, AppCode. AppCode doesn't integrate with OS X services, but you can configure nsstringfromenumgen as an "External Tool" and provide the selected text as a parameter. There's still an extra copy & paste step not needed with Xcode and Services, but it's not too bad.

Article page

NSStringinfying enums

Making sense of enum values in C is too difficult. Usually sooner rather than later while debugging you need to see what's inside an enum value, but C provides no introspection tools. You just get an integer value, no mapping to the original symbolic name. That's why every enum should be accompanied by a stringifying function, but that requires manual labor. Few programmers are happy to write those functions and fewer are going to update them. Automation to the rescue.

I'm working in the context of Objective-C, and so is Wolf Rentzsch, who recently blogged his script for generating NSStringFromEnumName functions. I have used a very similar solution for a long time, and I expect so have many others.

But you don't have to be jwz to doubt the wisdom of parsing C with a bunch of ad hoc regexps. I was always unhappy with it and knew there were various not-so-corner cases I wasn't handling properly. Using a real C parser seemed like the right thing to do, but it hasn't really been feasible until pretty recently, after the advent of libclang.

So, here it is, using Python and clang, my most recent take on NSStringFromEnum. It might not be any better for being based on libclang, but it's different.

Article page

ZeroMQ, iOS and Python

I wrote some example code for you.

Background: last week a coworker asked me what's the flavor du jour in two-way communication between a network server and an iOS app, should he just go with BSD sockets or is there something better? I suggested he should take a look at ZeroMQ. Not that I actually knew very much at all about it, but I had heard the name and seen that some people were pretty enthustiastic about it.

Turns out he had deadlines and wasn't too keen on building the library with an outdated zsh script that didn't seem to work.

I started fiddling with it myself on the weekend to have some idea about what I'm talking about. True enough that the script provided on the web page wasn't up to date, and once I fixed it I got only an ARM binary which isn't very useful in development when you want to test on the iPhone Simulator. After some more poking I finally managed to massage a working fat library out of it. And objc-zmq provided a nice simple Objective-C wrapper around the C API.

Not satisfied with playing with just one unknown technology, I thought I'd do the server in Clojure. After shaving the JNI yak for a couple of hours, trying to build a working version if the Java binding, I decided it wasn't worth it. Python was an easy fallback, but to keep things at least moderately exciting I used gevent which was also something I hadn't tried before.

It worked out pretty nice. The Python server is extremely simple and the iOS app isn't complex either. This hardly counts as a strenuous test of ZeroMQ, but at least from the code perspective it was really pleasant to work with. No hassle with buffers, just complete messages from an extremely simple API that enables the most common communication patterns with a couple of keywords. They wisely keep out of the marshalling business, telling people to use Protocol Buffers or something else for defining message formats.

The example project is available on Bitbucket. It works on my computer at the moment; see the Bitbucket page for details about the bits it requires.

Enjoy.

Article page

Unit testing Cocoa code with MacRuby

Announcing RCRunner, a GUI test runner for MacRuby and Cocoa.

Cocoa unit testing can be a pain. In addition to the usual difficulties of writing tests for user interface heavy code, the Apple sanctioned solution, SenTestingKit, can isn't the greatest testing framework around and the default way of using it rules out debugger.

GHUnit helps somewhat. It's a GUI test runner with additional testing methods. However, with it you are still writing your tests in Objective-C. On the plus side it's the same language you're probably writing your app in. On the minus side Objective-C can be verbose and sometimes, especially when writing test code, brevity would be welcome.

Enter MacRuby. You get the conciseness of Ruby with full access to your Objective-C classes. And Ruby probably has the greatest density of testing frameworks per active programmer among all the languages in popular use today.

There's a nice article about TDD, Objective-C and MacRuby on the MacRuby site. However, the approach taken in it still uses a Xcode build phase script to accomplish testing. That makes debugging hard and you have to hunt through the build logs for your errors.

RCRunner is a separate GUI program you run. You tell it names of Ruby modules and it uses any test cases it finds[1]. You can breakpoint your code and thanks to Ruby, reload the test code. You can inspect errors and log output test by test.

Enjoy.

[1] At the moment it supports only MiniTest but adding support for other frameworks isn't difficult.

Article page

Using Firefox as Flash playing Safari fallback

If you want to go Flashless on Mac and Safari, it's possible to use Firefox as a fallback, too, not just Chrome. While Firefox does load Plugins from /Library/Internet Plug-Ins and ~/Library/Internet Plug-Ins, it looks in other places too. I just tested and it seems to work fine from ~/Library/Application Support/Firefox/Profiles/<profile name>/plugins and I suspect /Applications/Firefox.app/Contents/MacOS/plugins would work too.

So you can copy Flash Player.plugin, NP-PPC-Dir-Shockwave and flashplayer.xpt to one of the Firefox specific folders and launch Firefox from Safari's Developer menu. Chrome starts up faster, though.

Article page

xibgraph: Interface Builder overviews

When putting together user interfaces with Interface Builder, you connect things together with bindings, actions and outlets and it's good. Understanding the result later on is a completely different matter. It can be time consuming and difficult to browse the objects inside one by one, trying to comprehend the whole. Even more so if you're trying to read someone else's work.

Out of that frustration came xibgraph. It takes a XIB file and outputs the connections contained inside:

Example xibgraph output

At the moment it supports bindings and actions. Outlets are next.

xibgraph supports a couple of different output formats. JSON is supported out of the box and if you install pydot, you get DOT, the format understood by Graphviz and OmniGraffle too.

It hasn't been tested on a particularly wide variety of XIBs, so it's very plausible it will produce wonky results or just outright refuse to work with your files. If so, patches and bug reports are welcome.

xibgraph is MIT licensed and written in Python. It requires PyObjC (it seemed like the easiest way to get XPath support on OS X) and probably Python 2.6. Everything but the DOT support should work without additional requirements on OS X 10.6.

Article page