As I have mention in my previous article (J2ME technical discussion part-1).
Here I am going to give presentation about the MIDP architecture and API.
Outline:
>> MIDP Introduction
- Hardware and Software Requirements
- MID Profile Architecture
- MIDlet Suite
>> Basics of MIDlet
- MIDlet
-MIDlet StateChangeException
-Display
-Displayable
H/W and S/W Requirement
>> H/W Requirement
-Screen size 96*54 pixels
-At least one type of user input(keyboard, touch screen)
-128 KB non-volatile memory for MID component.
-8KB non-volatile memory for storing persistence data.
-32 KB of volatile memory to running java.
-Wireless N/W connectivity
>> S/W Requirement (OS S/W)
- Minimal scheduling, Exception handling and processing of interrupts software.
- support for displaying bitmapped graphics
- Must accept I/P and pass to JVM
- Data Persistence S/W.
- Software must be capability to read and write to/from non volatile memory.
- There must be access to the networking on the device.
MID Profile Architecture
• MID- To visually portrait the architecture of the application begin with the Hardware
• Native OS – One step up running on the H/W is the Native OS.
• Native apps - first reference to an application running on an MID.
- example are configuring application (i.e. Date,Time, Ring setting)
- Before J2ME only one type of apps will run in mobile that’s are native app.
• CLDC installed on the native operating system and is the foundation for the for MIDP.
• MIDP applications have access to both the libraries of CLDC and MIDP.
• OEM-specific (original equipment manufacturer) classes are provided by the manufactory of the company
MIDlet Suite
• MIDlet is a java application designed to be run on a mobile device.
• It has as its core java classes the CLDC and MIDP.
• MIDlet suite consists of one or more MIDlet packaged together usings a JAR file.
>> Runtime environment and application manager
-- Application manager is the software on a mobile device that is responsible for installing, running and removing MIDlet suite.
-- Application manager is a device – dependent software(ie., designed and implemented by Manufacture of device).
When application manager start the MIDlet , It will make all the following available to the application:
-- Access to the CLDC and JVM
-- Access to the MIDP-define classes : user interfaces , persistence storage ,networking support using HTTP,timer and managing user interaction with the device.
-- Access to JAR file
-- Access to JAD (Java Application Descriptor) file
>>Java Archive File (JAR)
-- Bundle all the information(Class file , images and application information) related to project into single entity known as a JAR file.
-- In addition to classes and resource file , a JAR contains a file known as a manifest.
-- manifest describe the content of the JAR file.
-- manifest file has the name manifest.mf and is stored as the part of JAR file itself.
>> JAR Manifest Attributes
--Manifest has totally nine attribute , no need to define all attribute.
--If the following six attribute are inside the manifest , the application manager will refuse to load the JAR:
- MIDlet-Name
- MIDlet-Version
- MIDlet-Vendor
- MIDlet-
(one entry for each MIDlet in the JAR file) - MicroEdition-Profile
- MicroEdition-Configuration
>> JAR –MIDlet Attribute
>> Sample manifest entry
MIDlet-Name: Todo List
MIDlet-Version: 1.0
MIDlet-Vendor: Core J2ME
MIDlet-1: TodoList, /images/Todo.png, Todo.TodoMIDlet
MicroEdition-Profile: MIDP-1.0
MicroEdition-Configuration: CLDC-1.0
>>> JAD(Java Application Descriptor)
>> JAD file may be available as part of the MIDlet suite to provide information about the MIDlet(s) within the JAR.
>> The rational behind including a JAD file is as follow.
1. To provide information to the application manager about the contents of a JAR. With this information, decisions can be made as to whether or not a MIDlet(s) is suitable for running on the device.
2. Provide a means for parameters to be passed to a MIDlets(s) without having to make changes to the JAR file.
>> JAD Attribute
-- JAD have set pre-define attribute
-- You can also define your own attributes as you see necessary for your application.
-- Simply create names that do not start with "MIDlet-" and you are good to go
-- As with the manifest file, there is a required set of attributes that must be defined in the JAD file:
- MIDlet-Name
- MIDlet-Version
- MIDlet-Vendor
- MIDlet-
for each MIDlet - MIDlet-Jar-URL
MIDlet
• MIDlet is the application that is build-upon the MIDlet Class.
• The application manager communicates with a MIDlet through methods in this class.
• This communication is a two-way street.
• As an example, just as the application manager can pause a MIDlet (e.g., to allow a user to answer an incoming phone call), a MIDlet can make a request to be paused (and later restarted).
MIDlet API
MIDlet StateChangeException
• During the course of a MIDlet's lifecycle, if an error occurs when changing states, this exception is thrown.
• Two methods(startApp(), destoryApp()) in MIDlet class are throw this Exception
| Constructer | Description |
| MIDletStateChangeException() | Create exception object with no text |
| MIDletStateChangeException(String s) | Create exception object with text |
• There are two constructors for creating this exception, one with and without a text message.
• Eg. TestException
Display
• Each MIDlet has a reference to one Display object
• Retrieve information about the current display (e.g., the range of colors supported) and includes methods for requesting that objects (Forms, TextBoxes, etc.) be displayed.
• display controlling what is shown on the device and when
• Note
- only one display object per MIDlet
Creating a Display object
A Display object is made available to a MIDlet through a call to a static method declared inside the Display class.
Structure
public class DisplayStats extends MIDlet
{
private Display display; // Reference to Display object
// MIDlet constructor
public DisplayStats()
{
display = Display.getDisplay(this);
...
}
...
}
Display API
Display Class: javax.microedition.lcdui.Display
Method | Description |
| static Display getDisplay(MIDlet m) | Get Display object for this MIDlet |
| Displayable getCurrent() | Displayable getCurrent() Get current Displayable object |
| void setCurrent(Alert alert, Displayable nextDisplayable) | Show an Alert followed by the specified Displayable object |
| void setCurrent(Displayable nextDisplayable) | Show a new Displayable object |
| boolean isColor() | Does the device support color? |
| int numColors() | How many colors (or shades of gray) are available? |
| void callSerially(Runnable r) | Request a runnable object be called after repainting |
Displayable
• Display can show any number of Displayable objects.
• a Displayable object can be viewed on a device
• The MIDP includes two subclasses of Displayable: Screen and Canvas.
• Screen object(Textbox, List, Form and Alert) are all high-level user interface components, as their implementation and presentation on the device are handled for you.
• The Canvas object is used for custom graphics and low-level event handling, such as when writing games, and requires a little more finesse on your part to update the display.
Creating Displayable Object
• We don't create Displayable objects directly; instead, we reference subclasses of Displayable
• Screen and Canvas extend the Displayable class
• Using API
| Method | Description |
| void addCommand(Command cmd) | Add Command to Displayable object |
| void removeCommand(Command cmd) | Remove Command from Displayable object |
| void setCommandListener(CommandListener l) | Add CommandListener to Displayable object |
| boolean isShown() | Is the Displayable object visible on the screen? |
Event Handling
• Event Handling in
• Command Object
• Item Object
• Command and Command Listener
• Item and Item Listener
Event Handling in
• event handling is nothing more than recognizing when an event occurs and taking an action based on that event.
• there are three key steps to successfully managing an event.
- The hardware (the physical device itself) must recognize that something has occurred.
- The software on the device (the application manager) needs to be notified of the event
- A message from theapplication manager will be sent to the MIDlet. This message will contain information about the event so we can make decisions as to how to proceed
Command Object
• A Command is an object that holds information about an event.
• The simplest way to think of a Command is as a "button," something that you press or select
• Processing events requires a little legwork up front. Here are the steps:
1. Create a Command object to hold information about an event.
2. Add the Command to a Form, Textbox, List or Canvas.
3. Add a "listener" to the above Form, Textbox, and so forth.
Command Object Creation
private Form fmMain; // A Form
private Command cmExit; // A Command to exit the MIDlet
...
fmMain = new Form("Core J2ME"); // Form object
cmExit = new Command("Exit", Command.EXIT, 1); // Command object
...
fmMain.addCommand(cmExit); // Add Command to Form
fmMain.setCommandListener(this); // Listen for Form events
...
public void commandAction(Command c, Displayable s)
{
if (c == cmExit)
{
destroyApp(true);
notifyDestroyed();
}
}
Item Object
• An Item is any component that can be added to a Form. ChoiceGroup, DateField, Gauge and TextField are all subclasses of Item and each can process events.
• Items are accessible only as part of a Form, whereas Commands areavailable on Forms, as well as a Textbox, List, or Canvas.
• Once you add an Item to a Form, as with Commands, you must add a listener
• Once there is a change to an Item (e.g., a Gauge has been incremented or a DateField has been changed), the listener object will be notified (sent a message).
