1. Home
  2. Resources
  3. Overview of webOS
  4. Overview of webOS - Mojo Application Framework

Overview of webOS - Mojo Application Framework

Mojo Application Framework

A webOS application is similar to a web application based on standard HTML, CSS, and JavaScript, but the application lifecycle is different. Applications are run within the UI System Manager, an application runtime built on standard browser technology, to render the display, assist with events, and handle JavaScript.

The webOS APIs are delivered as a JavaScript framework, called Mojo, which supports common application-level functions, UI widgets, access to built-in applications and their data, and native services. To build full-featured webOS applications, many developers will also leverage HTML5 features such as video/audio tagging and database functions. Although not formally part of the framework, the Prototype JavaScript framework is bundled with Mojo to assist with registering for events and DOM handling among many other great features.

The framework provides a specific structure for applications to follow based on the Model-View-Controller (MVC) architectural pattern. This allows for better separation of business logic, data, and presentation. Following the conventions reduces complexity; each component of an application has a defined format and location that the framework knows how to handle by default.

You will get a more extensive overview of Mojo in Chapter 2, and details on widgets, services and styles starting in Chapter 3. For now, you should know that the framework includes:

  • Application structure, such as controllers, views, models, events, storage, notifications, logging and asserts;
  • UI widgets, including simple single-function widgets, complex multi-function widgets and integrated media viewers;
  • Services, including access to application data and cross-app launching, storage services, location services, cloud services, and accelerometer data;

Anatomy of a webOS Application

Outside of the built-in applications, webOS applications are deployed over the web. They can be found in Palm's App Catalog, an application distribution service, built into all webOS devices and available to all registered developers. The basic lifecycle stages are illustrated in Figure 1-9.

Figure 1-9. Application Stages

Downloading an application to the device initiates installation of the app provided that it has been validly signed. After installation the application will appear in the Launcher. If it is a headless application, then a card is not required and instead the application can utilize just a dashboard and communicate to the user through notifications. Headless applications typically include a simple card based preferences scene to initiate the application and configure its settings. Note that headless applications require at least one visible stage at all times (either a card, dashboard or alert) to not be shut down.

Other applications are launched from the launcher into the foreground and may be switched between foreground and background by the user. Each of these state changes (launch, deactivate, activate, close) is indicated by one or more events. Applications are able to post notifications and optionally maintain a dashboard while in the background.

Applications are updated periodically by the system. If running, the application is closed, the new version installed, and then it's launched. There isn't an update event so the app needs to reconcile changes after installation, including data migration or other compatibility needs.

The user can opt to remove an application and its data from the device. When the user attempts to delete an application, the system will stop the application if needed and remove its components from the device. This includes removing it from the launcher and any local application data, plus any data added to the Palm application databases such as Contacts or Calendar data.

UI Widgets

Supporting webOS's user interface are UI Widgets and a set of standard styles for use with the widgets and within your scenes. Mojo defines default styles for scenes and for each of the widgets. You get the styles simply by declaring and using the widgets, and you can also override the styles either collectively or individually with custom CSS.

The List is the most important widget in the framework. The webOS user experience was designed around a fast and powerful list widget, binding lists to dynamic data sources with instantaneous filtering and embedding objects within lists including other widgets, including other lists, icons and images.

There are Simple Widgets, including buttons, checkboxes, sliders, indicators, and containers. The Text Field widget includes text entry and editing functions, including selection, cut/copy/paste, and text filtering. A Text Field can be used singly or in groups or in conjunction with a List widget.

Menu widgets can be used within specified areas on the screen; at the top and bottoms are the View and Command menus and they are completely under your control. The App Menu is handled by the system, but you can provide functions to service the Help and Preferences items or add custom items to the menu. Each of the various menu types is shown in Figure 1-10.

Figure 1-10. Application Menu Types

For Notifications, you can choose from a Popup Notification or a Banner Notification, both of which post notifications for applications in the notification bar.

Pickers and Viewers are more complex widgets. Pickers are for browsing and filtering files or contacts, or for selecting addresses, dates or times. If you want to play or view content within your application, such as audio, pictures, video or web content, then you would include the appropriate viewer.

Using Widgets

A widget is declared within your HTML as an empty div with an x-mojo-element attribute. For example, the following declares a Toggle Button widget:

x-mojo-element="ToggleButton" id="my-toggle">

The x-mojo-element attribute specifies the widget class used to fill out the div when the HTML is added to the page. The id attribute is required to reference the widget from your Javascript and must be unique.

Typically, you would declare the widget within a scene's view file, then direct Mojo to instantiate the widget during the corresponding scene assistant setup method using the scene controller's setupWidget method:

 / Setup toggle widget and an observer for when it is changed.   // this.toggle     attributes for the toggle widget, specifying the 'value'   //        property to be set to the toggle's boolean value   // this.togglemodel   model for toggle; includes 'value' property, and sets   //     'disabled' to false meaning the toggle is selectable        //   // togglePressed   Event handler for any changes to 'value' property       this.controller.setupWidget('my-toggle',    this.toggle = { property : 'value' },     this.toggleModel = { value : true, disabled : false });       this.controller.listen('my-toggle', Mojo.Event.propertyChange,      this.togglePressed.bindAsEventListener(this));

This code directs the scene controller to setup my-toggle passing a set of attributes, toggle, and a data model, togglemodel, to use when instantiating the widget and to register the togglePressed function for the widget's propertyChange event. The widget will be instantiated whenever this scene is pushed onto the scene stack.

To override the default style for this widget, you would select #my-checkbox in your CSS and apply the desired styling (or use .checkbox to override the styling for all checkboxes in your app). For example, to override the default positioning of the toggle button to the right of its label so that it appears to the left of the label:

#my-toggle   { float:left;          }

There's a lot more to come so you shouldn't expect to be able to use this to start working with any of these widgets at this point. Chapter 3 and 4 describe each of the widgets and styles in complete detail.

Services

Even limiting yourself to just webOS's System UI, application model and UI widgets, developers would have some unique opportunities for building web applications, particularly with the notification and dashboards. But they'd be missing the access and integration that comes with a native OS platform. The Services functions complete the webOS platform, fulfilling its mission to bridge the web and native app worlds.

Through the Services APIs, you can access hardware features on webOS devices (such as location services, the phone, and the camera) and you can leverage the core application data and services that have always been a key part of a Palm OS device. Almost all of the core applications can be launched from within your application, and there are functions to access data in some core applications.

A service is an on-device server for any resource, data, or configuration that is exposed through the framework for use within an application. The service can be performed by the native OS (in the case of device services), an application, or by a server in the cloud. The model is very powerful as evidenced by the initial set of offered services.

The Services differ from the rest of the framework because they are called through a single controller function, serviceRequest. The request passes a JSON object specific to the called service and specifying callbacks for success and failure of the service request.

Starting with Chapter 7, you'll find a full description of the general model and handling techniques as well as enumeration of all the services and the specifics for using each one.