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.]

Stages and Scenes

• webOS apps provide greater degree of scope than standard web application.
• New app structure: stages and scenes.
• Stage is a declarative HTML structure like a conventional HTML window or browser tab.
• Typically, primary application stage will correspond to application's card.
• Other stages can include dashboard, other cards. Example: Email application with multiple cards (inbox, draft email); each card is a separate stage
• Scenes - sub-view of a stage.
• Apps must provide at least one scene within a stage
• Each scene supported by:
  • a controller: JavaScript object referred to as a scene assistant
  • a scene view: segment of HTML representing the layout of the scene
• Need to specifically activate (push) a current scene into view and pop a scene when no longer needed. Generally push = tap and pop = back (gesture)

Application Lifecycle

• webOS applications required to use directory and file structure conventions to enable framework to run apps without complex config files.
• Application must have:
  • appinfo.json object: provides essential info needed to install and load app.
  • index.html file
  • icon.png:launcher icon
  • app folder: provides directory structure for assistants and views
• If app has images, javascript or app-specific css, they should be in folders named images, javascripts, and stylesheets (not required but recommended for standardization)
• When launched, webOS apps load index.html file and any referenced stylesheets and javascript files.
• Framework then invokes stage and scene assistants to perform app setup functions and activate first scene
• App is then driven by user actions or dynamic data
• Organizational model makes it possible to build an app that manages multiple activities in different states (active, monitoring, background) at same time.
• Examples of apps with varying complexity:
  
  • Single scene apps: e.g. Calculator
  • Headless apps: e.g. traffic alert app that only prompts with notifications
  • Connected apps: e.g. social networking app with card view for interaction and dashboard for status
  • Multi-stage apps: e.g. email: inbox card, compose cards, dashboard with status, headless app that syncs email and posts notifications in background

Events

• webOS supports standard DOM Level 2 event model.
• Use conventional techniques to listen for support DOM events and assign event handlers in HTML or JavaScript
• UI widgets have custom events (covered in chapter 3)
• Need to use custom Mojo event functions
• Events work within DOM but:
  • include support for listening to and generating custom Mojo event types
  • are more strict with parameters - Mojo checks parameters to ensure they are properly defined and typed
• webOS service functions work with registered callbacks instead of DOM-style events (covered in chapter 7)
• Event driven model isn't conventional to web development; derives from modern OS application design

Storage

• Mojo supports HTML5 database functions directly
• Provides high-level functions to support simple CRUD (create, read, update, delete) operations on local databases
• Through these "Mojo Depot" functions, can create local db and add, delete, retrieve records
• Expected to use databases for storage of app preferences or cache data for faster access on application launch or use when device is not connected

UI Widgets

• webOS UI supported by UI Widgets and set of standard styles for use in scenes
• Default styles can be overridden with custom CSS
• List is most important widget in framework
• webOS user experience designed around fast and powerful list widget
• Lists can be bound to dynamic data sources with instant filtering and embedding objects within lists including:
  • other widgets
  • other lists
  • icons
  • images
• Simple widgets include:
  • buttons
  • checkboxes
  • sliders
  • indicators
  • containers
• Text Field widget includes text entry and editing functions including:
  • selection
  • cut/copy/paste
  • text filtering
  • Can be used alone, in groups, in conjunction with a list widget
• Menu widgets can be used in specified areas on the screen
• At top and bottoms are View and Command menus - completely under your control
• App Menu is handled by system, can provide functions to service Help and Preferences items or add custom items
• Notifications widgets include
  • Popup Notification
  • Banner Notification
• Both post notifications for apps in notification bar
• More complex widgets: Pickers and Viewers
• Pickers: browsing and filtering files or contacts, selecting addresses, dates or times
• Viewers: Playing or viewing content in your app including audio, pictures, video or web content

Using Widgets

• Widget declared as empty div with x-mojo-element attribute
• Toggle Button widget example:

<div x-mojo-element="ToggleButton" id="my-toggle"></div>

• x-mojo-element attribute specifies widget class that fills div when HTML is added to page
• id is required to reference widget - must be unique
• Typically, delcare widget within scene's view file, then direct mojo to instantiate widget during corresponding scene assistant setup method using 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));

• code directs scene controller to set up:
  • my-toggle passing a set of attributes
  • toggle
  • toggle model - data model to use when instantiating the widget and registering the togglePressed function for the widget's propertyChange event
• Widget will be instantiated whenever scene is pushed onto the scene stack
• To override default style for widget, use #my-checkbox selector (or .checkbox to override all checkbox styling in your app)
• Example:

#my-toggle {float:left;}

Services

• webOS System UI, application model and UI widgets alone would provide unique opportunities for building web apps
  • such apps would lack access and integration that comes with native OS platform
