The basics of Java mobile development

Developing software for a mobile device is not very different from developing software for a standard computer. The main difference lies in resources.

A normal computer, by todays standard, has such a high performance that you no longer have worry about what datatype to use in order to save memory or how to make code more efficient so that it don't need as much power to run. You can keep it quite sloppy, even if you shouldn't.

When working with smaller devices such as a cellular phone resources can still be an issue and no matter what, a cellular phone can't match a computer in performance anyway.
Because of this, when creating applications for a cellular phone you won't run the application on the normal JVM (Java Virtual Machine) but rather on the KVM (Kilobyte Virtual Machine) which has limited resources more suitable for small devices.

There are three Java 2 platforms, J2EE (Java 2 Enterprise Edition), J2SE (Java 2 Standard Edition) and J2ME (Java 2 Micro Edition). When developing software for mobile devices J2ME is required.
J2ME differs somewhat from J2EE and J2SE in that it implements a different approach to The Configuration.



While J2EE and J2EE uses CDC (Connected Device Configuration) in order to configurate the JVM core, J2ME uses a mix of CDC and CLDC (Connected Limited Device Configuration) in order to apply to both larger "small-devices" such as PDA's (with CDC) and smaller devices such as cellphones and pagers (with CLDC).
A cellphone and a pager however are quite different devices with different resources (screen size, memory etc) which is why Sun introduced the Profile concept in the J2ME. A profile is an enhancement of a configuration with unit specific libraries for the developers.
The MIDP (Mobile Information Device Profile) defines the API for user interface components, events, network connections and more for the limited device.

Creating a MIDlet

The abstract MIDlet class is a framework for the Mobile Information Device Profile (MIDP) that you inherit in order to create a cellular phone application (for example).
When inheriting the MIDlet class there are three methods that you have to implement:

startApp(): The MIDlet is told to require all resources needed and continue.
pauseApp(): The MIDlet is told to release all temporary resources and enter a passive mode.
destroyApp(): The MIDlet is told to release all resources and enter its destroy state.

Theses three methods are accompanied by already implemented methods such as:

notifyDestroyed(): Notifies the application manager that the MIDlet has entered the destroyed state.
notifyPaused(): Notifies the application that the MIDlet doesn't want to be active and has entered a state of pause.
resumeRequest(): Provides the MIDlet with a mechanism to indicate that it wants to resume. The application manager will then take the decision to start the application.

Mentioned above is the application manager. This is a sort of container that controls your application. The MIDlet you create runs inside the application manager and is bound by the rules of the application manager.



As we can see in this picture the application manager rules the MIDlet and holds all the keys. If the MIDlet wants to pause, it needs to ask the application manager. If it wants to exit, it needs to ask the application manager. If it wants to start, well, you get the point.

This means that the three methods, startApp(), pauseApp() and destroyApp() must be implemented in order to communicate with the application manager. Luckily there are, as mentioned above, more, already implemented, methods to handle the direct communication.

A basic MIDlet

This will demonstrate how a basic MIDlet looks before anything is implemented:



Following articles will show how to create basic MIDlets. Hopefully this article has shed some light on how mobile development works.