Help
Palm's webOS offers you a rich set of tools to help you develop visually appealing mobile applications. This excerpt from Palm webOS introduces you to the anatomy of a webOS application and its lifecycle.
Outside of the built-in applications, webOS applications are deployed over the Web. They are located in Palm’s App Catalog, an application distribution service that is built into all webOS devices and is available to all registered developers. The basic lifecycle stages are illustrated in Figure 1.9.
When you download an application to the device, it will be installed, provided it has been validly signed. After installation the application will appear in the Launcher.
Users can launch other applications from the Launcher into the foreground and switch them between the foreground and background. 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.
If it is a dashboard application, a card is not required; the application uses a dashboard and notifications to communicate with the user. Dashboard applications typically include a simple card-based preferences scene to initiate the application and configure its settings. Every application requires at least one visible window at all times (either a card or dashboard).
Applications are updated periodically by the system. If running, the application is closed, then the new version is installed and then launched. There isn’t an update event, so the application needs to reconcile changes after installation, including data migration or other compatibility needs.
The user can 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.
Palm’s user experience architecture provides for a greater degree of application scope than is normally considered in a web application. To support this and specific functions of the framework, Palm has introduced a structure for webOS applications built around stages and scenes.
A stage is similar to a conventional HTML window or browser tab. Applications can have one or more stages, but typically the primary stage will correspond to the application’s card. Other stages might include a dashboard, a pop-up notification, or secondary cards for handling specific activities within the application. Refer to email as an example of a multistage application, where the main card holds the account lists and inbox, and displays the email contents, but new email messages are composed in a separate card to allow for switching between compose and other email activities. Each card is a separate stage but still part of a single application.
Scenes are mutually exclusive views of the application within a stage. Most applications will provide a number of different kinds of scenes within the same stage, but some very simple applications (such as the Calculator) will have just a single scene. An application must have at least one scene, supported by a controller, a Javascript object referred to as a scene assistant, and a scene view, which is a segment of HTML representing the layout of the scene.
Most applications will have multiple scenes. You will need to specifically activate (or push) the current scene into the view and pop a scene when it’s no longer needed. Typically, a new scene is pushed after a user action, such as a tap on a UI widget and an old scene is popped when the user gestures back.
As the terms imply, scenes are managed like a stack with new scenes pushed onto and off of the stack with the last scene on the stack visible in the view. Mojo manages the scene stack, but you will need to direct the action through provided functions and respond to UI events that trigger scene transitions. Mojo has a number of stage controller functions specifically designed to assist you.
Palm webOS applications are required to use directory and file
structure conventions to enable the framework to run the applications
without complex configuration files. At the top level the application must have an appinfo.json
object, providing the framework with the essential information needed
to install and load the application. In addition, all applications
will have an index.html file, an
icon.png for the
application’s Launcher icon, and an app folder, which
provides a directory structure for assistants and views.
By convention, all of an application’s images, other Javascript,
and application-specific CSS should be contained in folders named
images, javascripts, and stylesheets, respectively. This is not
required, but makes it simpler to understand the application’s structure.
Launching a webOS application starts with loading the index.html file and any referenced
stylesheets and Javascript files, as would be done with any web
application or web page. However, the framework intervenes after the
loading operations and invokes the application, stage, and scene
assistants to perform the application’s setup functions and to
activate the first scene. From this point, the application is driven
either by user actions or dynamic data.
Significantly, this organizational model makes it possible for you to build an application that will manage multiple activities that will be in different states (active, monitoring, and background) at the same time.
Applications can range from the simple to the complex:
Single-scene applications, such as a Calculator, which the user can launch, interact with, and then set aside or close.
Dashboard applications, such as traffic alert application that only prompts with notifications when there is a traffic event and whose settings are controlled by its dashboard.
Connected applications like a social networking application, which provides a card for interaction or viewing and a dashboard to provide status.
Complex multistage applications like email, which can have an inbox card, one or more compose cards, and a dashboard showing email status. When all the cards are closed, the email application will run in the background to continue to sync email messages and post notifications as new messages arrive.
Palm webOS supports the standard DOM Level 2 event model. For DOM events, you can use conventional techniques to set up listeners for any of the supported events and assign event handlers in your Javascript code.
There are a number of custom events for UI widgets. For these events, you will need to use custom event functions provided within the framework. Mojo events work within the DOM event model, but include support for listening to and generating custom Mojo event types and are stricter with parameters.
The webOS Services work a bit differently, with registered callbacks instead of DOM-style events. The event-driven model isn’t conventional to web development, but has been part of modern OS application design and derives from that.
Mojo supports the HTML 5 database APIs directly and provides high-level functions to support simple create, read, update, or delete (CRUD) operations on local databases. Through these Cookie and Depot functions, you can use local storage for application preferences or cache data for faster access on application launch or for use when the device is disconnected.
This is the official guide to building native Javascript applications for Palm's new mobile operating system, Palm® webOS™. Written by Palm's software chief technology officer along with the Palm webOS development team, Palm webOS offers you a complete tutorial on the design principles, architecture, UI, tools, and services necessary to develop webOS applications. If you're familiar with HTML, CSS, and Javascript, you're ready to build applications for webOS-based devices, including the Palm Pre.
