Android, WebView and AJAX

Android, WebView and AJAX
Posted in Android Development tagged AJAX, android, http, json, SAX, webview, xml at 3:35 pm by tetontech
Thankfully, as of Google’s release of Android 2.0 the XMLHttpRequest object is now included and supported as is the in-browser database and the CSS animations and transitions. Welcome to the party Google. It’s about time.

OK. An update…… The XMLHttpRequest object does exist but it doesn’t work. I ended up implementing my own http handling inside of QuickConnect. Too bad Google. You’re making our work harder.

The statement below still applies to pre 2.0 Android.

There has been some buzz about how to do AJAX from within the WebView component of the Android platform. Unfortunately Google has not included the XMLHttpRequest object in the implementation for reasons they only know. As I have scoured the web on this topic I have found many statements about how a work around ’should’ be able to be done, some statements that simply state that it can not be done, and others saying that Google gears solves the whole problem.

Here is the reality.

Can it be done? Yes. Is Google gears the answer? No. It uses the XMLHttpRequest object.

I have spent a significant amount of time exploring possibilities. The solution requires a call from JavaScript down to the Java layer of the application. Simply stated, the Java code uses the HTTP classes, Connection , Client, etc. to make the request and the result is then passed back up to JavaScript.

The ‘gotchas’ are as follows.

The return value of a call from JavaScript to Java can only return primitives and strings, not objects. Therefore no type of complex dom-like object can be retrieved directly.
The Android API requires that all communication from Java to JavaScript be done in the form of a URL change for the WebView. This means that data must be URL encoded on the Java side and decoded on the JavaScript side.
The URL encoder on the Java side doesn’t match the decoder on the JavaScript side. The spaces in the data are converted to ‘+’ characters which remain ‘+’ characters in the JavaScript decoder. This requires that the implementer of a library replace all instances of the space character with some other sequence on the Java side, I used ‘_SpA_, and then replace all of the placeholder sequences with spaces on the JavaScript side.
The javaScript dom parsing object doesn’t handle XML well. The parsed result of an RSS feed isn’t even close to the XML it is sent.
After spending over a week exploring the possibilities I have come to the following conclusion.

The best way to get AJAX access within Android’s WebView objects is as follows.

Make a call from JavaScript to Java including the URL.
Using the Java-side HTTP objects make the request including any cookies stored on the Java side that may be needed.
After receiving the completed response from the server determine the data type.
If the data is JSON or HTML URL encode it.
If the data is XML send it to Android’s SAX parser.
Send the data to the JavaScript side of the application
If the data is JSON or HTML do this directly
If the data is XML use the SAX events to produce a JSON string that represent the XML node in question and pass the JSON for this node back up to JavaScript
URL decode the data when it gets to the JavaScript side and put any spaces back in the data
Handle the data in JavaScript
If the data is JSON or HTML take any steps appropriate for you application.
If the data is XML assemble a dom-like node structure as each individual JSON string representing a node is received. Once the entire ‘dom’ document is built use it as if it had been obtained using the XMLHttpRequest object.
This approach will work. My tests indicate that this type implementation could mimic the XMLHttpRequest’s functionallity but not necessarily its’ method structure. They also indicate that implementations that use the Java side to make AJAX requests will be too slow. Data sets of any significant size require to much encoding and decoding to be efficient.

I would hate to go through the very large development cycle required to do the implementation described above only to have Google wise up and include the XMLHttpRequest object. At this point in time there are QuickConnectFamily roadmap items that seem much more feasible and demand my time. If AJAX support becomes critical to QCAndroid developers I am willing to do an implementation with the understanding that it may not be usable for significantly sized data sets.

At this point QuickConnectAndroid will not have AJAX support because of the WebView object’s limitations. The hope is that Google will realize it’s mistake and put the XMLHttpRequest object back in the WebKit engine implementation for the WebView Java object. Pressure from the development community on Google may be of help here.