This writing was written in 2009. Back then Android was not yet developed.
One big difference that a programmer for handheld device will notice is the fact that applications which display text at the command window and obtain input from the command window cannot be implemented on mobile phones. More so some GUI components like AWT was designed for desktop applications. Resizing windows, window management and event handling as understood in GUI applications are not much required in handheld devices.
The snippet of code below was written in VB after laying common controls, containers and components on the Form using the Visual Studio IDE.
Private Sub Login_MouseClick(ByVal sender As System.Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles Login.MouseClick
Panel2.Hide()
FlowLayoutPanel2.Hide()
Add.Hide()
End Sub
Such a code, which is familiar to GUI developers, cannot be automatically applied on hand-held devices due to the constraints of the screen size, input and hardware, limited memory and smaller CPU. Besides, each device has different input methods; some have full keyboards, others have joysticks, others have numeric keyboard, others have touch screen. A developer of an educational solution must keep in mind the differences in devices as well as the constraints some have more than others. Sometimes, one better concentrate on the basic functionality, rather than use technologies which may not be supported by most of the devices.
Java ME (formerly J2ME) is a downsized version of the standard Java SE platform intended for client side programming. The CLDC HotSpot VM (Java Virtual Machine) included in Java ME version 3.0, similar to the former KVM caters for small devices with limited CPU power and memory like cell phones PDAs etc. One may appreciate that while the requirements of the desktop increase and provided for by Java SE, and also provided server programming in the Java programming language by the Java EE, the demands also grew for small hand held devices.
Java is an object oriented language. Java Programmers create classes, which include peaces called methods.
public int throwDice( )
{
return 1+ Math.abs( random.nextInt() % dicelimit );
}
Methods return information and can be called where required.
Example:
public void initialize ()
{
// some information
}
public void paint (Graphics g) {
if (diceImage == null)
initialize ();
} //calls method initialize Java programmers become familiar also with the “rich collection of existing classes in the Java class libraries, which are also known as the Java APIs (Application Programming Interfaces). A java programmer needs to be familiar with the classes and interfaces of the API, most often bundled in packages, example Package java.io, package java.lang, java.util, javax.microedition.io.
A configuration specifies a JVM and APIs for a range of devices and are generally described in terms of:
• The types and amount of memory available
• The processor type and speed
• The type of network connection available to the device Java ME is devided into configurations, profiles and optional APIs as shown in Figure
Java ME defines two configurations, Connected Limited Device Configuration (CLDC) and Connected Device Configuration. A Connected limited device is designed for devices with 16KB to 512KB, including 160KB of ROM and 32 KB of RAM.A connected device has a minimum of 512 Kb of Read-only memory (ROM, which is non-volatile and 256KB of random access memory (RAM), which is used to store data and programs whilst they are open on the device. CDC is found on set boxes, web telephones and residential gateways. Besides memory a configuration also consists of the virtual machine and a minimal set of class libraries
One device may be different from the other, having different memory, different screen size and I/O interfaces. The profile sits on top of the configuration and allows each configuration to be adapted and provides the APIs and specifications necessary to develop applications for a specific family of devices. The profile adds networking, user interface components, and local storage to the configuration.
Besides an application written for MIDP 1.0 which had many limitations such as no active rendering APIs, no support for full screen mode, no support for audio etc, can execute on MIDP 2.0. Figure shows the minimum screen requirements for MIDP 1.0, 2.0 and 3.0 devices leading Java into richer mobile experiences
MIDP 2.0 provides the following APIs bundled in these packages:
User Interface Package
javax.microedition.lcd
The UI API provides a set of features for implementation of user interfaces for MIDP
applications.
javax.microedition.lcd
The Game API package provides a series of classes that enable the development of rich
gaming content for wireless devices.
Application Lifecycle Package
javax.microedition.mid
The MIDlet package defines Mobile Information Device Profile applications and the
interactions between the application and the environment in which the application runs.
Persistence Package
javax.microedition.rms
The Mobile Information Device Profile provides a mechanism for MIDlets to
persistently store data and later retrieve it.
Networking Package
javax.microedition.io
MID Profile includes networking support based on the Generic Connection
framework from the Connected, Limited Device Configuration.
Public Key Package
javax.microedition.pki
Certificates are used to authenticate information for secure Connections.
Sound and Tone Media
javax.microedition.med
The MIDP 2.0 Media API is a directly compatible building block of the Mobile Media
API (JSR-135) specification.
javax.microedition.med
This package defines the specific Control types that can be used with a Player.
Core Packages
java.lang
MID Profile Language Classes included from Java 2 Standard Edition.
java.util
MID Profile Utility Classes included from Java 2 Standard Edition.
As stated earlier it is very important that the Java ME developer be familiar with the following APIs because they are used in his/her application. A developer for example, imports the LCDUI API for which provides several user interfaces: List, Alert, TextBox, Form and Canvas, and also Commands.
The architecture of the LCDUI would look as in Figure
MIDP 2.0 makes use of the following high level components:
Form- TextBox, used for entering text
Alertused for showing dialog boxes and warnings)- TextField, which can be inserted in a form. (similar to JTextField)
StringItemused for showing text strings (usage similar to JLabel)ChoiceGroupused for showing radio buttons (similar to JCheckBox)DateField, used for selecting dates and timesGauge, can be used for example to show battery level etc.ImageItem, used for showing images in high-level UI applications (usage similar to ImageIcon)List, used for showing lists and combo boxes (usage similar to JList)
The MIDP 2.0 adds low-level APIs which allow “full control of the MID display at pixel level” (MIDP Programming with J2ME. Low Level API, http://www.developer.com/java/j2me/article.php/10934_1561591_5/MIDP-Programming-with-J2ME.htm.) including the CustomItem class and the GameCanvas class.
Scalable Vector Graphics (SVG) differ a lot from Bitmaps such as GIF, JPEG, or PNG. SVG is an XML-based vector graphics framework while the others are pixel based images.
There are several advantages of using SVG. One of them is size: The size of an image which in GIF format uses up 7,386 bytes, in a vector format, the size is only 693 bytes, less than a tenth as large, because “raster-based image formats like GIF encode the colour contents of each pixel of the rectangular region that comprises the image. Vector-based images instead contain only the drawing instructions that determine how the pixels should be coloured. The vector representation of an image can be much more compact, a big plus in resource-constrained mobile devices” (Michael Powers, Getting Started with Mobile 2D Graphics for J2ME, http://developers.sun.com/mobility/midp/articles/s2dvg/index.html).
Another advantage is interactivity. Using SVG one can create buttons, forms and even menus.
The MIDlet
An application written for the Mobile Information Device Profile is called MIDlet. A MIDlet uses only the APIs defined by the MIDP and CLDC specifications.
Every java programmer would come across the method in which execution to any java program begins:
public static void main (String [] args)
Unlike any application of the Standard Edition, a MIDlet has no static main method. Java is smart enough that if one is found the Application Management Software (AMS), sometimes known as Java Application Manager (JAM), which is the software on the device that manages the downloading and lifecycle of MIDlets, simply ignores it. MIDlets on the other hand have a specific life cycle, The MIDlet methods are therefore as follows:
public ExampleMidlet() {
}
public void startApp() throws MIDletStateChangeException {
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional) {
}
Figure below shows a state transition diagram of the MIDlet lifecycle.
Figure 6: State transition diagram of the MIDlet lifecycle In Martin de Jode The MIDlet is instantiated by the AMS, which provides the initial class for the MIDlet to initialize. This is however done in dormant state. Method pauseApp(), as shown in MIDlet, indicates to the MIDlet that it should enter the PAUSED state. The Active State is entered after the AMS has called the startApp () and the MIDlet is functioning normally. When the destroyApp() method has been called by the AMS all threads will be destroyed and the MIDlet will be destroyed
A typical MIDlet will look as follows:
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
public class RandomNumber extends MIDlet implements CommandListener{
private Display display;
private Command exit, generate, submit;
private Form form;
…
public RandomNumber(){
//constructor
display=Display.getDisplay(this);
form = new Form(“Basic Arithmetic”);
exit = new Command(“Exit”, Command.EXIT,0);
generate = new Command(“Generate”, Command.OK,1);
submit = new Command (“Submit”, Command.OK,1);
}
public void startApp(){
display.setCurrent(form);
count =0;
}
public void pauseApp(){}
public void destroyApp(boolean unconditional){
notifyDestroyed();
}
public void commandAction(Command c, Displayable d){
String label = c.getLabel();
if(label.equals(“Exit”)){
destroyApp(false);
}else if(label.equals(“Generate”)){
random();
form.addCommand(submit);
form.removeCommand(generate);
rizultat.setText(“”);
}else if(label.equals(“Submit”)){
submit();
form.removeCommand(submit);
}
}
A Midlet class has the following characteristics:
- Like in every Java Application the keyword class specifies that we are defining a class.
- It imports the APIs found in packages javax.microedition.lcdui.*; and javax.microedition.midlet.*;
- It extends the MIDlet class found in the javax.microedition.midlet package.
- It consists of the three methods which characterize the midlet lifecycle.
- The constructor usually describes the Display and user interface classes from the LCDUI API.
- The Display manages the device’s screen referenced in startApp()
- Declaration of variables like any other computer program
- It might consist of a commandAction method which allows interactivity using the command buttons
Once a developer completes the application he/she requires a development kit which enables the application to run on the device. Some years ago, Sun introduced the J2ME Wireless toolkit (See Figure 9), an easy and authoritative tool, which also included an emulator so that one can test the application on it rather than on the real device. The GUI tools automates the building and packaging of MIDlets including setting required attributes for a MIDlet suite as shown in Figure 7. In the times of the J2ME Wireless tookit, the source code including the MIDlet had to be placed manually where the Wireless Toolkit can get access to them, usually in the apps subdirectory of the Wireless tookit folder, e.g. C:\WTK2.5.2\apps.
The following folders will be created:
src
which olds the source code, .java, of the MIDlet and other classes:
res
which holds required resources including icons, svg etc:
lib
which holds third-party libraries:
bin
which holds the JAR, JAD and manifest files.
Nowadays the toolkit can be used with Netbeans and more work becomes automated. A developer simply creates the classes and sketches the midlet, taking advantage of Netbeans drag and drop features.
Java ME SDK replaced J2ME and also Sun Java Wireless toolkit and combines full support for creating and testing Java ME and JavaFX Mobile applications.”
When one builds an application all classes including the MIDlet, and the images and other resources are packaged into a single JAR file. This is the only file one needs to transfer from one’s desktop to the mobile phone. The JAR’s manifest file tells the device what is in the JAR file. The Java application descriptor(JAD) also has similar packaging information.
Figure 8: MIDP Java Application Descriptor and Executable JAR file
.
Required programming skills and limitations of hand-held devices
Developing wireless applications with java requires some programming experience in Java. Before starting Java ME one must be familiar with the APIs of the standard edition. The fundamentals of object oriented programming are an important requirement for a Java ME enthusiast. As an object oriented language, a java program is composed of lots of interacting software objects similar to real-world objects such as people, animals, plants, buildings etc.
Some knowledge in GUI is also a must. As stated before, one has to forget the System.out.println and instructions from the command line. Consider the following example:
form = new Form(“Addition/Subtraction”);
number1 = new StringItem(“”,””);
…
form.append(number1);
…
public void random(){
Random number = new Random();
float numbera = number.nextFloat();
firstnumber = (int)(numbera*100f)%100;}
…
number1.setText(“”+firstnumber);
The form produced by this code is a generated random number displayed on a form.
Using canvas class requires more or less the same skills as when working with GUI on desktop applications. However a difficulty may arise if one wishes to insert a high-level component such as textbox or stringItem together with a canvas screen. Since “it is derived directly from Displayable, it inherits the ability to have associated Commands, but it does not provide a title or the ability to contain other components”(J2ME in a nutshell, p. 139). A Java ME developer may opt therefore to display results of a game as an example on a separate form.
Jason Lam, in J2ME & Gaming, listed several mobile-devices constraints including:
a. Memory
which can be divided into the heap memory and RMS, record management system. If an application is bigger than the allocated heap memory on the device the application will not work.
b. Display Size and Colour
c. Phone Interfaces, including different layout of buttons and control
d. Missing classes (Jason Lam, J2ME & Gaming v 0.5.6, p. 15-18 [open source] http://www.jasonlam604.com).
Java ME as a downsized range of API classes such as no built-in API support for file handling, RMI, JDBC, JNDI, or the AWT/Swing user interface models. One must also keep in mind the support for file formats, such as images, sounds and videos and reducing the size to fit on screen and in memory
Analysis and Design
The first step in this analysis was a use case diagram. These model diagrams here are more to help the developer build the required tasks and help a client understand the system. Modelling language is far beyond the scope of this dissertation but no developer can come out with a good project without some form of planning and design. The use case diagram shown in figure , shows what a user can do with the application.
The diagram describes the interaction of the user with the system. A user can perform one of the following activities:
- Display information about M-learning or the ‘about’ screen
- Study Logo which is used in basic skills mathematics
- Load the addition/subtraction activity
- Load the multiplication activity
- Load the guess shape activity.
Last two activities require the generation of a random number, which class is not visible to the user but plays an important role.
Flowcharts were then sketched can give a step-by-step solution to each problem and represent the algorithms Flowscharts were chosen due to the less-object oriented nature of Java ME, and to show clearly the sequence of operations to be performed. The first flowchart (Figure 10) represents the MainMenu and its operations. Main Menu will consist of a SVG menu if supported by mobile device. Otherwise commandAction can still have the same functionality.
The Displayables of the LCDUI APIs will be demonstrated in the first activity with the aim to teach LOGO which is widely used in mathematics, especially in basic skills mathematics. Images and other items can be inserted on the Form.
The addition/subtraction activity (Figure 11) will make use of the Form. Two methods are called; one to generate a number to hundred and the other to generate the operator (either + or -). Either an addition or a subtraction will be displayed, using stringItem, and the user will enter the answer in the text field provided. If the computation of both random numbers will be equal to the answer the user submits then a message congratulating the user will be displayed. Otherwise a ‘wrong’ message will be displayed. A user has 5 chances. After 5 times his/her name will be stored in memory.
The Multiplication Activity (Figure 12), will make use of the Canvas. A method to generate a random number from one to six will be called. Two PNG images showing a dice each will be displayed according to the number generated. A correct answer, together with other random numbers will also be displayed providing the user a multiple choice. Since Canvas does now allow for a text field or high-level components, the Game API will be used, allowing a user to use the keypad.
If the key pressed is equal to the correct number a message congratulating user will be displayed. Otherwise a message stating that it is wrong will be displayed.
‘Guess the shape activity’ (Figure 13) will follow the same principle. A random number will be generated, and a shape will be displayed on canvas according to that number. A user will be asked to choose from the multiple choice of shapes which is the correct answer.
Besides of these activities, other enhancements will also be added. Some of these additions require an analysis of the hand-held device. An SVG form for example is proposed in the beginning of the addition/subtraction activity. Yet, SVG would not be supported on all mobile phones. The same thing would apply for an SVG menu.
Notes about solid shapes, displayed on a Form, may be added to the shape activity. Form, however, depends much on screen size of each device.
Another difficulty might be with portability, when moving the source files – the Java classes including the MIDlet – from one toolkit to a newer one, e.g. a project to be packaged with Sun Java Wireless toolkit to another system having Java ME.
Despite these drawbacks, good planning and follow basic software engineering guidelines helps a lot to complete the project as it should be. After the following diagrammatic representations, classes including required methods, should be created first. The MIDlet should take the least time to be completed and may be adapted to different SDKs.
Besides diagrammatic representations, drawings to show the user interface also help both the developer in his/her work and the client. An image using Adobe Photoshop was created to show the initial feel of the SVG menu. Adobe photo shop is widely used for the client side like WebPages.
Similarly the shapes of the GuessShape were sketched and saved as PNG.
The design of the scrolling text is a bit more complex. A careful design enables a developer to determine the size of the box where text can be scrolled, the padding and borders.
innerwidth = (length – 2 * border – 2 * padding – scrollbarWidth);
innerheight = (breadth – 2 * border – 2 * padding);
Before coding, class diagrams help determine the classes and their attributes and operations. Though platform independent, the class diagram gives an approximate idea of the methods used and how the application is going be. Class diagrams are also called static diagrams.
A class to generate random numbers, GenNum (see Fig 19) is very important and common to the Multiplication and Shapes Activity. It can also be used by the addition/subtraction unless it does not call another random generation method. Due to these multiple interfaces, an Inteface (see Fig 20) might be required. The use of Interface is used in Java RMI. The Midlet simply calls the Interface.
Interface can also be used to avoid inheritance and abstract classes.
Multiplication Canvas (Figure 21) consists of four methods. Paint() will consist of the drawings including text to be displayed on canvas. Repaint () simply tells the Canvas to draw itself. Infact everything will be displayed again. keyPressed() and getGameAction() will enable the user to use keystrokes to choose correct answer and press FIRE to repaint.
ShapesCanvas (Figure 22) and ScrollMethodsCanvas (Figure 23) have the same methods typical in all canvas classes.
The whole project will be implemented as in Figure 24. The dependences between classes is very important, both for the menu actions and also for the Interface used in the number generation.
