1

tamerunΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 3 μήνες)

344 εμφανίσεις

SA0942A Mobile Game Programming


1
/
6

lecture
2

2
.
All about
Midlets
.



At the end of this lecture a student will be able to:



Discuss the MIDLET Lifecycle



Outline the
development
process of MIDlet creation




1
.
Introduction
.

In the previous lecture we looked at MIDP and CLDC. The latter is a specifica
tion
of the devices that the application is to run on and the former is a library of
routines that allow J2ME applications to run on micro devices.
The next step is to
look at the MIDlet, the actual object into which we must force our application to
allow
it to run within a MID
P environment on a suitable CLDC

device. You will
not
e

that when your develop your program, set up the project in Netbeans, you
must specify the version of both MIDP and CLDC that you are targeting.


In this lectur
e we will look at th
e lifecycl
e of the MIDlet and how this interacts
with the
Application Manager that runs inside the device. We will then go onto
look at the architecture of the MIDlet, and the associated files needed to run a
MIDlet on a real phone. But first we will look
at the application manager running
inside

a mobile phone.


2. Application Manager.

Whe
n

you look at the specification of a Nokia Series 40 phone it claims to have
the Nokia OS running; the series 60 phones have Symbian operating systems
running. Neither of

these operating systems are complex or sophisticated; they
are the bare bones of an operating system. However all mobile devices capable of
running J2ME applications
must
have an Application Manager (AM). The task of
the AM

is to manage the applications

o
r processes

within the device, decide which
process

is to be run, swap
processes

and allocate resources. So for example the
AM

will load a game when requested, will interrupt and pause the game when a
telephone call comes in, will load the telephone applic
ation and when this has
finished reload the game from the position it was paused. Thus the
AM

has

inbuilt

the concept of applications

or processes

that it can start, pause or destroy
according to some preset rules. Indeed the
AM

is a cut down scheduler for

the
mobile phone.


The MIDlet is the mobile program and hence this must interact with the
application manager. You will see that the architecture of the MIDlet mirrors the
behaviour of the application manager.



3
. MIDP Applications


MIDlets.

A Java prog
ram for a Mobile Information Device is called a MIDlet.
Below is the
basic structure of an empty MIDlet.


public class lifeCycle extends MIDlet {


public lifecycle() { }


public void startApp() {


}


public void pauseApp() {


}


public
void destroyApp(boolean unconditional) {


}

}

SA0942A Mobile Game Programming


2
/
6

lecture
2

There are 3 methods that must be implemented by the developer
, plus the
constructor method
. These methods are used by the Application manager to
change the state of the MIDlet. The diagram below indicates t
he different states
occupied by the MIDlet.




The
AM

is responsible for managing the applications on the phone and when it
needs to change the state of the J2ME applicatio
n it calls one of three methods
plus the constructor met
hod.


lifecycle()

Constructor method called only once when the MIDLet is
created.

startApp()

Called whenever the application is started or restarted. Note
that when the application is initially started the
constructor
method is called then startApp(). Whe
n the application is re
-
started only the startApp() method is called.

pauseApp()

This is called when the AM

needs to pause the
application

in
order to run another application.
Basically the programmer will
aim to store the state of the application.

destr
oyApp(true)

This is called when the AM needs to terminate the application.
Used to tidy up variables etc. prior to termination.


In addition to these routines the develope
r

may force a change in state in their
application by notifying the AM that a change

in state is required


notifiyDestroyed()

This is called by the developer to inform the AM t
hat the
game is finished. The AM

in turn then calls destroyApp(true)
in the application.

notifyPaused()

This can be used to inform the AM that the game is to be
pa
used.

resumeRequest()

Call this method to inform the AM that the MIDlet is to start
again.






Startup

Paused

Running

Shutdown

pauseApp()

startApp()

destroyApp(true)

lifeCycle()

SA0942A Mobile Game Programming


3
/
6

lecture
2





4
.
Example
.


/*


* DateTimeApp.java


*


* Created on 23 August 2007, 15:39


*/


import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

im
port java.util.Date;

/**


*


* @author g510572


* @version


*/



public class DateTimeApp extends MIDlet implements CommandListener {



private Command exitCommand = new Command("Exit", Command.EXIT, 99);


private Form form ;


private StringItem s
tring ;



public DateTimeApp() {


form = new Form("Date and Time") ;


String date = new Date().toString();


string = new StringItem("Current date and time : ", date) ;


form.append(string) ;


form.addCommand(exitCommand) ;


form.setComma
ndListener(this) ;


}



public void startApp() {


Display display = Display.getDisplay(this) ;


display.setCurrent(form) ;


}



public void pauseApp() {


}



public void destroyApp(boolean unconditional) {


}




public void commandActi
on(Command c, Displayable s) {


if(c == exitCommand) {


destroyApp(false);


notifyDestroyed();


}


}


}



This example
shows the date and time on the screen as
part of a from
.
Many of
the
defaults have been kept to keep this program simple.





The constructor created the new
form that includes the string to be
displayed



startApp does the task of displaying the alert



pauseApp is blank



destroyApp is blank

SA0942A Mobile Game Programming


4
/
6

lecture
2

Think of a MIDlet as you would an Applet or a Servlet. It is a container already
available

for you as a programmer and you are required to extend the
functionality of the empty MIDlet. The abstract class MIDlet provides a lot of basic
function
ality but does not do anything.



5
.
Understanding the process of Midlet Creation.
.

