ISEMVJCE2014-15

INFORMATION SCIENCE AND ENGINEERING

Semester 8

10IS831-WIRELESS NETWORK AND MOBILE COMPUTING

Author Details:

Name: VanshikaRastogi

Designation: Asst. Professor

Department:ISE

Dept. of ISE

Unit-8

J2ME

  1. Why JAVA???
  • Both procedural and Object Oriented (C/C++) had inherent drawback of platform dependency.
  • Overcoming this drawback has been one of the reason for the success of JAVA.
  • This is because JAVA is a cross between a compiled and interpreted language.
  • The process is divided into two steps;
  • Firstly, Java compiles and generates the code called the byte code, which are interpreted by the virtual machine in the second step.
  • This require that the virtual machine should be there in all the environment where Java program has to be executed.
  1. Mobile Application Architecture
  • Basically, there are two types of mobile applications:
  • Those that are device resident; i.e., those that utilize exclusively the device resources and do not interact with any other applications outside except may be while downloaded or installed.
  • Games are one of the example of such applications.
  • The second type are the network-enabled applications.
  • A typical J2ME transaction is shown in the figure below.
  • The device resident client app initiates a request to the server application using any of the service bearer like, GSM, CDMA, etc.
  • The protocols may vary from HTTP to WAP.
  • The request received by the server is processed and the response is returned to the application.
  1. JAVA 2 MICRO EDITION (J2ME)
  • J2ME was conceived from the need to define a computing platform that could accommodate consumer electronics and embedded devices.
  • The biggest challenge for J2ME was to define a platform that could support a consistent set of services across a broad spectrum of devices with a large multitude of capabilities.
  • The designers of J2ME came up with a concept of configurations and profiles towards achieving this goal.
  • A configuration defines the lowest common denominator or the minimum capabilities that will be available across a given range of devices.
  • It is a complete Java run time environment, consisting of :

A JVM

A set of Core Java runtime classes

A set of supported API

  • Configuration specify classes and methods that are inherited from J2SE (Java 2 Standard Edition) classes.
  • That means, J2ME is a subset of J2SE.
  • Configurations also include additional classes to adapt to device capabilities and constraints.
  • To avoid fragmentation and a deluge of incompatible platforms, J2ME defines only two types of configurations that represents the two distinct categories of devices.
  • The first category is devices that have superior UI facilities such as higher computing power and are constantly connected. These implement the Connected Device Configuration (CDC).
  • For example, set-top box, Internet TVs, Internet-enabled screen phones.
  • The second being personal, mobile information devices that are capable of intermittent communication. These implement the Connected, Limited Device Configuration (CLDC).
  • For example, mobile phones, pagers, PDAs and organizers.
  • Profile takes the configuration a step further by defining the libraries used to create applications.
  • The profile specifies the application level interface for a particular class of devices representing a vertical market.
  • Profiles are built on top of and utilizes the J2ME configurations.
  • Profiles are also a mean to guarantee interoperability.

Fig. 8.1: how the three fit in together

CDC

  • CDC is a configuration for high end devices with large memory, in the range of 2MB or more, providing connectivity through some kind of network and some UI support.
  • CDC is a superset of the CLDC and is close to the J2SE runtime environment.
  • The CDC specification defines:

A full-featured JVM, called the CVM.

A subset of the J2Se 1.3 classes

APIs introduced in the CLDC-the generic connection framework

  • The CDC defines three profiles:

Foundation Profile: is targeted at devices supporting a strong network, but does not provide any UI. Essentially, it does the “useful” work. It is also used as a base by other profiles.

Personal Basis Profile: the J2ME Persona Profile is a reinforcement of the Personal Java Application Environment suitably modified to fit into the J2ME environment. It caters to devices that enjoy reliable and constant internet connectivity and rich GUI.

J2ME Remote Profile: provides support for RMI across applications. It is built on top of Foundation Profile and uses TCP/IP as the connection protocol.

CLDC

  • Is meant for low end, intermittently connected, battery-operated devices.
  • A CLDC device is characterized by the following capabilities:

A minimum of 128 to 512 KB for the platform.

A 16-bit or 32-bit low end processor.

A low-bandwidth network with intermittent connectivity.

  • CLDC runs on KVM, which is highly optimized JVM for resource constrained devices.
  • CLDC does not support the following Java language features:

Floating point calculations

Object finalization

Customer class loader

Error classes

  • Sun has released two profiles that sit atop the CLDC. They are MIDP and PDAP.

