Mojo Madness Comments

The last 10 months or so has been a blur of JavaScript code and forum posts as I’ve tinkered on the job and off with Palm’s webOS, as well as their amazing in-browser IDE, Ares. A post or two is sure to follow, here or elsewhere, regarding the Ares experience itself, but I wanted to comment a bit on Palm’s Mojo app framework and the Palm dev and support staff who work the forums, run their Twitter account, fix and improve their library and their toolkit, and generally kick ass.

While nothing is perfect, Mojo has a lot of things going for it: consistency of API let’s users quickly ramp up to speed any time a new widget is added or simply learn more of the large existing set; a deep, thorough set of events for every widget allows you to hook behaviors on widgets at any point in their lifecycles; a growing list of services on the device means you have access to almost all the functionality you see Palm’s own apps exhibiting; and Prototype is quite powerful in its own right.

That last point is as good a place as any to dive in. Prototype is, like MooTools or Base, essentially a class system and set of utility functions. While libraries like jQuery focus solely on DOM, Prototype and its kin exist to facilitate extension of existing classes and the creation of new ones. It’s this presentation of the classical inheritance pattern that allows Prototype to shine. Prototype and similar libraries allow you to inherit from existing classes much more easily than with raw JavaScript.

Palm’s Mojo framework takes distinct advantage of this functionality by building a vast library of classes you can make use of: from the most important widget, list, to buttons, spinners and WebViews, Mojo has a lot of UI elements available for developers to take advantage of when building applications. In addition to the set of widgets available, Mojo presents most of its additional functionality through a unique twist on the MVC paradigm.

The view, of course, is represented in the DOM. Controllers manipulate the DOM as well as manage all the scenes and data management assistance for the closest thing to Ruby on rails is controllers. Assistants have various lifecycle phases such as setup activate, deactivate. You can hook into these phases and fire off whatever functionality you need. For instance, making a request of the GPS service. Once this on-device service has responded, you can make additional requests. For instance hitting a web service and passing in the GPS data as part of the parameters. In Mojo models are represented by the transient in memory objects connected to widgets. A model might contain, for instance, an array of elements which is used to populate the DOM in terms of the list widget. By updating the status of these structures in memory and then calling the modelChanged method widgets will automatically rearrange the DOM as needed.

Ares is an in-browser IDE (think Eclipse or Visual Studio in the browser!) that let’s you drag and drop to design scene layouts, hookup widgets, and assign initial model properties and attributes for these widgets. It also contains a full- fledged debugger (hooking into the emulator via Java applet) with breakpoints and interactive console a la Firebug. These tools are amazing, and sped up the development of Taxi Magic for webOS significantly. There’s even a standalone version of the debugger, which let’s you debug non-Ares projects!

This kind of advanced functionality is what Mojo is all about. I’ll be blogging about Palm, Mojo, the future of webOS (thank you, HP!), and my own experience with Mojo and Ares and related topics more soon.

Post a Comment

Your email is never published nor shared. Required fields are marked *