Understanding WebOS
From WebOS101
This article provides an explanation towards how webOS works, and what makes it a unique mobile platform.
- Note that this article is quite dated, and makes several references to the Mojo framework specifically, but still has information relevant to webOS in general.
Contents |
Setup
The webOS operating system is a highly customized version of linux. Much of the internals of webOS are covered at webOS internals. Here we're going to keep it simple. SDK applications run in a webkit instance, with Google's V8 javascript engine as the javascript interpreter. Palm has extended the window object with a few custom objects, like window.Mojo. Essentially, we could write applications without Mojo, but we'd have to do a lot more javascript that Palm has already done for us, and we wouldn't have access to some features. For example, Mojo provides custom Palm UI elements that we can use in our applications to provide UI consistency for the user. Palm has also set you up with am instance of Prototype.js to work with inside your application.
So Palm has made it easy, and you've got all the tools of the web available in your application. Everything from local databases, to a simple 2D drawing API and audio and video, Palm has provided it to you. V8 manages memory for you. Making calls to web API's is as simple as making an AJAX request. From there it's a matter of understanding application structure.
A Note About Paradigm
WebOS has a few design paradigms to understand. First: Every Mojo application is also referred to as a stage. Applications have different views, which are referred to as scenes. Scenes form a tree structure, where the parent is whatever initiated the scene (usually, but not always the stage). In the following example, the stage has scenes "main", "about", "howto", and "options".
Stage
->main
->->options
->about
->howto
In this example, notice that main, about and howto are scenes whose parent is the Stage. However, options is a scene whose parent is another scene, main. In webOS applications you can stack scenes and build a scene hierarchy where it makes sense for your application.
When a scene is initialized, we say it is pushed, when it is uninitialized, we say it is popped. If you push one scene inside of another scene, you make that scene a child of the scene it was launched from. We'll get into this a bit more when we discuss it later in this article.
Application Structure
In a basic application (which can be created using the palm-generate command line tool) the file structure is as follows:
/app/
->/assistants/ - The application assistants (js files for each scene)
->/views/ - The application views (html files for each scene)
/images/ - You can place your images here
/stylesheets/ - CSS style sheets are placed here
appinfo.json - Contains application info like the application title
framework_config.json - Some framework configuration settings as a JSON document
icon.png - The application icon
index.html - The base application template, a simple html document
sources.json - contains a list of assistant files the application uses
Inside the /assistants/ directory you have the javascript files related to any scenes that are available, as well as the stage assistant. So let's take an example with scenes "main" and "about". Then the /assistants/ folder would contain three files:
main-assistant.js //The main scene javascript file
about-assistant.js //The about scene javascript file
stage-assistant.js //This is the javascript file for the StageAssistant
Assistant files related to scenes also have corresponding view files. So if in the previous example we have the "main" and "about" scenes, then we also have views corresponding to those assistants in the /views/ directory as follows:
/about/
->about-scene.html //the html file corresponding to the about scene
/main/
->main-scene.html //the html file corresponding to the main scene
Application Launch Cycle
When the application launches, after doing some other fancy stuff, the application initializes the stage-assistant.js file and the index.html file. The first function call whenever any assistant.js file is initialized is the setup method. The stage assistant doesn't contain any UI. As a developer, you will make sure the stage-assistant.js launches the scene that you want to display first. So if the first scene to display was the "main" scene, then your application would launch that scene first from the stage-assistant.js setup method. Here's how you do that, in this example stage-assistant file:
function StageAssistant() {
}
StageAssistant.prototype.setup = function() {
this.controller.pushScene('main'); //this initializes the main-assistant.js and the main scene
};
At the point that your application gets to this set of code, it's a matter of miliseconds (usually) before your application displays. When you call pushScene, the application initializes the main-assistant.js file and the corresponding view file (which is in the /views/ directory). Again, the first function call when the main-assistant.js file initializes is the setup method of the SceneAssistant object. So in this instance, the setup method of the MainAssistant is called first when the scene is initialized.
function MainAssistant() {
}
MainAssistant.prototype.setup = function() {
//This happens first
};
//other methods of the MainAssistant
What we have yet to discuss, are the scene html templates. As mentioned, every scene has a javascript and an html file. Before the setup methods are called, the html from the scene html file is injected into the application's DOM. So one thing to note is that you can reference any html in the respective html file of a scene inside of the assistant's javascript file.
Events in webOS
To handle events in webOS, we register handlers in the setup method of the scene assistant. The downside is that we need to register events to every scene we create, and every DOM element we create. This is the simplest example, and we'll get to more when we get to widgets, but let's say we want to register a Mojo.Event.tap event to the window. So if the user taps anywhere on the screen, it will call a function.
MainAssistant.prototype.setup = function() {
this.handleTap = this.handleTap.bindAsEventListener(this);
this.tapevent = this.controller.listen('window', Mojo.Event.tap, this.handleTap);
};
So in the following code, we register an event, called Mojo.Event.tap, to the window. When the user taps the window object, the handleTap function is called. Let's take a look at the handleTap function:
MainAssistant.prototype.handleTap = function(e) {
console.log("Yay!");
};
When the handleTap function is called, it will print "Yay!" in the console log. This is a brief introduction to events. For a full list of events take a look at Mojo.Event.
Scene Popping and Pushing
I want to go over a more complex example of popping and pushing scenes. In this example, after every push or pop, we'll take a look at the current structure of the application stack. Events are represented by ALL CAPS.
APPLICATION LAUNCH
//Stack:
//Stage
PUSH "main"
//Stack:
//Stage
//->main
POP "main"
//Stack:
//Stage
PUSH "help"
//Stack:
//Stage
//->help
PUSH "about"
//Stack:
//Stage
//->help
//->->about
POP "about"
//Stack:
//Stage
//->help
POP "help"
//Stack:
//Stage
APPLICATION EXIT
Scenes pushed by the Stage are pushed onto the stage as a child. Scenes pushed by a scene are pushed onto the scene as a child.
Handling Application Interruptions
In webOS, applications can be minimized and still run in the background. If you need to stop something in your application when it's minimized and start it again when the application is maximized, webOS gives you two events that you can use to do this. They are the activate and deactivate methods of a scene assistant. So in the scene called "main", the assistant file would have these two functions:
MainAssistant.prototype.active = function() {
//This happens when the application (and the main scene) is maximized again.
};
MainAssistant.prototype.deactivate = function() {
//This occurs when the application is minimized in the main scene.
};
