Android JSON Bug

Today I was working on some code that needed to invoke a JavaScript function on a web page that was being displayed in a WebView within an Android application. As part of that function invocation a JSON object is passed in. It's actually a pretty complex JSON object. Of course it must be passed in simply as a string and then parsed by the JavaScript to an object. Android includes the JSON "reference implementation", so naturally I wanted to use this instead of relying on some 3rd party JSON library that would fatten up my APK. The standard way to do this with the reference implementation is to create an instance of org.json.JSONObject and use its toString method. You can create an empty instance and programmatically build up a JSON data structure, or you can give it a Java Map to build from. I chose to go the latter route.
When my web page choked, I wasn't too surprised. I'm never surprised when code I write has bugs initially. I added a log statement to show the data being passed in and was surprised to see that it looked like this:

{"a": "{b={c=d}}", "e":"f"}

This was not correct. This should have looked like this:

{"a": "{"b":"{"c":"d"}"}", "e":"f"}

To create the JSONObject that I was passing in, I passed it in a HashMap whose keys were all strings but whose values were either strings or another HashMap. So to create the above structure there would be code like this:

HashMap<String,Object> top = new HashMap<String,Object>();
HashMap<String,Object> a = new HashMap<String,Object>();
HashMap<String,Object> b = new HashMap<String,Object>();
b.put("c", "d");
a.put("b", b);
a.put("e", "f");
top.put("a",a);

It seemed that the JSONObject code was flattening out my objects and producing incorrect JSON (WTF equal signs!) as a result. I put together a quick workaround to recursively replace any HashMap values with JSONObjects like this:

JSONObject jsonIfy(HashMap<String,Object> map){
	HashMap<String,Object> fixed = new HashMap<String,Object>();
	for (String key : map.keySet()){
		Object value = map.get(key);
		if (value instanceof Map){
			value = jsonIfy((HashMap<String,Object>) value);
		}
		fixed.put(key,value);
	}
	return new JSONObject(fixed);
}

This worked perfectly.

JsonViewer Updated

Some folks pointed out that the JsonViewer installer was complaining about being on the wrong version of AIR. That was because I wrote it before AIR went 1.0. So I thought "no problem, just re-compile it." Well sort of.

I updated Flex Builder 3 to the GA version and updated AIR to 1.0. I imported the old project. It picked up my Subversion settings and what not, very nice. I did a new "export release version" and it worked just fine. I tried to execute the .air file and it bombed. It told me that my AIR file was damaged.

WTF!? I tried to run the app directly from Flex Builder. It did nothing. No errors, just nothing. So I tried debugging. Then I finally got an error message about using the wrong version of AIR. I opened up the JsonView-app.xml. There was no "setting" in here for AIR version, but then I saw this

<application xmlns="http://ns.adobe.com/air/application/1.0.M6">

Yep the .M6 was killing me. I removed it from the XML namespace declaration, and voila! Everything worked perfectly. Show your appreciation for my pain by downloading JsonViewer.

New Version of JsonViewer: Now Open Source!

I updated the JsonView AIR app I wrote a couple of months ago. It has wound up being pretty useful for some of the folks I work with, hence there have been some bug fixes new features requested. I have also had some folks email me about the source code. So as a result of these two things, not only did I update the app, but I released it as open source via Google Code.

So you can get the latest version here, or you can check out the source code for yourself. I was almost embarrassed to show the source because it so trivial!

Web APIs: Flickr vs. GMaps

I was doing a little research on web APIs. Two of the better ones (or at least well known and used) out there are Flickr and Google's Map (GMap.) They present two very different ways to enable third party developers to leverage powerful web services. So I thought I'd do a little compare and contrast.

Flickr's API is a classic procedural library. There are calls for almost any action you could possibly do with all things Flickr : photos, account, tags, sets, etc. You can upload photos, access photo streams, search by tags ... pretty much anything you can do on Flickr's site. Each call is a different HTTP request. You can send the package of your request in a variety of formats: REST, XML-RPC, and SOAP. The REST and SOAP follow the usual patterns for these formats. The REST requests are "pure" HTTP requests. Flickr's XML-RPC is very true to the RPC mode. It uses simple XML to specify a procedure to call along with it's parameters.

You can also specify the format of the response you get back from Flickr. Since they support REST, XML-RPC, and SOAP for requests, it's not surprising they support all these for responses. They recently added JSON and PHP as response formats. I was pleased to see JSON. I can imagine that if I was going to use Flickr's API, I would probably choose to use REST+JSON. Make a pure HTTP request and get back a JavaScript object. Seems like the lean-mean approach to me. I was surprised to see PHP as a response type. In this case, they are referring to serialized PHP objects. The structure of these objects is identical to the JSON structures.

GMaps is different in many ways to Flickr. Instead of supporting procedural calls to Google, everything is object oriented JavaScript. You include a library from Google and then use their objects. Many of their objects provide methods for making calls similar to what you see in Flickr. For example, you can geo-code a location, calculate directions, etc. But you don't make the HTTP request and you don't parse a response. Google's JavaScript objects do these for you.

The differences in these web APIs reflect the differences in these web services. Flickr is more of a pure data service. You can modify data (photos) and query that data (search for photos, etc.) Flickr wants to be your photo database. As such, they give you a number of ways to access your data. What you do with the data is up to you. Show your pics on a website, provide tools for uploading, print the pics, make aprons, whatever...

GMaps wants to draw maps for you. They don't want to give you mapping data for you to do whatever for it. They want to draw. They'll take your data and draw maps with it. They always draw the map, so they give your users a familiar interface that also integrates into Google. All roads lead back to Google.

Thus the APIs to these services are very appropriate for the services. I don't know for sure, but I'd wager they also reflect the programming design behind the services. It seems pretty obvious that Flickr is written in PHP and that Google Maps is written in Java (maybe the last one is less obvious, but I do have a little inside information on that one.) So it's not really surprising that a PHP site would have a very flexible, procedural API, and that a Java site would have more closed, object-oriented API.

JSON vs. XML

I recently was dragged into a JSON vs. XML debate. There are definitely some people out there with strong opinions on this matter. I'm not really one of them. However, most web developers I've worked with like how easy JSON is to work with. That's good enough for me. Plus, some of the typical pro-XML arguments are particularly disturbing to me:

1. XML has strong typing. That's great if you're doing some kind of B2B data/document exchange. Is it really well-suited for the web? Do you want to run a schema-validating XML parser inside a browser? If your server dishes up an XML doc, do you really want your browser to reject it?
2. XML is extensible. Being able to extend a schema and thus add to a document is great, but do you really want data objects that have a lot more information than is needed by your browser? Perhaps you'll want to wait until the net neutrality debate is over before you answer that...
3. XML allows your client and server to use the same data model. Again this sounds great, but there are big problems. First, it implies your server is storing everything (or a lot of things) as XML. You better have some really good reasons for doing this, as either your neglecting the considerable strengths of relational data storage or you're probably misusing it. Second, you're creating a strong coupling between the Models and Views in your system. I know this has become more popular as it is viewed as a tenet of "lightweight" development, but it is a design flaw. That doesn't mean you should never do it, just that it must be weighed against the positives that it would bring. In my experience, even when such tightly coupled systems work well at first, they become a nightmare on versions 1.1+

Again, it's not that I'm against XML on the browser... I'm just wary of some of the arguments for it. I think it is often a wash between the two technologies, which is why I say "so be it" when a web dev tells me they prefer JSON because it makes some of the programming easier.