Session 3 J2ME Mobile Information Device Profile(MIDP)  API
Upcoming SlideShare
Loading in...5
×
 

Session 3 J2ME Mobile Information Device Profile(MIDP) API

on

  • 2,909 views

Session 3 Presentation in J2ME

Session 3 Presentation in J2ME

Statistics

Views

Total Views
2,909
Views on SlideShare
2,894
Embed Views
15

Actions

Likes
0
Downloads
94
Comments
0

2 Embeds 15

http://microtechinfo.blogspot.com 14
http://www.blogger.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Session 3 J2ME Mobile Information Device Profile(MIDP)  API Session 3 J2ME Mobile Information Device Profile(MIDP) API Presentation Transcript

  • Session :3 (30-Mar-09) - 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
  • H/W an S/W Requirement
    • >> 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 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.
  • MID Profile Architecture (Cont.,)
    • 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 consist of one or more MIDlet packaged together usings a JAR file.
  • MIDlet suite(Cont.,)
    • >> 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
  • MIDlet Suite(Cont.,)
    • >>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.
  • MIDlet Suite(Cont.,)
    • >> 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-<n>(one entry for each MIDlet in the JAR file)
        • MicroEdition-Profile
        • MicroEdition-Configuration
  • MIDlet Suite(Cont.,)
    • >> JAR –MIDlet Attribute
  • MIDlet suite(Cont.,)
    • >> 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
  • MIDlet Suite (Cont.,)
    • >>> 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.
  • MIDlet Suite(Cont.,)
    • >> 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 &quot;MIDlet-&quot; 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-<n> for each MIDlet
      • MIDlet-Jar-URL
  • MIDlet Suite(Cont.,)
  • MIDlet Suite(Cont.,)
    • >> Simple JAD file
      • MIDlet-Name: Todo List
      • MIDlet-Version: 1.0
      • MIDlet-Vendor: Core J2ME
      • MIDlet-Jar-URL: http://www.corej2me.com/TodoMIDlet.jar
      • MIDlet-Jar-Size: 17043
      • MIDlet-1: TodoList, /images/Todo.png, Todo.TodoMIDlet
  • 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 LifeCycle
    • MIDP applications are known as “MIDlets”
    • MIDlets move from state to state in the lifecycle, as indicated.
      • Start – acquire resources and start executing
      • Pause – release resources and become quiescent (wait)
      • Destroy – release all resources, destroy threads, and end all activity
    Pause Active Destroyed startApp destroyApp pauseApp destroyApp
  • MIDlet API Method Description Communication from application manager to MIDlet abstract void destroyApp (boolean unconditional) MIDlet is about to be shut down abstract void pauseApp() MIDlet is about to be placed into paused state abstract void startApp() MIDlet has been placed into active state Communication from MIDlet to application manager final void notifyDestroyed() MIDlet is requesting to be shut down final void notifyPaused() MIDlet is requesting to be paused final void resumeRequest() MIDlet is requesting to become active (after being paused) Attribute request from MIDlet to application manager final String getAppProperty (String key) Get attributes from JAR and/or JAD files
  • 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
  • MIDlet StateChangeException API
    • There are two constructors for creating this exception, one with and without a text message.
    • Eg. TestException
    Constructer Description MIDletStateChangeException() Create exception object with no text MIDletStateChangeException(String s) Create exception object with text
  • 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 Mobile device
    • Command Object
    • Item Object
    • Command and Command Listener
    • Item and Item Listener
  • Event Handling in Mobile Device
    • 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 &quot;button,&quot; 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 &quot;listener&quot; 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(&quot;Core J2ME&quot;); // Form object
    • cmExit = new Command(&quot;Exit&quot;, 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();
    • }
    • }
  • ItemObject
    • 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).
  • Item Listener object creation
    • private Form fmMain; // A Form
    • private DateField dfToday; // A DateField
    • ...
    • fmMain = new Form(&quot;Core J2ME&quot;); // Form object
    • dfToday = new DateField(&quot;Today:&quot;, DateField.DATE); // DateField
    • ...
    • fmMain.append(dfToday); // Add DateField to Form
    • fmMain.setItemStateListener(this); // Listen for events
    • ...
    • public void itemStateChanged(Item item)
    • {
    • // If the datefield initiated this event…
    • if (item == dfToday)
    • ...
    • }