The user interface

MIDP has to be able used by all the devices :

• The majority of the wireless devices are used in one hand
• Small screens
• All the devices have not a pointer

You must always think to the final users :

• The information mobile devices are products for clients, not desktop computers
• The user interface must be unified by MIDP : all the MIDP applications must integrate the same functionnalities

A user interface in two layers

The user interfaces of MIDP can be created by using one of the two layers of the API.

The High Level API for portability :

• We can execute and use the applications using these APIs on all the MIDP devices
• No other direct access to the native functionnalities of the device

The Low Level API :

• It provides an access to the primitives of native drawing, events about keys, entry process, ...…
• It is the possibility for the developer to reduce portability to increase usuability

Principes of conception based on the Screen

The user interface of the MIDlets are based on simples screens.

The screens must contain a minimal quantity of informations : in general only one thing.

The screen must ask only one interaction of the user.

No complex operation is possible.

The timer

The timer manages queues and deliveries.

It can :

• Trigger more than a task by timer
• Be periodical
• Be triggered at fix intervalls
• Do "one shot"

The entry

The High Level API is managed by using abstract command : you don't access directly to the soft buttons :

• Each implementation of MIDP do a matching between the soft buttons and the items of the menu for a specific device
• MIDlets can provide semantic informations (example : back)

The Low Level API permit to the developer to access to the events of pression of the keys.

Here you are examples of commands :

• new Command("Buy", Command.SCREEN);
• new Command("Info", Command.SCREEN);
• new Command("Back", Command.BACK);

RMS

RMS is a light database oriented records :

• Independant API from the device
• ID of record unique for each record of the store
• The records are arrays of bytes
• Shared in a MIDlet Suit
• Atomic update for the simple records
• Support of the enumeration, order and filter

The platform of the device is responsible of :

• The integrity of data when you boot and change battery
• The storage in memory Flash

The main methods are :

• Storage : openRecordStore, closeRecordStore, listRecordStore, deleteRecordStore, getRecordSize, getNumRecords
• Data : addRecord, deleteRecord, getRecord, setRecord, getRecordSize
• Selection : RecordEnumeration, RecordFilter, RecordCompare

The network connection

The MIDP devices can implement the HTTP protocol.

MIDP extend the network of the Generic Connection framework of CLDC : HttpConnection contains get/setRequestProperty, get/setRequestMethod, getResponseCode, getResponseMessage, getHeaderField, getURL, getHost, getPort, getFile, getQuery, getRef.

The development of an application

Write a MIDlet :
c:>javac -g:none -bootclasspath e:midp-fcsclasses HelloWorld.java

Preverify :
The verification of the class file is not done in the device.
c:\midp-fcs\bin\toolspreverify -classpath e:midp-fcsclasses HelloWorld

Create a JAR file for the application (optionnal) :
c:\jdk1.3\bin\jar cf hi.jar -C .output HelloWorld.class

Deploy the application

Launch the application :
c:\midp-fcs\bin\midp.exe -classpath e:midp-fcsclasses;.hi.jar HelloWorld

The development of an application on Palm OS

Compile :
javac -classpath j2me_cldc\bin\apiclasses;. -d -bootclasspath j2me_cldc\bin apiclasses HelloWorld.java

Preverify :
preverify.exe -classpath j2me_cldc\bin\apiclasses;. -d HelloWorld

Launch the utility MakePalmApp :
java -classpath j2me_cldc ools palm.database.MakePalmApp –bootclasspath j2me_cldc\bin\apiclasses -classpath . HelloWorld

Load in POSE