I read Barbara's (Little Spring Design) piece titled the un-browsers where she describes mFoundry's mojax mobile application framework. I know about mFoundry from before, but wasn't aware of mojax. mojax is their a Mobile “AJAX” application platform, so I went ahead and checked it out.
mojax is very cool, but mojax is not Mobile AJAX; it does have mobile AJAX characteristics. I write this because when terms get overloaded, confusion and noise is introduced… and if you read my blog, you know how picky I'm about that. :-)
mojax is based on their mWorks technology, and uses an XML dialect called MIL to describe the application, that when combined with Java produces code that runs on a runtime at the client/handsets; these clients they call Moblets. They also use CSS and their own flavor of ECMA-262 (ECMA/JavaScript) which is called MILScript. So mojax is an client-side application runtime that uses “their own flavor of XML to describe UI” + “their own XML to describe other application metadata” + “their own flavor of ECMAScript. Calling mojax a Mobile AJAX platform, per the already accepted definition, is a stretch. In the mojax blog, Rodney Aiglstorfer writes Why does mojax qualify as a mobile AJAX application framework, but I have to disagree. Rodney also mentions that mojax is not a browser per-se, which I agree with, but it does have XML rendering (browser)-characteristics, and there is nothing wrong with that.
The technique of using XML combined with Java (into MIDlets) to describe the UI and related controllers we introduced/used at AGEA in the early 2001, giving us the flexibility of dynamic screens definition while leveraging native/local functionality. But
I quickly convinced myself that using the proprietary XML to describe the UI (i.e. re-inventing the wheel) was not the right approach and instead (X)HTML + scripting should be used. Nevertheless the approach worked fine, and allowed us to quickly create fully functional mobile applications. This is when I realized of the potential of the convergence of native + thin clients.
Note that the concept of converging native (such as Java ME) with client-side XHTML rendering (local or web-site) is very powerful; I call these type of mobile clients lightweight clients, which is about the intersection of “native” and local/thin client approaches – very powerful indeed. Imagine being able to run locally on the handset,
occasionally-connected, use (embedded or remote) XHTML and CSS and JavaScript for the user interface, together with Java/MIDP code to access to the native functionality such access to messaging (WMA), multimedia (MMAPI), localstore (RMS, file), the network (HTTP, socket, datagram), cryptographic functions, location, camera, and other APIs. Note that this is the goal of the JSR 290: Java Language & XML User Interface Markup Integration, to integrate Java with W3C's Web Integration Compound Document (WICD) to run on handsets… I can't wait.
So what should mojax do next? mojax should use the standards of the Mobile Web, such as XHTML Basic 1.1, ECMAScript 3rd Edition Compact Profile, CSS 2.1 Mobile Profile, SVG Tiny 1.2 and other – see
W3C WICD Mobile 1.0. And perhaps evolve into small and efficient JSR 290 runtime, and donate the source code, under the Apache license, to the Java ME community :-)
ceo