Blogroll

JSON

I recently had a problem where a web app that worked fine on the iPhone, iPhone Simulator, Safari Mac, Safari Windows, Chrome and the Android Emulator would not work at all on any Android device. After tracking down someone who had an Android phone and was able to debug the app, we discovered:

Console: Uncaught illegal access

in the debugging output that was eventually traced back to a JSON.parse() call that had a null parameter. On all other platforms this returns null, on the Android device it throws an exception. See this bug report for details.

Moral of the story? Always explicitly check your parameter to JSON.parse() for null… and don’t trust the emulator!

As mentioned previously, I’m boning up on Haskell. I prefer to learn by doing, so I’m attempting to build a functioning application as part of the process. I’ve struggled to find much entry level (real application) source code, so I’ll be posting my progress as I go in the hope that it will help others undertaking the same journey. Note the emphasis is on ‘entry level’ — I’m not pretending to be a Haskell guru; if you are one, pointing out what I’m doing wrong would be much appreciated.

This application is a hypothetical REST-based continuous integration status aggregator — CI servers publish build results to the server, then mobile clients view the results. It seemed a little bit more interesting than another blog app tutorial. I’ll be using the popular happstack web application framework, serving JSON over its built-in web server.

First, the setup. Assuming you have a GHC distribution and cabal installed on your computer (on OS X, the Haskell platform binary installer includes these), you’ll need to install happstack and JSON:

cabal update
cabal install happstack
cabal install json

If you get happstack build errors, see my previous post for a possible resolution.

First step is returning some JSON from the server. The following code is a minimal implementation that serialises some hard-coded test data and returns it in response to a web request:

My gut feel, although this is probably the OO developer in me talking, is that automatic generation would be better suited to simple serialisation problems, and explicit serialisation more useful in instances where C#/Java devs would think ‘DTO’ (eg producing a flattened, version-tolerant data contract).

Running the application should result in the following highly enlightening data being served from http://localhost:8000/