Prince Edward C.

Privado
BSIT IV 1A
1. Mobile Information Device Profile vs MIDlets
Mobile Information Device Profile (MIDP) is a specification published for the use
of Java on embedded devices such as mobile phones and PDAs. MIDP is part of the Java
Platform, Micro Edition (Java ME) framework and sits on top of Connected Limited
Device Configuration (CLDC), a set of lower level programming interfaces. MIDP was
developed under the Java Community Process. The first MIDP devices were launched in
April 2001.
A MIDlet is an application that uses the Mobile Information Device Profile (MIDP) of
the Connected Limited Device Configuration (CLDC) for the Java ME environment.
Typical applications include games running on mobile devices and cell phones which
have small graphical displays, simple numeric keypad interfaces and limited network
access over HTTP.
2. What are the hardward and software requirements to build midlets and
midp
Hardware requirement
Memory: At least 128 KB of RAM for installation of MIDP. There must be at least
32KB for Java heap. At least 8KB of non-volatile memory is required.
Display: Screen should be at least 96 pixels wide and 54 pixels high. A screen must
support at least 2 colors. PDAs have 160 pixels and support 65536 colors.
Input device: RIM wireless handheld at the one end of the spectrum that has
complete alphanumeric keyboard. Palm-based OS handsets have facilities for writing
on the screen in the form of shorthand known as Graffiti.
Software requirement
3. MIDp Architecture

B
a
sic Layer
Local data storage

Prince Edward C. Privado

BSIT IV 1A
Persistent storage of data
Push Registry
Allows MIDlets to be launched in response to incoming network
connections(e.g.,alerts)
Connectivity
Connection for datagrams, sockets, and server sockects
OTA provisioning
Simplifies the way applications are delivered to consumers
Ability to dynamically deploy and update applications over-the-air (OTA).
How applications are discovered, installed, updated...
Second Layer
End-to-End security
MIDP provides a robust security model: http and https connections, and
public key management
Third Layer
Application Management
Applications are called MIDlets, manager in charge of controlling their
state
Higher Layer
Game
Specific game API for developers
User Interface
Both High Level (ready made widgets), and high level API (developer can
paint on the screen)
Media
Audio utilities API

4. MIDlet life cycle

Explain the lifecycle of a MIDlet.

Prince Edward C. Privado

BSIT IV 1A
1. The MIDlet life-cycle is fundamental to creating any MIDlet.
2. The life-cycle defines the execution states of a MIDlet creation, start, pause,
and exit.
3. A MIDlet is either in the active state or the paused state.
4. When it is first loaded by the MIDP runtime environment, it will be in the
paused state.
5. The runtime will generally call the method startApp() to signal that the MIDlet
should now activate itself.
6. Whenever the application is idle, the runtime can put the MIDlet back into the
paused state.
7. When it is paused, the application will not receive user interface events.
8. The runtime will call pauseApp() to indicate that it has done this.
9. When the operator is finished with the MIDlet, the runtime will destroy it.
10. Before it does this, it calls the method destroyApp() method.
11. The MIDlet must deallocate resources here as it does when it enters the
paused state.
12. In the MIDP documents, `destroyed' is described as being one of the states
that the MIDlet may be in.
5. Platform standardization
The Java platform available to MIDlets is that provided by CLDC as described in
Chapter 2, together with a collection of MIDP-specific packages arranged under
thejavax.microedition package hierarchy. The core libraries themselves are
almost unaffected by the MIDP specification; the only change is the addition of
the J2SE 1.3 timer facility in the java.util package, which will be covered in the
later section "Timers and TimerTasks". The MIDP specification also places the
following requirements on the core libraries:

Like applets, MIDlets are managed in an execution environment that is slightly

different from that of a Java application. As you'll see shortly, the initial entry
point to a MIDlet is not the main( ) method of its MIDlet class, and the MIDlet is
not allowed to cause the termination of the Java VM. In order to enforce this
restriction, the exit( ) methods in both the System and Runtime classes are
required to throw a SecurityException if they are invoked.
In addition to the system properties defined by CLDC, MIDP devices must set
the microedition.locale property to reflect the locale in which the device is
operating. The locale names are formed in a slightly different way from those
used by J2SE, because the language and country components are separated by a
hyphen instead of an underscore character. A typical value for this property
would be en-US on a MIDP device, whereas a J2SE developer would expect the
locale name in the formen_US. Since both MIDP and CLDC provide almost no
support for localization, however, the precise format of this property is of little
direct interest to MIDlets. Instead, it is intended to be used when installing
MIDlets from external sources, to allow the selection of a version of the MIDlet
suitable for the device owner's locale. The property must therefore be properly
interpreted by the agent (perhaps a servlet running in a web server) that supplies
the software.
The system property microedition.profiles must contain at least the value MIDP1.0. In the future, as new versions of the MIDP specification are released and
implemented, devices that support multiple profiles may list them all in this
profile, using spaces to separate the names.

Prince Edward C. Privado

BSIT IV 1A