• Services functions complete webOS platform, "fulfilling its mission to bridge the web and native app worlds"
• Through services APIs, can access webOS hardware features:
  • location services
  • phone
  • camera
  • core app data and services
• Almost all core apps can be launched from within an app
• Service is on-device server for any resource, data or configuration that is exposed through framework for use in an app.
• Service can be performed by native OS, app, or server in the cloud
• "Model is very powerful as evidenced by initial list of offered services"
• Services differ from rest of framework because they are called through single controller function: serviceRequest
• Request passes JSON object specific to claled service and specifies callbacks for success/failure of request
• Full description in chapter 7

Palm webOS Architecture

• Section not required to build webOS apps - included for interest
• webOS based on Linux 2.6 kernel
• Combination of open source and Palm components providing user space services
• referred to as Core OS
• Access through Mojo and various services; no direct interaction with core OS
• Users interact with apps and UI system manager which is responsible for the system UI
• collectively known as Application Environment

Application Environment

• App runtime envrionment managed by UI system manager
• presents system UI manipulated by user
• Framework provides access to UI widgets and Palm servivces
• Environment supported by core OS environment: embedded Linux OS with custom sub-systems handling:
  • telephony
  • touch and keyboard input
  • power management
  • storage
  • audio routing
• All core OS capabilities managed by application environment and exposed:
  • to end user as system UI
  • to developer through Mojo APIs
• App environment refers to System User Experience and feature set exposed to app developer, represented by Mojo Framework and Services
• Core OS covers everything else:
  • Linux kernel and drivers
  • OS services
  • Middleware
  • Wireless subsystem
  • Media subsystem
• UI System Manager (UISysMgr) is responsible for almost everything visible to the user
• App runtime provided by app manager:
  • loads individual apps
  • hosts built-in framework and some special system apps, status bar, launcher
  • runs in a single process
  • schedules and manages each running app
  • handles all rendering through interfaces to Graphics sub-system and on-device storage through interfaces to SQLite
• apps rely on framework for UI features and service access
• UI features built into framework and handled by app manager directly
• service requests routed over Palm Bus to appropriate service handler

Core OS

• Core OS based on version of Linux 2.6 kernel
• standard driver architecture managed by udev with proprietary boot loader
• Supports ext3 filesystem for internal (private) file partitions and fat32 for media file partition
• media file partition can be externally mounted via USB
• Wireless Comms system provides connection management that automatically attaches to WAN and WiFi networks when available
• Switches conneections dynamically, prioritizes Wifi connections when both are available
• EVDO or UTMS telephony and WAN data supported depending on device model.
• webOS supports most standard Bluetooth profiles and provides simple pairing services
• Bluetooth subsystem tightly integrated with audio routing to dynamically handle audio paths based on user perferences and peripheral availability
• Media server based on gstreamer
• includes support for:
  • numerous audio and video codecs
  • file and stream-based playback
  • mainstream image formats
  • image capture through built-in camera
• video and audio capture not supported in initial webOS products but inherently supported by architecture

Software Developer Kit (SDK)

• Includes tools, sample code, Mojo Framework, access to Palm Developer wiki with formal and informal training materials, tutorial and reference documentation
• Registered developers also get direct technical support by email or hosted developer forum

Development Tools

• Palm Developer Tools (PDT) installed from SDK and include targets for:
  
  • Linux
  • Windows (XP/Vista)
  • Mac OS X
• Tools enable you to:
  
  • Create new Palm Project using sample code and framework defaults
  • Search reference documentation
  • Debug your app in webOS emulator or attached Palm device
  • Publish an app
• Tools include:
• SDK bundle installer: Installs all webOS tools & SDK for 3rd party editors
• Emulator: Desktop Emulator and Device Manager
• Command-Line Tools:
  • Create New Project
  • Install & Launch in Desktop Emulator or Device
  • Open Inspector/Debugger Window
  • Package & Sign App
• Tools can be installed as command-line on every platform; include bundles for integration into popular HTML editors and plug-ins for Eclipse and Aptana Studio.
• Refer to Palm Developer Portal for most current list of supported editors and tool bundles

Mojo Framework and Sample Code

• SDK installation includes copy of Framework and sample code
• Don't need to include Mojo framework with app code because framework resident on device
• Framework code included in SDK for reference purposes and debugging
• Sample code includes samples for most significant framework functions including application lifecycle functions, UI widgets, each of the services.

Developer Portal

• Main entry point: developer.palm.com
• Provides:
  • SDK
  • development tools
  • documentation
  • training materials
  • application signing services
  • access to app catalog
    • app store published and promoted with every webOS device