Mobile Information Device Profile

MIDP ( Mobile Information Device Profile ) is a profile of the Java Micro Edition (Java ME), which is specifically designed to meet the abilities of small mobile devices such as mobile phone or PDA. It therefore contains functions for setting and polling of ITU- T one-handed keyboards, miniature screens, volatile and non - volatile memory in the kilobyte range etc.

MIDP applications are called MIDlets.

There are so far the MIDP 1.0 and MIDP 2.0 or 2.1, which has some extensions. MIDP 3.0 is already as JSR 271 under construction.

MIDP is a Sandboxmodell, which ensures great security against computer virus or hacker attacks. The use of network facilities is preceded by a confirmation from the user that they must explicitly permit for each MIDlet in the required connection. Viruses or similar programs are according to Sun Microsystems also not possible because the file system outside the sandbox and it is very limited is accessible.

Hardware Requirements

The specification MIDP 2.0 provides for doubtful accounts for the minimum hardware configuration of a device. Among other things, the device must have a resolution of 96 × 54 pixels, 384 kilobytes of RAM, Internet connection, and a (virtual ) sound output possess. Since MIDP however builds on the CLDC configuration, many hardware requirements are already determined by.

Current status MIDP 2.0

Compared to version 1.0, the currently used version is 2.0 ( with the variant 2.1) significantly more powerful. There are a number of features that make the current functionality of Java ME applications:

  • Playing sound (WAV, MID, MP3)
  • Video streaming (in addition need multimedia API)
  • Game API with sprites, layers, etc.
  • Support for HTTPS, Sockets, Serial Interface
  • Push architecture ( server can activate MIDlets )
  • OTA provisioning (dissemination via wireless )

User interface

MIDP APIs for user interface provides the developer of a minimum set of user interface elements (UI ) to allow interactivity between users and MIDlet. It is located in the package javax.microedition.lcdui. A distinction between the low-and high -level API.

High -level API

The high- level API provides input and output fields, such as text fields (Text Field) or progress indicators ( Gauge), are available. You are the parent class subordinate item. Objects of Item can be placed on a form, but they are limited to position. Forms are objects of class shape. They can be appended to the current display and contain various UI elements. The MIDlet can request changes between forms, as well as during the term add UI elements and respond to user input.

The most important UI elements are:

  • Form: a container for other UI elements.
  • Command: Represents a menu item. Several commands can be summarized in a menu and attached to a form.
  • Alert: Pop - up messages that notify the user about errors, exceptions, warnings or other information.
  • Choice Group: Implements a selection between several entries. The selection of exclusively individual (german single choice) or several entries (English multiple choice) is possible.
  • TextField: Single-line input fields where the user can insert text and can be edited.
  • TextBox: Similar to a TextField, but several lines.
  • Gauge: progress bar.
  • Ticker: display of moving text.

Low -level API

In contrast, the low-level API operates at the pixel level. Canvas class is the entry point for graphic drawing. It itself contains no methods for this purpose, but it provides the callback function paint () methods. You will be called when the program manager decides to draw the new display. Its only parameter is a Graphics object, which all drawing functions, such as drawLine () to draw a line or fillRect () to fill a rectangle contains.

Basically, one can distinguish between pure background applications and those that interact with the user. Interactive applications can access the display via a display object. It is obtained as the return object the static method getDisplay () with the MIDlet as an argument. The method setCurrent () determines which object Displayable to display the contents of a display. Displayable is the parent class of screen and canvas. You are subject to all UI classes. In other words, it defines all the objects that can be shown on the display.

Record Management System (RMS)

MIDP provides special APIs for permanent storage of data that allows the realization of a simple database-driven application programs. The storage of data within the file system is not for reasons of portability in MIDP itself, but specified in JSR 75.

MIDP provides a rather rudimentary alternative is available, the Record Management System (RMS) for persistent storage of data. "Persistent " in this context, to retain the data after multiple reboots of the MIDlet and the mobile device, even after replacing the batteries. The RMS is javax.microedition.rms in the package.

A MIDlet can create as many databases as instances of record store. MIDlets within a suite can access the same databases. MIDlets from different suites are denied access. Even if the database name two such MIDlets is the same, there are two separate databases. Only the MIDP 2.0 specification allows a split database access. An RMS database is located in a platform specific environment. To get the concept of platform independence of Java that implements RMS internally more tailored to the respective system routines, so that outwardly abstract methods are available for database operations.

A record store consists of a collection of byte arrays with an associated unique ID starting with 1 will be the primary key (English primary key) used. IDs of deleted entries are not recycled. When you add a new entry, it gets the next highest ID of the greatest ever occurred arrived ID. A record store can be in four states.

First, a record store on the condition Not Exists with openRecordStore () and a name ( max. 32 characters) as an argument is created. If the database already, the transition from the Closed state. The following condition can open the database with the methods AddRecord () setRecord () and deleteRecord () be modified, with a time stamp (English timestamp) marks the time of last modification and a counter is incremented after each change. With GetRecord () records are read, stating its ID. If multiple threads on a record store, it's the task of the MIDlets to coordinate these requests. close recordstore () closes the database and leads them over to the Closed state. In this state, no access to the database are possible if such an attempt to RecordStoreNotOpenException. deleteRecordStore () deletes the database and the state Emergency Exists is achieved. RecordStore defines the enumerateRecords () method can be filtered or sorted with the help of those records. It returns an object RecordEnumeration that allows a flexible handling of an RMS database. This interface is very similar to the implementation of a classic linked list. It contains methods for dynamically through records and queries whether there is a next or previous item, etc. Other interfaces are record listener and record the filter classes. Record allows the listener intercepting events, such as modifications to the database, so that corresponding reactions can be set. With filter data record can be checked to certain criteria.

Distribute a MIDlet

The distribution of MIDlets, ie the compilation of a program file, then as a Java Archive (JAR). Additionally there is a descriptive text file specifying the Java Archive Descriptor ( JAD ). Many mobile phones now require but no JAD file more, but retrieve the necessary information to the so-called manifesto, a text file included in the JAR with a similar structure and content.

A JAR can contain multiple MIDlets, which are then referred to as midlet suite. Of course, only the compiled. Class files and no source code available from the archive each. Even these are usually not treated with an obfuscator. In addition to the program code the jar often contains the necessary resources such as sounds, graphics etc.

In JAD or Manifest are, inter alia, include information on

  • Name and version of the MIDlet suite
  • Name, icon and program files of the MIDlet
  • Number of bytes in the JAR file ( JAD )
  • Required Java ME profile and configuration required, ie CLDC version

In addition, some manufacturers like Nokia have specified extensions. Also custom entries to the configuration of the application similar to command-line parameters are possible.

571103
de