We now will consid
er the whole process of Midlet creation from design to
deploying the MIDet on the phone.
There are at least 7 stages between the initial
design of the
MIDlet namely:



Design



Code



Compile



Pre
-
Verify



Packge



Test



Deploy


5.1 Design.

A MIDlet is no different to

any other program in that the application needs to be
designed. How is the user to interact with he application? How are the objects
linked? Standard design tols can be used to develop the application.


5.2 Code.

The next stage is to take the design and w
rite the code. There is no need to
design the whole system then write the code. It is probably best to develop from
a high level architecture, the
n add the

low level bits one at a time so you can be
certain that the program works. The code is typed into th
e computer using some
IDE. You can use Notepad

but NetBeans is more efficient and recommended.


5.3 Compile.

Press the button in NetBeans and the code is compiled. This stage takes the .java
files and creates .class files. This is the stage you will be fam
iliar with.

We use the
ssmae Java compiler but different options because of the target at the KVM with
CLDC1.1 and MIDP2.

In a standard application the class file will be executed on
the JVM. However in a J2ME application the class file needs some work to
get it in
a suitable state to execute on the
phone.


5.4 PreVerify.

As a minimum the class file needs to be verified. Verification of the code is a step
performed by the JVM before it runs a class file to ensure the class file is
structurally and conceptu
ally correct. If this fails the JVM generates and error and
shuts down. On a CLDC machine the verification phase cannot be run at load time
by the JVM. There are insufficient resources. Hence the pre
-
verification. At this
stage the class file is verified o
ffline to ensure that the class file loaded will have
no verification errors.


There are two additional stages that NetBeans can perform here. The first is
obfuscation. The compiled class file contains a lot of information that may not be
needed in the ru
n code. It contains full variable and method names. So for
example we may use a long method call that is meaningful to us, moveCharacter
ToRight(). As a good programmer you have been taught to use meaningful
names. However these names are of no consequence

to the JVM and long names
occupy space. The obfuscation phase gets ri
d of these names and replaces them

with short names a().


SA0942A Mobile Game Programming


5
/
6

lecture
2

Pre
-
processing is a method of commenting you
r

code with commands. These are
ignored by the compiler but
are

executed by the pre
-
processor. Thus you can
add
or remove code for different devices
,

or for debug or normal mode. The operation
of the pre
-
processor is outside the scope of this course. Netbeans supports an
ANT script to give pre
-
processing commands.


Only after that is the

code pre
-
verified and ready for the JVM.


5.5 Package.

The program is now packaged up for distribution to the device. The diagram
below shows how the program is packaged.




The manifest file d
escribes the contents of the JAR f
ile

(
Java Archive

File)
. There
are several attributes in the manifest file.
You can develop the manifest file
manually through Notepad but t
his file is created automatically by Netbeans. You
should

examine the contents.


The JAR file contains all the cla
sses and other resources required to run the
program.


As a separate
entity you also need a JAD file

(
Java Application Descriptor
)
. The
contents of this look similar to the manifest file. It does include some vital
information such as the size, MIDP and C
LDC standards used. This JAD file will be
used for deployment, see later.


5.6. Test

J2ME applications need to be tested as all programs. However
the testing of a
J2ME application is not as simple as that for a PC based program. If a PC based
program works

on one PC there is a fair bet it works in a similar way on another.
This is not true for mobile phones. The application needs to be tested on different
devices. Additionally the application will work differently on different devices due
to the different m
anufacturer implement
ation of

MIDP
.
Remember the standards
only state that the facilities must be available, they do not specify the exact way
they must be implemented.


JAR File

MID
let

1

p
re
-
verified

classes

o
ther
re
sources

Manifest file

M
ID
let 2

p
re
-
v
e
rified
classes

o
ther
resources

JAD fil
e

SA0942A Mobile Game Programming


6
/
6

lecture
2

Testing
involves

using an emulator. Start with the defau
l
t colour emulator

to see
if y
our program is working. Once you achieve this you can start worrying about
different phone models. Most of the major manufacturers provide emulators for
their phones. If the emulator is written well it will
faithfully
emu
late the operation
of the phone. On

this module we will focus only on one model of phone the Nokia
6230i. So step 2 of testing is to test the code working on the Nokia 6230i
emulator.


Over the past few years Nokia have started to standardise their phones on a
limited number of “series”. Al
l Nokia “series 40” are designed to run the same. So
once you have your application working on the Nokia 6230i emulator, it should
work the same way on any Nokia “series 40” phone. This cuts down the testing.


The final step is to deploy the game onto the

real phone and see it working. It is
this final step where the developer sees the deficiencies in the manufacturers’
emulators. To be fair to Nokia, their emulator seems to mirror the phone exactly.



5.7 Deployment.

There are two ways to deploy the appli
cation onto the phone. One way is to
connect the phone to your PC locally via either Bluetooth, IR or a cable.
Then to
transfer the application using some software such as Nokia PC Suite.



The second way to deploy an

application is over the air
. You will
need to load the
J
AR

and JAD onto a web server. Then using the mobile Internet point the phone
at the JAD file. The phone downloads this file, reads the file and if the phone can
support the application as described in the JAD file it downloads the JAR and

puts
the files in the correct place. The application will now be available within the
applications of your phone.


Whilst the first method is useful for you when testing it is of no use for making
money. To make money you must have the game on the Interne
t and get people
to download the game. We will come back to this later.