Advanced - Extending EclipseME

Adding a New Wireless Toolkit

EclipseME works in conjunction with the wireless toolkits that are provided by Sun and the different device providers such as Nokia and SonyEricsson. EclipseME provides the ability to be extended by adding new wireless toolkit types to the types already known by EclipseME. Each wireless toolkit type definition provides the necessary EclipseME wrapper to interface EclipseME to the wireless toolkit.

All API's are provided by the eclipseme.core plugin. The model that must be implemented is provided as a set of interfaces in the eclipseme.core.model package. The eclipseme.core.model.impl package provides base implementations for most of the interfaces required within the model. Wireless toolkit implementors may choose to take advantage of these classes or build directly to the model interfaces.

It should be noted that all classes that reside in a package with the word "internal" within the package name are considered implementation that is internal to EclipseME and not meant to be derived from or otherwise called by external plugins. In addition, all classes can be considered interim API which can and will change for the foreseeable future. Developers that use any part of the EclipseME code at this point in time, need to be prepared for breaking changes.

Extending the Wireless Toolkit Type Extension Point

Adding a new wireless toolkit starts by adding a new plugin extension to the Wireless Toolkit Types extension point. Implementing this extension point involves providing an implementation of the IWirelessToolkitType interface. Each wireless toolkit type is responsible for two important functions:

• isThisType
  Returns a boolean indicating whether the specified java.io.File instance is a valid wireless toolkit root that is handled by this toolkit type.
• createToolkit
  Returns a newly created instance of IWirelessToolkit configured to represent the wireless toolkit implemented by this toolkit. Each IWirelessToolkit is responsible for creating one or more IPlatformDefinition instances, each of which represents a separate device "platform".

Implementing the IWirelessToolkit Interface

The IWirelessToolkit implementation is responsible for creating and populating one or more IPlatformDefinition instances, each of which represents a separate device "platform". As these platform definitions are created, the components that make them up must be registered for use within EclipseME.

When implementing a wireless toolkit type, every effort should be made to simplify the operation from the user's perspective. For example, the SonyEricsson toolkit provides versions of both Sun's MIDP 1 toolkit and MIDP 2 toolkit. The wireless toolkit implementation attempts to hide this detail by providing two separate platform definitions.

Implementing the IPlatformDefinition Interface

The IPlatformDefinition implementation is a representation of a device platform, including the following components:

• IConfiguration
  Each platform definition must specify a J2ME configuration.
• IEmulator
  Each platform definition must provide an IEmulator for emulating midlets.
• IPreverifier
  Each platform definition must provide an IPreverifier instance for preverifying classes and libraries.
• IProfile
  Each platform definition must provide one or more IProfile instances that provide the libraries that make up the platform's functionality.
• IWirelessToolkit
  Each platform definition must depends on the wireless toolkit for which it is defined. The platform definition must always provide a reference to its parent toolkit.

In most cases, the standard implementation in PlatformDefinition will suffice for this interface.

Implementing the IConfiguration Interface

The IConfiguration implementation is a representation of a device's J2ME configuration, such as CLDC. A configuration may or may not have an associated jar file providing the API for a particular toolkit. If no library is necessary, the configuration may return null to indicate that fact. In most cases, the standard implementation in Configuration will suffice for this interface.

Implementing the IEmulator Interface

The IEmulator implementation provides the EclipseME core implementation with the information necessary to launch a class within a device emulator. The AbstractEmulator abstract class provides a convenient starting point for implementing a new emulator class. The UEIEmulator provides an implementation of the Universal Emulator Interface that works for many of the emulators that are available.

Implementing the IPreverifier Interface

The IPreverifier implementation is a representation of the support for preverifying CLDC classes. Preverification processing allows part of the bytecode verification processing to be executed on the development machine to save the cost of running that verification on low-power devices.

Implementing the IProfile Interface

The IProfile implementation is a representation of a device's J2ME Profile, such as MIDP 1.0. Each profile consists of one or more libraries that make up the function of that profile. Each library is represented by an Eclipse IClasspathEntry instance which also allows for classpath variable representations to be specified. In most cases, the standard implementation in Profile will suffice for this interface.

Registering Platform Components

In order for EclipseME to correctly interact with the various platform components, each instance that is created must be registered in the Platform Component Registry. Instances of

• IConfiguration
• IPlatformDefinition
• IProfile
• IWirelessToolkit

must all be added to the registry with a unique identifier before they may be used by the rest of the EclipseME functionality. Generally, this registration will be done during the creation of the platform definitions by the wireless toolkit.