MIDP

MIDP ( M obile I nformation D evice P rofile ) was a profile of the Java Micro Edition ( Java ME ), specifically less on the skills mobile devices such as mobile phone or PDA was designed. It therefore included functions for controlling and querying ITU -T one-hand keyboards, miniature screens, volatile and non- volatile memory in the kilobyte range, etc.

MIDP applications are called MIDlets .

MIDP is a sandbox model , which guaranteed high security against computer viruses or hacker attacks . The use of network facilities is preceded by a confirmation from the user, who must explicitly allow it for each MIDlet if a connection is required.

Hardware requirements

The MIDP 2.0 specification sets requirements for the minimum hardware equipment of a device. Among other things, the device must have a display resolution of 96 × 54 pixels, 384 kilobytes of RAM , an Internet connection and (virtual) sound output. However, since MIDP is based on the CLDC configuration, many hardware requirements are already determined by it.

MIDP 2.0

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

Playing sound (WAV, MID, MP3)
Video streaming (additionally requires multimedia API)
Game API with sprites, layers etc.
Support of HTTPS, sockets, serial interface
Push architecture (server can activate MIDlets)
OTA provisioning (distribution via radio network)

MIDP APIs

user interface

MIDP APIs for the user interface provide the developer with a minimal set of user interface elements ( UI ) to enable interactivity between the user and the MIDlet. It is located in the javax.microedition.lcdui package. A distinction is made between the low- and high-level API.

High level API

Low and high level API of the MID profile

The high-level API provides input and output fields such as B. text fields ( TextField) or progress indicators ( Gauge) are available. They are Itemsubordinate to the parent class. Objects from Itemcan be placed on a form, but can only be positioned to a limited extent. Forms are objects of the class Form. They can be Displayappended to the current one and contain various UI elements. The MIDlet can request changes between forms, add UI elements during runtime and react to user input.

The most important UI elements are:

Form: Container for other UI elements.
Command:Represents a menu item. Several commands can be combined in a menu and attached to a form.
Alert: Pop-up messages that notify the user of errors, exceptions , warnings or other information.
ChoiceGroup:Implements a selection option between several entries. The selection of only single (English single choice) or multiple entries (English multiple choice) is possible.
TextField: Single-line input fields in which the user can insert or edit text.
TextBox:Similar to one TextField, but with several lines.
Gauge: Progress indicator.
Ticker: Display of moving text.

Low level API

In contrast, the low-level API works at the pixel level . The class Canvasis the entry point for graphical representations. It itself does not contain any methods for this, but it does provide the callback function paint(). It is called whenever the program manager decides Displayto redraw it. Its only parameter is an object Graphicsthat contains all drawing functions, such as drawLine()drawing a line or fillRect()filling in a rectangle.

Basically, a distinction can be made between pure background applications and those that interact with the user. Interactive applications can access the display via an object Display. It is received as a return object of the static method getDisplay()with the MIDlet as an argument. The method setCurrent()determines which object is to represent Displayablethe content of a display. Displayableis the parent class of Screenand Canvas. All UI classes are subordinate to it. In other words, it defines all objects that can be shown on the display.

Record Management System (RMS)

RMS structure

MIDP provides special APIs for the permanent storage of data that allow the implementation of simple database-supported application programs . For reasons of portability, the storage of data within the file system is not contained in MIDP itself, but is specified in JSR 75.

MIDP provides a rather rudimentary alternative for the persistent storage of data, the Record Management System (RMS). "Persistent" means that the data is retained after restarting the MIDlet and the mobile device several times, even after changing the battery. The RMS is located in the javax.microedition.rms package.

RMS database structure

A MIDlet can open any number of databases as instances of RecordStore. MIDlets within a suite can access the same databases. Access to MIDlets from different suites is denied. Even if the name of the database of two such MIDlets is the same, there are two separate databases. Only the MIDP 2.0 specification allows shared database access. An RMS database is in a platform-specific environment. In order to maintain the concept of platform independence from Java , the RMS internally implements several routines tailored to the respective system, so that externally abstract methods for database operations are available.

A record store consists of a collection of byte arrays with an associated unique ID starting at 1. It is a primary key (Engl. Primary key) is used. IDs from deleted entries are not recycled. If a new entry is added, it receives the next higher ID of the largest ID that has ever occurred. A RecordStore can be in four states.

Life cycle of an RMS database

First, a RecordStore with the status Not Exists is created with openRecordStore()and a name (max. 32 characters) as an argument. If the database already exists, the transition from the Closed state takes place . In the following state open the database with the methods can be addRecord(), setRecord()and deleteRecord()are modified, wherein a time stamp (engl. Timestamp) marks the date of last modification and a counter is incremented after each change. With getRecord()data records are read out with their ID. If several threads access a RecordStore, it is the task of the MIDlet to coordinate these accesses. closeRecordStore()closes the database and puts it in the Closed state . In this state, no access to the database is possible and, if you attempt this, will result in a RecordStoreNotOpenException. deleteRecordStore()deletes the database and the status Not Exists is reached. RecordStore defines the method enumerateRecords()by which records can be filtered or sorted. It returns an object RecordEnumerationthat allows flexible handling of an RMS database. This interface is very similar to the implementation of a classic linked list. It contains methods for dynamically scrolling through the data records as well as queries as to whether there is a next or previous element, etc. Further interfaces are the classes RecordListenerand RecordFilter. RecordListenerallows the interception of events such as B. Modifications of the database so that appropriate reactions can be set. With RecordFilterdata records can be checked for certain criteria.

Distributing a MIDlet

The distribution of MIDlets, i.e. the compilation of a program file, takes place as a Java Archive (JAR). A descriptive text file is also specified, the Java Archive Descriptor (JAD). However, many cell phones today no longer require a JAD file, but take the necessary information from the so-called manifest , a text file contained in the JAR with a similar structure and content.

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

In the JAD or manifesto are u. a. Information included about

Name and version of the MIDlet suite
Name, icon and program files of the MIDlets
Number of bytes in the JAR file (JAD only)
Required Java ME profile and configuration, i. H. CLDC version

In addition, some manufacturers such as Nokia have specified extensions. User-defined entries for the configuration of the application similar to command line parameters are also possible.

Web links

Individual evidence

↑ jcp.org

[1] .org