www.webOShelp.net

The webOS Mojo object Depot provides a simplified interface to the native HTML 5 database API. Palm recommends using Depot instead of the native API if:

• You are storing simple objects for offline data access
• You don't need a schema design
• You don't need to handle transactions or queries.

Depots are currently limited to 5 megabytes of data per object.

Mojo.Depot() opens the depot that matches the name argument or, if there is no match,
creates a new depot with that name. There are three methods:

• simpleGet() calls the provided success method, passing the object retrieved if it
  exists, or failure if no object matches the key.
• simpleAdd() updates the value of the named object.
• removeAll() removes the named depot and deletes the associated data.

Like cookies, you can use the Depot constructor to create a new Depot or open an existing one by providing a unique key to identify the Depot. Depot calls are asynchronous, so you will need to define a callback function to receive the returned data. Depot allows you to store and retrieve data in JSON format, automatically converting between JSON and SQL.

Palm warns that Depot is "not very efficient" and that using it for complex objects "can impact application performance and memory". Complex objects include:

• Deep hierarchy
• Multiple object layers
• Array and object datatypes
• Large strings

Click here for a detailed example of setting up and using a depot.

That concludes our coverage of Mojo's Depot API. Tomorrow we'll revisit the most powerful method of local data storage in webOS: the HTML5 database storage API.

This is one of many daily development-related webOS articles. Grab the RSS feed to stay in the know!

Much of the information in this article was presented in Chapter 6 of Palm webOS by Mitch Allen.

No, these cookies won't increase your Mojo. Unless you define "Mojo" as the ability to effortlessly store small amounts of local data on webOS devices.

The next few articles will take a look at the local storage capabilities of webOS, as well as data transfer from remote servers using Ajax. The first function we're going to look at is cookies (mmm...cookies).

webOS provides a cookie API, a "simplified interface to browser cookies", intended to be used as a "single object store for small amounts of data" such as application preferences, version numbers and other state information. Palm encourages the storage of cached data for offline access as a way to make your applications more flexible.

Mojo cookies are related to browser cookies, but accessible through an object interface to simplify usage by applications.

Access to traditional browser-based cookies is based on the web page's domain. webOS creates a "fake domain" for running applications that is based on the application's ID. This limits access to the cookie to the application itself; the cookie can never be accessed by an external web page or service.

Palm suggests limiting cookies to less than 4 kilobytes, but allows multiple cookies per application if needed. Cookies can be deleted and will automatically be erased if the application that created them is deleted.

Mojo.Model.Cookie(id) opens the cookie that matches the id argument or if there is no match, creates a new cookie with that id. There are three methods:

• get() retrieves the object stored in this cookie if it exists or returns undefined.
• put() updates the values of the object with an optional date/time after which to expire (delete)the object.
• remove() removes the named cookie and deletes the associated data.

The Cookie function and methods are synchronous (that is, you do not have to define a callback function to receive the returned data), but your application will have to wait for the data to be returned before continuing. However; this time should be negligible.

Click here for an example of setting up a cookie.

And that's all you need to know about cookies. Unless you're this guy.

Tomorrow we'll look at Mojo Depot - a simplified interface to the HTML5 Database storage API.

This is one of many daily development-related webOS articles. Grab the RSS feed to stay in the know!

Much of the information in this article was presented in Chapter 6 of Palm webOS by Mitch Allen.

Viewers allow you to embed rich media objects within scenes. The viewer widgets included with Mojo version 1 include webView, imageView, video and audio.  The latter two are based on the HTML5 spec for including video and audio objects in a webpage.

WebView

Displays a "contained web object" (like a web page) in a scene. This can be used to render local markup or an external URL.

Click here for an example of setting up a WebView widget.

ImageView

Similar to WebView, the ImageView widget displays a full-screen image with support for zooming, panning, and "flicking" left and right between additional images.

Audio and Video

These objects are based on HTML5 media extensions. These objects should be used when you want to maintain your application's context or play content directly within your scene.

Audio and Video objects cannot be set up directly through HTML tags in your scene file; they must be set up through JavaScript in the assistant's setup method. You must then set the source and set up event handlers before you can play the media.

The video object requires coordination of the video sink through helper functions freezeVideo and activateVideo. When the application is not in the foreground, it must release the video sink so that the active application can use it to display video, if necessary.

Media objects support both file-based and streaming sources.

And with that, we've completed our tour of Mojo's widgets! Tomorrow we'll start on an entirely new topic, Data, with a look at using cookies for local storage.

This is one of many daily development-related webOS articles. Grab the RSS feed to stay in the know!

Much of the information in this article was presented in Chapter 5 of Palm webOS by Mitch Allen.

A filterList widget is used to provide a list that is navigated with a search field; particularly one in which the list is filter in real-time as the user types characters into the search field. It displays a variable length list of objects that are built by a special callback function. This was the original interaction found on Google's homepage that launched the popularity of Ajax.

The widget is composed of a text field above a list, where the list generated by running the contents of the text field through an application-specific callback function against some off-screen data source.

The text field is hidden until key input is received. On the first keystroke, and every subsequent keystroke, the framework calls the function specified by filterFunction.