Skip to main content

Motivation for the component model

Posted by danila on February 21, 2007 at 1:23 AM PST

The notable feature of mobile devices is diversity in platform
capabilities. This makes doing software for mobile a challenge.

The phoneME Feature software can be viewed as an adaptor between
a set of APIs available on the platform and a set of Java APIs fixed
by the corresponding specifications: CLDC, MIDP, optional JSRs.

This adaptor is positioned as optimized meaning it should
deliver competitive performance for all its features.

How to make it work for the variety of platforms?

In ideal world we would introduce a single unified set of porting
APIs that needs to be implemented for a particular platform and
that's it - you have phoneME Feature software up and running.

Unfortunatelly one set of porting APIs won't fit all. Depending on the OS and available native libraries, some segments of the porting API will appear too high-level or too low-level.

For example, let's consider the UI subsystem. A platform can have a
library of graphics primitives optimized for the particular hardware
and a fully fledged library of UI components.

We will likely choose to reuse these libraries so that Java
applications will have same look&feel as native applications on the
phone and provide comparable graphics performance.

In this case we need to integrate these libraries with phoneME
software and the porting API for that platform would include interfaces to graphics primitives and UI components.

For the other platform that doesn't have native UI components, we will use the UI components implementation included in phoneME Feature
software. In this case we only need to port low-level graphics
primitives.

For yet another platform that doesn't have low-level graphic
primitives and provides only screen buffer, we would use low-level
graphics primitives implementation included in phoneME Feature and
port only the screen buffer access.

The same for all other subsystems and functional areas covered by MIDP and optional JSRs.

The phoneME Feature software should be able to cope with this
multi-level complexity of porting. This drove us to the following
requirements to the architecture:

  • the software should be decoupled into components of reasonable granularity
  • it should be easy to replace each of the components with an alternative implementation

Another important requirement is the ability to port, build and test a single component independently without having to bring up the
whole system.

These are basically the requirements for the phoneME Feature software
architecture and in the next post I will write on how we addressed
them.

Related Topics >>