An Idea for iPhone and Mobile: Cross Platform XML Object Binding with JavaScript

In my work developing mobile applications, I have been searching for an idea that would allow me to build applications ONCE and share them on multiple platforms. As a secondary goal, whatever I come up would support a dynamically extensible plugin architecture where additional code and features can be downloaded to the device without redistributing the application through the AppStore or whatever means are provided for other platforms (Android, BlackBerry, etc.).

First Analysis Answers

When I first analyzed this issue, I examined the idea of exclusively utilizing “hybrid” applications that made use of an embedded browser to provide an extensible “runtime” (the JavaScript engine that every browser provides) that did not violate the iPhone license agreement by installing an unapproved runtime (like .NET or some other technology) on the iPhone.

I found two open source frameworks that operated using this technique:

• PhoneGap. This open source library provides support for iPhone, Android, and BlackBerry. The “application” is an HTML page that loads from the resources distributed with an application shell for the target platform, and all development is done in JavaScript. Hooks into an embedded browser allow the interface to communicate with the shell to execute native code operations.
• QuickConnect iPhone. This framework works very similar to PhoneGap. There are really no significant differences other than the approaches to hooking into the aforementioned embedded browser.

What I did and didn’t like

The cool things about these frameworks and the resulting applications were the following:

• Any web developer with JavaScript knowledge could build an application. For Android and iPhone, this was especially cool, since both utilize the WebKit browser.
• The application could indeed be developed once and run on multiple platforms with access to features common across those platforms (camera, media, accelerometer, GPS and location, etc.).
• The JavaScript API’s were very consistent in both frameworks across platforms.

That being said, there were several things I didn’t like about the resulting applications:

• Drawing and application performance was slow(er), because the browser is the only mechanism available for displaying things.
• User interfaces did not seem as responsive as native versions of the same applications.
• Special features of specific devices were unavailable.
• HTML does not give you everything you might need in an application, and there can be some impedance mismatch between the “web” application paradigm and what is needed from a mobile application. Native windows are sometimes just better and necessary.

My grand idea

What I decided I really want in cross platform mobile development are the following:

• No compromise in performance. I want a way to utilize the “hybrid” approach where it makes sense (like for displaying structured content from external sources) but have access to native user interface features and elements provided by the platform directly.
• I want a way to support visual and non-visual plugins through an extensible architecture where code can be introduced from external web sources at runtime without, once again, taking a hit on performance.

The answer, it seems, is composed of two parts:

• Use JavaScriptCore or some other JavaScript engine (like V8, which is what Google’s Chrome browser uses) directly from a native application shell to provide a runtime environment for common code in JavaScript.
• Create an XML schema for describing applications that maps XML elements to native classes in a manner similar to XAML from Microsoft, MXML from Flex, or the Android SDK XML schema. The aforementioned JavaScript engine would be used to allow for programming to be done in the context of the XML document or as a “code-behind” file like in ASP.NET.

Application shells

Native application shells would be written for each supported platform on top of an application library whose purpose is to interpret the contents of an application XML file, hook contained functions into events associated with classes supported by XML elements, and download extensions or other code from whatever external sources are defined, caching modules on the device after some validation process.

Conclusion

This approach achieves my stated objective with the following benefits:

• Less actual code is necessary to build and wire applications. This effect can be observed in WPF and Silverlight applications.
• Hybrid methods can still be used, so designers can still use HTML as the application if they like.
• Performance is greatly enhanced by using the JavaScript engines directly. JavaScriptCore actually compiles to native code. Because execution is not bound to web page processing, the chances that cached native code is used can be assured to be greater.
• JavaScriptCore and V8 can be built for any ARM-based phone platform. A great article describing how it can be used within and outside the context of a web view can be found here.
• Non-visual application functions and services can also be developed efficiently using JavaScript.
• External code can be validated and packaged in more creative ways than with a strict hybrid. Application updates can be done dynamically without redistributing the application.