www.webOShelp.net

Scrollers provide the "finger-flicking" scroll method provided by most touch-screen devices today. One scroller is implemented automatically in every scene and additional scrollers can be added to almost any elements that can be contained within a div tag.

Scrolling modes (in Mojo v1.0):

1. free: allows scrolling along the horizontal and vertical axes.
2. horizontal: allows scrolling only along the horizontal axis.
3. vertical: allows scrolling only along the vertical axis.
4. dominant: allows scrolling along the horizontal or vertical axis, but not both at once.
   The initial direction of the drag determines the scrolling axis for the duration of the drag.
5. horizontal-snap: allows scrolling only along the horizontal axis. Snaps
   to points determined by the position of the block elements found in the model's
   snapElements property array. As the scroller snaps into each point it sends a propertyChange event.
6. vertical-snap: same as horizontal-snap but along the vertical axis.

The widget targets its child element for scrolling. If it has more than one child element, a single div is automatically created to wrap the child elements.

Important: The size of the scroller's target div, the child element, must be set in CSS, otherwise the div will expand to the size of its contents and scrolling will not work.

Scrollers can be nested if the actions required to start scrolling do not conflict. For example, a horizontal scroller can be nested inside the default vertical scroller; any vertical motions will then be captured by the vertical scroller, even if they begin on the horizontal scroller.

Click here for an example of how to set up a scroller.

That does it for the scroller widget. Up next...pickers!

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.

Indicators can be used to show that activity is taking place even if it's not otherwise visible, or as a progress indicator.

Mojo has two types of indicators:

• Activity indicator: animates without showing progress.
• Progress indicator: shows activity and progress

Activity Indicators: Spinner

Spinners are appropriate for applications with limited available space, or when it is difficult to estimate the duration of the activity. They come in two preset sizes: 128x128 and 32x32. The spinner is used in the core applications on every activity button.

Click here for an example of how to set up a spinner.

Progress Indicators

• Progress Pill: a wide pill which is styled to match the View menu and the .palm-header scene style
• Progress Bar: a narrow horizontal bar with a blue progress indicator
• Progress Slider: intended for streaming media playback applications

Progress Pill

Progress pills are styled to match the Mojo button and header styles, and can be used to display the progress of a download or any long-running operation.

The indicator is desitned to show a pill image that corresponds to the model's value property, where 0 is no pill and 1 is a full pill. By updating the widget's model with values between 0 and 1, the pill will display varying stages of progress.

Palm recommens the use of an interval timer to update the progress pill display. At each callback, incase the progress indicator's value property and call the updateModel function.

Click here for an example of how to set up a progress pill.

Progress Bar

A thin horizontal bar indicating progress. Managed the same as the progress pill.

Click here for an example of how to set up a progress bar.

Progress Slider

A slider and progress pill in one handy control; ideal for streaming or progressive download media applications.

The Progress Slider is configured the same way as as Slider widget, but its value model property can be incremented like a Progress Pill, increasing from 0 to 1. Palm has not yet revealed an example of a slider in code; we'll update this article when they do.

That does it for indicators. Stay tuned for the scroller widget!

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.

Menus are a common part of almost every modern application. A webOS application can have standard menus available in every scene or context-sensitive menus that vary between scenes. It can have dropdown menus, floating menus, or button-based menus.

Like simple widgets, menus are instantiated by setupWidget(). Unlike simple widgets, however, menus use the commander chain to propagate menu commands between stage assistants and scene assistants. The commander chain will be covered at the end of the tutorial.

Mojo supports four types of menu widgets: Application Menu, View Menu, Command Menu and Submenu. The first three types are very similar, each using a single model definition with an array containing the menu items. They are instantiated in the usual way by a call to setupWidget(), specifying the menu type, attributes and model. The types include:

• Mojo.Menu.appMenu
• Mojo.Menu.viewMenu
• Mojo.Menu.commandMenu

Selecting an item in a menu generates a command that is processed by a commander registered in the commander chain.

A menu's model is composed a visible property to set the menu to visible or invisible and an items array, which contains menu items and menu item groups. Menu items in groups represent a second level of selectable items. Each item can have a label and and icon (either a custom image or a standard framework icon) and a command value, which is propagated to the command chain when the item is selected. Submenus have many of the same model properties as the other menu types, but is instantiated and managed differently.

Menu widgets are different from standard widgets in that they are not declared in a scene's view file with an x-mojo-element; they are instantiated and handled completely from within the scene assistant. Menus are attached to the scene's window rather than the scene itself, so they always appear above other scene elements and cannot be positioned using HTML or CSS.

Let's take a closer look at the different menu types.

Dialogs are found in most modern applications. They are used to inform the user of errors, provide information, or present the user with important choices. Dialogs in Mojo have some interesting capabilities, such as the ability put almost any functionality into a dialog by building it as a scene.

Dialogs are instantiated using controller functions instead of setupWidget().  showDialog() is used to display custom dialogs, and requires both a template and an assistant—the same as a scene.

There are three basic types of dialogs:

• Error Dialog: Used for presenting error information.
• Alert Dialog: Used for presenting simple options.
• Custom Dialog: A custom dialog requires its own scene with its own assistant and scene view file, which generates overhead both from a development perspective and a device resource perspective. When pushed, the dialog scene becomes a child of the invoking scene.