Palm webOS: Developing Applications in Javascript Using the Palm Mojo Framework – Page 8

Services

Even limiting yourself to just webOS’s System UI, application model and UI widgets, developers would have some unique opportunities for building web applications, particularly with the notification and dashboards. But they’d be missing the access and integration that comes with a native OS platform. The Services functions complete the webOS platform, fulfilling its mission to bridge the web and native app worlds.

Through the Services APIs, you can access hardware features on webOS devices (such as location services, the phone, and the camera) and you can leverage the core application data and services that have always been a key part of a Palm OS device. Almost all of the core applications can be launched from within your application, and there are functions to access data in some core applications.

A service is an on-device server for any resource, data, or configuration that is exposed through the framework for use within an application. The service can be performed by the native OS (in the case of device services), an application, or by a server in the cloud. The model is very powerful as evidenced by the initial set of offered services.

The Services differ from the rest of the framework because they are called through a single controller function, serviceRequest. The request passes a JSON object specific to the called service and specifying callbacks for success and failure of the service request.

Starting with Chapter 7, you’ll find a full description of the general model and handling techniques as well as enumeration of all the services and the specifics for using each one.

Palm webOS Architecture

The Palm webOS is based on the Linux 2.6 kernel, with a combination of open source and Palm components providing user space services, referred to as the Core OS.

You won’t have any direct interaction with the Core OS, nor will the end users. Instead your access is through Mojo and the various services. Users interact with the various applications and the UI System Manager, which is responsible for the System UI. Collectively this is known as the Application Environment. Figure 1-11 shows a simplified view of the webOS architecture.

Figure 1-11. Simplified webOS Architecture

This overview is included as background in case you want to have an idea of how webOS works-this information is not needed to build applications so you can skip it if you aren’t interested.

Application Environment

The application runtime environment is managed by the UI system manager, which also presents the System UI manipulated by the user. The framework provides access to the UI Widgets and the Palm Services. Supporting this environment is the Core OS environment, an embedded Linux OS with some custom sub-systems handling telephony, touch and keyboard input, power management, storage and audio routing. All these Core OS capabilities are managed by the Application Environment and exposed to the end user as System UI and to the developer through Mojo APIs.

Taking a deeper look at the webOS Architecture, Figure 1-12 describes the major components within the Application Environment and the Core OS.

Figure 1-12. webOS System Architecture

The Application Environment refers to the System User Experience and the feature set that is exposed to the application developer, as represented by the Mojo Framework and the Palm Services. The Core OS covers everything else: from the Linux kernel and drivers, up through the OS Services, Middleware, Wireless and Media sub-systems. Let’s take a brief look at how this all works together.

The UI System Manager or UI SysMgr, is responsible for almost everything in the system that is user visible. The application runtime is provided by the Application Manager, which loads the individual applications, and hosts the built-in framework and some special system apps, the status bar and the Launcher. The Application Manager runs in a single process, schedules and manages each of the running applications, and handles all rendering through interfaces to the Graphics sub-system and on-device storage through interfaces to SQLite.

Applications rely on the framework for their UI features set and for services access. The UI features are built into the framework and handled by the Application Manager directly but the service requests are routed over the Palm Bus to the appropriate service handler.

Leave a Reply

You must be logged in to post a comment.