| Article Index |
|---|
| Palm webOS by O'Reilly - Chapter 1 Summary - Part 2 |
| Stages and Scenes |
| UI Widgets |
| Palm webOS Architecture |
| All Pages |
Page 2 of 4
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
0 Comments