Cep Terminals GSM/GPRS TERMINAL CT63 JAVA 6203 User Manual

Product codes
6203
Page of 109
Java User’s Guide
6 MIDlets
42
wm_java_usersguide_v19
Page 40 of 109
2012-01-27
Confidential / Released
6
MIDlets
The Java ME
TM 
Mobile Information Device Profile (MIDP) provides a targeted Java API for writ-
ing wireless applications. The MIDP runs on top of the Connected Limited Device Configuration 
(CLDC), which in turn, runs on top of the Java ME
TM
. MIDP applications are referred to as MID-
lets. MIDlets are controlled by the mobile device implementation that supports the CLDC and 
MIDP. Since IMP-NG is a subset of MIDP 2.0, IMP includes MIDlets. The MIDlet code structure 
is very similar to applet code. There is no main method and MIDlets always extend from the 
MIDlet class. The MIDlet class in the MIDlet package provides methods to manage a MIDlet’s 
life cycle.
6.1
MIDlet Documentation
MIDP and MIDlet documentation can be found at 
 and in the 
html document directory of the wtk, 
…\Cinterion\CMTK\<productname>\wtk\doc\index.html
6.2
MIDlet Life Cycle
The MIDlet life cycle defines the protocol between a MIDlet and its environment through a sim-
ple well-defined state machine, a concise definition of the MIDlet’s states and APIs to signal 
changes between the states. A MIDlet has three valid states:
Paused – The MIDlet is initialised and is quiescent. It should not be holding or using any
shared resources. 
Active – The MIDlet is functioning normally.
Destroyed – The MIDlet has released all of its resources and terminated. This state is only
entered once.
State changes are controlled by the MIDlet interface, which supports the following methods:
pauseApp() – the MIDlet should release any temporary resources and become passive.
startApp() – the MIDlet starts its execution, needed resources can be acquired here or in
the MIDlet constructor.
Note: Take care that the startApp() method is always properly terminated before calling the
destroyApp() method. For example, avoid that threads launched by startApp() enter a
closed loop, and be sure that all code was entirely executed. This is especially important
for OTAP, which needs to call destroyApp().
destroyApp() – the MIDlet should save any state and release all resources
Note: To destroy only the Java application without switching off the module, the destroy-
App() method can be called explicitly. To destroy the Java application and switch off the
module at the same time, it is sufficient to send the AT^SMSO command from somewhere
in your code, because this procedure implies calling the destroyApp() method. Likewise,
resetting the module with AT+CFUN=x,1 also implies calling the destroyApp() method.
Note that AT+CFUN=x,1 will restart the module – to restart Java afterwards either use the
autostart mode configured with AT^SCFG or restart Java with AT^SJRA. 
From this you can see that the commands AT^SMSO and AT+CFUN=x,1 should never be
sent within the destroyApp() method. It is good practice to always call the notifyDestroyed()
method at the end of your destroyApp method. And use the destroyApp method as single
exit point of your midlet.