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.