MIDP

  • J2ME Mobile Information Device profile.
  • The first profile to be released.
  • Current version is 2.0
  • It provides classes for writing downloadable applications and services that are of interest to the consumer for example, games, commerce applications, personalization services.
  • The MIDP profile requires the devices to have that following capabilities:

A minimum of 512KB for the platform.

Intermittent connectivity to some type of wireless network.

Limited user interface

Some kind of input mechanism.

PDAP

  • J2ME Personal Digital Assistant profile.
  • Recently released profile for the PDA market.
  • It lies on top of CLDC specification.
  • Provides user interface and data storage APIs for devices.
  1. Programming for CLDC
  • We will take MIDP into consideration.
  • A MIDP application is called MIDlet.
  • The MIDlet Model
  • MIDlet sits atop the MIDP which in turn requires the services of the CLDC and the VM below it.
  • It is the device hardware that executes instructions on behalf of the software layer above.
  • Like an applet, MIDlet needs an execution environment.
  • The browser’s equivalent in the MIDP world is called Application Management Software (AMS).
  • All MIDlet runs within the context of an AMS.
  • A set of MIDlets can be grouped together into a MIDletsuite.
  • Provisioning
  • It is the process of application discovery, download and installation.
  • PDAs allowed this by downloading the application on the PC and then using a serial cable to transfer it to the device.
  • Provisioning includes:

Search: which can be performed by the user manually entering the URL.

Retrieve: the descriptor file, which includes the application details, checks for version, and compatibility issues.

Download: the appropriate jar file is downloaded. All middle suites are packaged into a jar file.

Install: once the download is completed the AMS is called to install.

Finally, the VM is launched and

The application is launched.

Fig.:Provisioning

  • The MIDlet Lifecycle
  • A MIDlet has three states.
  • A MIDlet class extends javax.microedition.javax.microedition.midlet.
  • MIDlet defines the lifecycle notification methods.
  • These methods allow the AMS to notify and request MIDlet state changes.

Applications are launched either by a user selection or in response to an external event from the push registry. On being activated by the AMS, the MIDlet is constructed but is still inactive. Now the MIDlet is in the paused state.

Once constructed, the AMS initializes and activates the MIDlet by invoking its startApp() method. The MIDlet now changes to active state. If the initialization fails a javax.microedition.midlet.MIDletStateChangeException is thrown and the stae is changed to destroyed.

A transition from active state to the paused state is initiated by the AMS by calling the MIDlet’spauseApp() method. In this state a MIDlet should release all its resources.

A MIDlet can be destroyed from either active or paused state.


Fig.: MIDlet Life Cycle

  1. Creating a New Application
  • To create a new application, first need to download the WTK.
  • Click on “New Project”
  • Enter appropriate names for the application and the application class and click “Create Project”.
  • By default, WTK will create the folder structure under the Apps folder of the WTK root.
  • Use any editor, to enter the program above and save it under the source folder of the application.
  • Go back to the WTK and click “Build”. If everything is OK, we will get a Build complete message.
  • Clicking on run will launch the emulator which lists the MIDlet currently registered with the WTKAMS.
  1. MIDlet Event Handling
  • User interactions generate events. These could be:

Screen inputs

Item state change

Handset data update

  • MIDP event handling mechanism is based on a listener model.
  • It provides interfaces for each event.
  • The interfaces implements the call back methods, which in turn invocate application-defined methods.
  • These methods perform the desired functions in response to events.
  • Command Listener
  • Is responsible for notifying the MIDlet of any commands or events generated by the user.
  • Objects extending it, implement the commandAction method.
  • This method takes two parameters: a command object and a displayable.
  • Item State Listener
  • It informs the MIDlet of changes in the state of an interactive item.
  • It calls the itemStateChange method in response to an internal state change.
  • Record Listener
  • It is related to database events.
  1. GUI in MIDP
  • “displayable” has two main subclasses Screen and Canvas.
  • The screen is the superclass for a set of predefined UI elements.
  • The predefined UI elements are called High Level UI elements.
  • The canvas elements are called Low Level UI elements.
  • High Level UI
  • Form: it is similar to thr HTML counterpart. It is used to hold itms and elements.
  • Items: to do some useful work we have to put some items in the form. MIDP provides some predefined items.
  • ChoiceGroups: allows the user to select one or more elements from a group. These groups are similar to “radio button”, “check boxes”, drop-down”.
  • DateField: an interactive item to enter/retrieve date and time information. Datefield extends the item class so that it can be placed on Form Objects.
  • Gauge: it can be considered as a progress bar. The constructor takes a label, Boolean flag, where true indicates interactive and false indicates non-interactive. It allows the user to change the values using some device-dependent input method.
  • StringItem: are similar to labels in functionality. They have a name or label and the display string.
  • ImageItem: it is a non-interactive item.
  • TextField: handles all text input. The constructor takes four parameters: a label or the name of the Item, the input lengthand constants that indicate the type of input allowed.
  • CustomElement: it extends the Item class, offers a simple template for developing custom items.
  • List: is a list of options that the user can select from.
  • Low-level GUI
  • Allow the application to control Displayable on the screen and allow the programmer to directly draw on the screen using the screen coordinates.
  • Specifically needed for applications like games, business tools that need to show graphs, bars, pie charts.
  • Canvas: it is a blank screen. We can draw lines, text and shapes on the screen.
  • Game API: all games APIs are in the package javax.microedition.lcdui.game. The first class in this package is the GameCanvas class. It inherits from canvas and basically provides the screen for a game.
  • Sprite: used for animation purpose. It provides various operations including flip, rotation, collision detection and more.

  1. Multimedia
  • A new entry in MIDP 2.0 is the Media API, a subset of Mobile Media API.
  • This library provides support for audio capability.
  • A J2ME audio application consists of three parts:

