overview.html

J2ME MIDP2.0 final specification

      view of how the MIDP fits into a device. Note that not all
      devices that implement the MIDP specification will have all the
      elements shown in this figure, nor will every device necessarily
      layer its software as depicted in this figure.</p>
    <p class="Paragraph">
      In the <a href="#ArchFig">High-Level Architecture</a>, the
      lowest-level block (MID) represents the Mobile Information
      Device hardware. On top of this hardware is the native system
      software. This layer includes the operating system and libraries
      used by the device.</p>
    <p class="Paragraph">
      Starting at the next level, from left to right, is the next
      layer of software, the CLDC. This block represents the Virtual
      Machine and associated libraries defined by the CLDC
      specification. This block provides the underlying Java
      functionality upon which higher-level Java APIs may be
      built.</p>
    <a name="ArchFig"></a>
    <h6>High-Level Architecture View</h6>
    <img src="Arch-4.gif" width=362 height=228>

    <p class="Paragraph">
      Two categories of APIs are shown on top of the CLDC:</p>
    <ul>
      <li class="Bullet1">
	MIDP APIs: The set of APIs defined in this specification.</li>
      <li class="Bullet1">
	OEM-specific APIs: Given the broad diversity of devices in the
	MIDP space, it is not possible to fully address all device
	requirements. These classes may be provided by an OEM to
	access certain functionality specific to a given device. These
	applications may not be portable to other MIDs.</li>
    </ul>
    <p class="Paragraph">
      Note that in the figure, the CLDC is shown as the basis of the
      MIDP and device-specific APIs. This does not imply that these APIs
      cannot have native functionality (i.e., methods declared as
      native). Rather, the intent of the figure is to show that any
      native methods on a MID are actually part of the virtual
      machine, which maps the Java-level APIs to the underlying native
      implementation.</p>
    <p class="Paragraph">
      The top-most blocks in <a href="#ArchFig">the figure above</a>
      represent the application types possible on a MID. A short
      description of each application type is shown in the <a
      href="#AppTypes">table</a> below.</p>
    <a name="AppTypes"></a>
    <br><b>MID Application Types</b>
    <table class="Table" border="1" cellpadding="3">
    <tr>
      <th rowspan="1" colspan="1">
	<p class="TableHead">Application Type</p>
      </th>
      <th rowspan="1" colspan="1">
	<p class="TableHead">Description</p>
      </th>
    </tr>
    <tr>
      <td rowspan="1" colspan="1">
	<p class="TableText">MIDP</p>
      </td>
      <td rowspan="1" colspan="1">
	<p class="TableText">
	  A MIDP application, or MIDlet, is one that uses only the
	  APIs defined by the MIDP and CLDC specifications. This type
	  of application is the focus of the MIDP specification and is
	  expected to be the most common type of application on a
	  MID.</p>
      </td>
    </tr>
    <tr>
      <td rowspan="1" colspan="1">
	<p class="TableText">OEM-Specific</p>
      </td>
      <td rowspan="1" colspan="1">
	<p class="TableText">
	  An OEM-specific application depends on classes that are not
	  part of the MIDP specification (i.e., the OEM-specific
	  classes). These applications are not portable across
	  MIDs.</p>
      </td>
    </tr>
    <tr>
      <td rowspan="1" colspan="1">
	<p class="TableText">Native</p>
      </td>
      <td rowspan="1" colspan="1">
	<p class="TableText">
	  A native application is one that is not written in Java and
	  is built on top of the MID's existing, native system
	  software.</p>
      </td>
    </tr>
  </table>
    <p class="Paragraph">
      It is beyond the scope of this specification to address
      OEM-specific or native applications.</p>

    <h3 class="SectionTitle">Device Requirements</h3>
    <p class="Paragraph">
      The requirements listed in this chapter are additional
      requirements above those found in <em>Connected, Limited Device
      Configuration (JSR-30 and JSR-139)</em>, Sun Microsystems, Inc.
    <p class="Paragraph">
      At a high level, the MIDP specification assumes that the MID is
      limited in its processing power, memory, connectivity, and
      display size.
    <h4 class="SectionTitle">Hardware</h4>
    <p class="Paragraph">
      As mentioned before, the main goal of the MIDP is to establish
      an open, third-party application development environment for
      MIDs. To achieve this goal, the MIDPEG has defined a MID to be a
      device that SHOULD have the following minimum characteristics:
    <ul>
      <li class="Bullet1">
	Display:</li>
    <ul>
      <li class="Bullet2">Screen-size: 96x54</li>
      <li class="Bullet2">Display depth: 1-bit</li>
      <li class="Bullet2">Pixel shape (aspect ratio): approximately 1:1</li>
    </ul>
    <li class="Bullet1">Input:</li>
    <ul>
      <li class="Bullet2">
	One or more of the following user-input mechanisms: one-handed
	keyboard, two-handed keyboard, or touch screen</li>
      </ul>
    <li class="Bullet1">Memory:</li>
    <ul>
      <li class="Bullet2">
	256 kilobytes of non-volatile memory for the MIDP
	implementation, beyond what's required for CLDC.</li>
      <li class="Bullet2">
	8 kilobytes of non-volatile memory for application-created
	persistent data</li>
      <li class="Bullet2">
	128 kilobytes of volatile memory for the Java runtime (e.g.,
	the Java heap)</li>
    </ul>
    <li class="Bullet1">Networking:</li>
    <ul>
      <li class="Bullet2">
	Two-way, wireless, possibly intermittent, with limited
	bandwidth</li>
    </ul>
    <li class="Bullet1">Sound:</li>
    <ul>
      <li class="Bullet2">
	The ability to play tones, either via dedicated hardware, or
	via software algorithm.</li>
    </ul>
  </ul>
    <p class="Paragraph">
      Examples of MIDs include, but are not restricted to, cellular
      phones, two-way pagers, and wireless-enabled personal digital
      assistants (PDAs).  
    <h4 class="SectionTitle">Software</h4>
    <p class="Paragraph">
      For devices with the aforementioned hardware characteristics,
      there is still a broad range of possible system software
      capabilities. Unlike the consumer desktop computer model where
      there are large, dominant system software architectures, the MID
      space is characterized by a wide variety of system software. For
      example, some MIDs may have a full-featured operating system
      that supports multi-processing and hierarchical filesystems,
      while other MIDs may have small, thread-based operating systems
      with no notion of a filesystem. Faced with such variety, the
      MIDP makes minimal assumptions about the MID's system
      software. These requirements are as follows:</p>
    <ul>
      <li class="Bullet1">
	A minimal kernel to manage the underlying hardware (i.e.,
	handling of interrupts, exceptions, and minimal
	scheduling). This kernel must provide at least one schedulable
	entity to run the Java Virtual Machine (JVM). The kernel does
	not need to support separate address spaces (or processes) or
	make any guarantees about either real-time scheduling or
	latency behavior.</li>
      <li class="Bullet1">
	A mechanism to read and write from non-volatile memory to
	support the requirements of the Record Management System (RMS)
	APIs for persistent storage.</li>
      <li class="Bullet1">
	Read and write access to the device's wireless networking to
	support the Networking APIs.</li>
      <li class="Bullet1">
	A mechanism to provide a time base for use in time-stamping
	the records written to Persistent Storage and to provide the
	basis for the Timer APIs.</li>
      <li class="Bullet1">
	A minimal capability to write to a bit-mapped graphics
	display.</li>
      <li class="Bullet1">
	A mechanism to capture user input from one (or more) of the
	three input mechanisms previously discussed.</li>
      <li class="Bullet1">
	A mechanism for managing the application life-cycle of the
	device.</li>
    </ul>

    <a name="SpecReqs"></a><h3 class="SectionTitle">Specification Requirements</h3>
    <p class="Paragraph">
      This section lists some explicit requirements of this
      specification. Other requirements can be found in the associated
      Javadoc. If any requirements listed here differ from
      requirements listed elsewhere in the specification, the
      requirements here take precedence and replace the conflicting
      requirements.</p>
    <p class="Paragraph">
      Compliant MIDP 2.0 implementations:</p>
    <ul>
      <li class="Bullet1">
	MUST support MIDP 1.0 and MIDP 2.0 MIDlets and MIDlet Suites.</li>
      <li class="Bullet1">
	MUST include all packages, classes, and interfaces described
	in this specification.</li>
      <li class="Bullet1">
	MUST implement the OTA User Initiated Provisioning specification.</li>
      <li class="Bullet1">
	MAY incorporate zero or more supported protocols for
	push.</li>
      <li class="Bullet1">
	MUST give the user a visual indication of network usage
	generated when using the mechanisms indicated in this
	specification.</li>
      <li class="Bullet1">
	MAY provide support for accessing any available serial ports
	on their devices through the CommConnection interface.</li>
      <li class="Bullet1">
	MUST provide support for accessing HTTP 1.1 servers and
	services either directly, or by using gateway services such as
	provided by WAP or i-mode.</li>
      <li class="Bullet1">
	MUST provide support for secure HTTP connections either
	directly, or by using gateway services such as provided by WAP
	or i-mode.</li>
      <li class="Bullet1">
	SHOULD provide support for datagram connections.</li>
      <li class="Bullet1">
	SHOULD provide support for server socket stream
	connections.</li>
      <li class="Bullet1">
	SHOULD provide support for socket stream connections.</li>
      <li class="Bullet1">
	SHOULD provide support for secure socket stream
	connections.</li>
      <li class="Bullet1">
	MUST support PNG image transparency.</li>
      <li class="Bullet1">
	MAY include support for additional image formats.</li>
      <li class="Bullet1">
	MUST support Tone Generation in the media package.</li>
      <li class="Bullet1">
	MUST support 8-bit, 8 KHz, mono linear PCM wav format IF any
	sampled sound support is provided.</li>
      <li class="Bullet1">
	MAY include support for additional sampled sound formats.</li>
      <li class="Bullet1">
	MUST support <a href="#MIDI-1">Scalable Polyphony MIDI
	(SP-MIDI)</a> and <a href="#MIDI-2">SP-MIDI Device 5-to-24
	Note Profile</a> IF any synthetic sound support is
	provided.</li>
      <li class="Bullet1">
	MAY include support for additional MIDI formats.</li>
      <li class="Bullet1">
	MUST implement the mechanisms needed to support "Untrusted
	MIDlet Suites".</li>
      <li class="Bullet1">
	MUST implement "Trusted MIDlet Suite Security" unless the
	device security policy does not permit or support trusted
	applications.</li>
      <li class="Bullet1">
	MUST implement "Trusted MIDlet Suites Using X.509 PKI" to
	recognize signed MIDlet suites as trusted unless PKI is not
	used by the device for signing applications.</li>
      <li class="Bullet1">
	MUST implement "MIDP x.509 Certificate Profile" for
	certificate handling of HTTPS and SecureConnections.</li>
      <li class="Bullet1">
	MUST enforce the same security requirements for I/O access
	from the Media API as from the Generic Connection framework,
	as specified in the package documentation for
	javax.microedition.io.
      <li class="Bullet1">
	MUST support at least the <a
	href="http://ietf.org/rfc/rfc2279.txt">UTF-8</a> character
	encoding for APIs that allow the application to define
	character encodings.</li>
      <li class="Bullet1">
	MAY support other character encodings.</li>
      <li class="Bullet1">
	SHOULD NOT allow copies to be made of any MIDlet suite unless
	the device implements a copy protection mechanism.</li>
    </ul>

    <h5 class="SectionTitle">References</h5>
    <ol>
      <li class="List1">
	<a name="MIDI-1"></a>
	Scalable Polyphony MIDI Specification Version 1.0, MIDI
	Manufacturers Association, Los Angeles, CA, USA, February 2002.
      </li>
      <li class="List1">
	<a name="MIDI-2"></a> Scalable Polyphony MIDI Device 5-to-24
	Note Profile for 3GPP Version 1.0, RP-35, MIDI Manufacturers
	Association, Los Angeles, CA, USA, February 2002.
      </li>
    </ol>
  </body>
</html>