www.webOShelp.net

Article Index
Palm webOS by O'Reilly - Chapter 1 Summary - Part 2
Stages and Scenes
UI Widgets
Palm webOS Architecture
All Pages

Slightly delayed but still incredibly useful, here is part 2 of our summary of Palm webOS: Rough Cuts by O'Reilly. (Go here for part 1.)

Mojo application framework

• Apps are run within UI system manager
• UI system manager built on standard browser technology:
  • renders display
  • assists with events
  • handles Javascript
• webOS APIs delivered as Javascript framework called Mojo
• Supports common application-level functions:
  • UI widgets
  • access to built-in apps and data
  • native services
• Can also leverage HTML5 features such as video/audio tagging and database functions
• Prototype JavaScript framework "not formally" part of Mojo framework, but is included to assist with registering for events and DOM handling
• Framework provides structure based on standard MVC architecture.
  • Better separation of business logic, data, and presentation
• Framework includes:
  • Application structure:
    • controllers
    • views
    • models
    • events
    • storage
    • notification
    • logging
    • asserts
  • UI widgets:
    • single and multi-function widgets
    • integrated media viewers
  • Services
    • access to app data
    • cross-app launching
    • storage, location, cloud services
    • accelerometer data

Anatomy/Lifecycle of a webOS Application

• webOS apps are deployed over the web from Palm's App Catalog [or other sources, as Palm has indicated they will not force apps to go through the catalog]
• Downloading initiates installation (provided the app has been validly signed)
• Apps pulled from the catalog either go directly to the dashboard as headless apps, or to the launcher as full apps
• Full apps:
  • launch to the foreground as a card
  • may move to background as other apps are launched
  • can push notifications from background to Dashboard or Notification bar.
• Headless apps can only be interacted with through the Dashboard or Notification bar, and potentially through a simple card-based preferences screen to initiate the app and configure its settings. Headless apps require at least one visible stage at all times (card, dashboard or alert) to avoid being shut down

Application updates

• Apps updated periodically by the system.
• If running, app is closed, new version installed and launched. [This must be an oversimplification; updates will not be forced, especially if a user is interacting with the application being updated.]

Application deletion

• System will stop applicatiion, remove its components including launcher, application data, and data added to the Palm application databases including Contacts and Calendar data. [This too must be an oversimplification, sometimes you will want to retain the data produced by an application, but remove the application itself.]