This is a sort of follow-up post to ZeroMQ, iOS and Python from a year ago. I again wrote a test app and server. Of the earlier components, iOS stayed, but ZeroMQ I replaced with WebSockets and the server is this time written in Clojure.

Idea of the exercise is the same as last time: two-way communication between an iOS client and server over a persistent connection. WebSockets is a more mainstream technology than ZeroMQ with a wide variety of servers available, even if it is a young spec and not quite everything has stabilized yet.

On the iOS side there's two options, short of writing the protocol implementation yourself: some kind of horrible Javascript-UIWebView bridge and Square's SocketRocket. I went for SocketRocket. It's available from CocoaPods and at least in this brief test worked fine.

Last time I was planning on doing the server in Clojure but ran out of patience. This time the technology stack was easier. I pretty much followed Jay Fields' example with just a few changes here and there and had a server running in no time.

The system doesn't do anything fancy, or do it particularly beautifully: the app waits for a button tap, sends a number wrapped in JSON to the server, the server increments it and sends it back.

The code is on BitBucket as always. Enjoy.

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.

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.