The JSR 190 Event Tracking API
The JSR 190 Event Tracking API contains two major sets of interfaces: the first is the Event Tracking API for application developers, and the second is the protocol between the mobile devices and the mobile operator's backend infrastructure, which connects to the operator's billing system. The high-level architecture is shown in the following diagram:
|Figure 2: This diagram illustrates the high-level architecture of the JSR 190 Event Tracking API.
The Event Tracking API allows applications to access multiple operators without having to understand the underlying interface. It also allows operators to expose a common event-tracking interface without exposing a subset of its own billing interface or creating its own proprietary interface.
It is important to understand that Event Tracking API is designed to expose event-tracking capabilities, not supplement them. Thus, application writers should not expect that using Event Tracking APIs would suddenly transform a billing system incapable of handling event-based billing into a fully featured billing system. Event Tracking APIs addresses only the event-tracking interface. How the underlying systems handle the event is out of the scope of the specification.
Background on MIDlet Programming
For those readers who are not familiar with MIDlet programming, this section provides some background information. The experts can safely proceed to the following section.
A MIDlet is an application written for the Mobile Information Device Profile (MIDP) for J2ME. The Mobile Information Device Profile (MIDP), combined with the Connected Limited Device Configuration (CLDC), is the Java runtime environment for today's mobile information devices (MIDs) such as phones and entry level PDAs. What MIDP provides is the core application functionality required by mobile applicationsincluding the user interface, network connectivity, local data storage, and application lifecycle managementpackaged as a standardized Java runtime environment and set of Java APIs.
A MIDlet must extend the abstract MIDlet class to allow the Application Management Software (AMS) to control the MIDlet lifecycle and state changes. The methods of this class allow the AMS to start, pause and destroy a MIDlet. A MIDlet is a set of classes designed to be run and controlled by the application management software via this interface. A MIDlet must implement the following three abstract methods as defined in the MIDlet class in order for the MIDlet to be functional:
As the names suggest, startApp is called when the MIDlet is entering the active state. pauseApp is called when the MIDlet is about to enter the pause state and destroyApp is called when the MIDlet is about to be destroyed.
The following diagram depicts the states of the MIDlet lifecycle.
A MIDlet programmer is mainly focused on writing code that is executed during the "Active" state and the "Cleanup" code needed for the MIDlet to enter the "Paused" or "Destroyed" states.