A manager that is responsible for creating and controlling the audio resources.

A player, the workhorse that does the actual job of playing the music.

A control to regulate the features of the player.

  • A plyer’s lifecycle has five states.
  • A player begins its life in the UNREALIZED state. Here it is still unformed and requires additional information to acquire resources.
  • At this point a call to realize () transitions it to the next state which is the REALIZED.
  • This method allows the player to collect information by which it can obtain resources.
  • In the REALIZED state the player is ready to acquire the required resources.
  • Here a call to prefetch () transit to PREFETCHED state.
  • In the PREFETECHED state all initializations happen.
  • A call to start () method will now start the player.
  • The start method also causes a STARTED event to be fired. It is now in the STARTED state.
  • From here, once the player reaches the end of the file it will automatically stop.
  • A corresponding STOPPED event will be triggered.
  • The last state in the life cycle is the CLOSED state.
  • Here it releases all the resources and must not be used again.
  1. Communication in MIDP
  • HTTP must be supported on all J2ME handsets.
  • All connection APIs come under the broad scope of a Generic Connection Framework (GCF) provided by CLDC.
  • The GCF provides a single consistent set of abstractions for the developer.
  • A call to connection interface would look like
  • ConnectionType conn=(ConnectionType) Connector.open ( URI );
  • Where URI is of the form:
  • <protocol>:<address>:<parameters>:
  • “protocol” specifies the protocol to be used.
  • “address” specifies the destination of the connection.
  • “parameters” are connection parameters as required by the specified protocol.
  • HTTP Connections
  • This allows to set the user-agent, the user language, the version of MIDP and CLDCsupported and also the application specific variables.
  • This feature is extremely useful when applications use server processing capabilities of a server.
  • For this MIDP provides set Requestproperty and getRequestProperty. Methods.
  • The SocketConnection Interface
  • Returns a socket connection and is normally used to access TCP/IP servers.
  • If a host name is specified, we get a client; else we get a server.
  • If the port number is missing, the default available port number is assigned to the port.
  1. Security Considerations in MIDP
  • Security considerations are of different types: application security, data security and communication security.
  • Application Security
  • The MIDP 2.0 security model introduces the concept of security domain.
  • A security domain defines the access permissions for an application.
  • Application belong to either

The trusted domain, i.e., permitted to use APIs that are considered sensitive.

The un-trusted domain, i.e., having restricted access.

  • A MIDlet suite that is not trusted will run in untrusted mode.
  • Each domain is associated with a domain policy that defines the requirements for a MIDlet to be considered as trusted.
  • Domain policy defines a set of permissions “allowed” and “user” that can be granted to the MIDlet.
  • “allowed” grants the MIDlet permissions to access and use the requested API.
  • “use” means the MIDlet has to obtain explicit user permissions through UI.
  • Recordstore Security
  • MIDP 2.0 allows for shared record stores.
  • Sharing is defined at the time of creation.
  • Access controls are enforced when Record Store are opened.
  • Communication Channel Security
  • Secured networking was introduced in MIDP2.0 with HTTPS.
  • The prmissions are granted individually to protocols.
  • Security of PushRegistry
  • Uses the security framework and permissions.
  • Only MIDlet suites having permissions can register for a Push based launch.

WIRELESS NETWORKS AND MOBILE COMPUTING / 1