Get a head start on working with the webOS SDK in this basic introduction to the webOS platform and the Mojo framework. Learn webOS technical terminology and take a look at how applications are put together, with an emphasis on how it relates to a desktop browser environment.
Some key parts of the UI and technical terminology discuss how mojo apps work like pages in a browser All implemented in HTML, CSS, JavaScript Discuss how many of the concepts you’re familiar with in desktop browsers fit into Mojo apps Accessibility One of the most exciting things about the webOS platform App dev model is much more accessible to people than other mobile platforms Mobile platforms like PalmOS or iPhone, you really have to be a C programmer Many more web developers, and on webOS, they can all leverage the skills they’ve developed & tools they’re familiar with. Goals - give you a conceptual head start When you dl the SDK, you’ll be productive more quickly SDK is publicly available now
Applications run in cards, Basis of webOS’s multitasking Native component called SysMgr runs the UI and switches between them Cards are like windows in a desktop browser Implemented entirely on HTML, CSS, JavaScript Each is a small web page -- index.html
Terminology: Scenes Various screens in a card are called scenes Stacked up. List, details, edit, etc… Each scene written separately, but not a different HTML document. they’re all sibling divs in the body.
There are other types: Dashboards for unobtrusive notifications Popup alerts for more immediate interruptions Picture shows the messaging app -- strips at the bottom are dashboard stages. All of these are implemented as separate HTML documents Child windows of the app Mojo provides APIs to create & manage stages. Job of an app is to coordinate and run the scenes in 1 or more stages Let’s see how they do it…
Directory structure, with basic required files Some of these are obvious Icon, images, stylesheets Extras: Miniicon.png framework_config.json Log levels, debug mode, timing, escaping
Title - displayed in the launcher Main - the HTML file to load for the app Id - unique identifier for the application Version - used by app catalog, launcher, must follow the 3 part format Vendor - string identifying the maker of the app, displayed in the launcher. Others: Visible: Hidden in the launcher noWindow: Hidden window noWindow:true in appinfo, main stage is hidden instead of shown as a card. This is needed if you don’t want all your stages closed when the user throws away your main card. Apps must always keep at least one stage open. close your card & display only a dashboard stage open a card again if the app is launched
Index.html, Pretty much what you’d expect Just a web page -- Don’t actually need to load Mojo at all Can just write content, and it goes into the card. Most useful & trivial app is a flashlight Note that I don’t know of any current apps that actually work this way. Story about Rich’s calculator Frequently surprised by how quickly & easily we could get things working
From our framework library app -- Mojo team uses internally Removed doctype & HTML tags Not much left: Script tag to load framework Link tag to load the app’s stylesheet Script tag has x-mojo-version=1… specifies version when we need to make breaking changes, we make a new version Mojo also loads the Prototype framework Empty body When Mojo is loaded, it does everything else: loading & invoking your app code Setting up the first scene Informing SysMgr that the stage is ready for display.
Mojo uses sources.json to load your app code List of JS source files Can load them in script tags, but wasteful if you have multiple stages. We put them in the assistants dir, but they can be kept wherever you like. If you’re optimizing app launch time, you can use the ‘scenes’ property. Specifies that the script is only needed for that scene It will be loaded automatically when the scene is pushed
JavaScript code Apps coordinate stages & run UI in them. They do this mostly by implementing assistant objects Mojo provides generic controllers for various things Apps provide assistants for the controllers that implement all the app-specific behavior AppController/Assistant - Handling launch arguments, creation of stages StageController/Assistant - Scene management. Encapsulation of common scene behavior. SceneController/Assistant- Most app code. Configures widgets, responds to user input, pushes/pops other scenes, etc, Dialogs, Widgets, etc…
app/views Views directory contains the HTML for the app’s scenes. One subdirectory per scene E.g., List, details, edit, options… Scene dirs contain a template for the scene Template is a fragment of HTML Sometimes with property substitutions Basic structure, devoid of dynamic content Declares Mojo widgets Possibly HTML templates for widgets Show you an actual Mojo app, so I added a power switch to the flashlight app
Scene template for the main scene in the Mojo flashlight Main scene is pushed by default Template main-scene.html is loaded Declaration of widget Id & custom property to indicate widget name App specifies other info for the widget in the scene assistant Div for light Takes up rest of screen Can adjust the brackground color
Source file for the main scene assistant Declares the MainAssistant class You can use Prototype’s Class.create() if you prefer. Implements 2 methods Setup() Configures widgets, Implements app-specific behavior switchLight() Event handler for the radio button that turns the light on & off
Three main jobs of a scene assistant’s setup() method: Initialize state in the assistant Set up the scene’s widgets Add event listeners where needed This is an assistant, accesses the scene controller at this.controller. setupWidget() is a SceneController method that tells the framework how to instantiate mojo widgets Attributes control the look & behavior of the widget Model holds the data the widget operates on Note: setupWidget() does not actually instantiate the widget… the framework does that later.
switchLight() is our event handler function. Bind it so when it’s triggered, ‘this’ will be a reference to the assistant object instead of the window Here we store the new function back in the object, which prevents us from accidentally using the unbound function. Listen() is a method available on the SceneController object. Wrapper around addEventListener(), Looks up the element by ID propertyChange events sent when a widget modifies some data Get() is another method available on the SceneController object. Simple wrapper around getElementById(), which looks up the element in the correct document. Espcially important if your application is using multiple stages. Saves the main light div in the assistant object, so we can reference it later
switchLight() is just the handler for the propertyChange event sent by the Mojo RadioButton widget Fetches the new value from the event uses it to set the background color to turn the light on or off. Note that we can reference ‘this.light’, since we bound the function in setup.
This is what it looks like -- Press the on/off button, and the large div toggles between dark blue and light yellow. That’s all there is to creating a basic Mojo app Obviously it can get a lot more complicated, but it’s easy to get things working.
![Meet Mojo™ ,[object Object],[object Object],[object Object],A brief introduction to Palm ® webOS™ applications](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)