iSTEP Tanzania

Programming cell phones (part 0)

Posted on: July 6, 2009

Programming for cell phones is slightly different than programming on a desktop. The limited CPU power, memory and API functionality for cell phones impose some challenges. This implies a need for more careful coding and a greater awareness of one’s resources.

The trend of programming smart mobile phones is rising and attracting considerable attention, as the ubiquitous computing aspect of mobile phones is very motivating and a lot of useful applications are now running on cell phones. The iPhone and Google Andriod are revolutionizing this computing platform. However, the most common platform is the Symbian OS, which is the interest of this blog post.

The Symbian OS was designed for mobile phones by several mobile phone manufactures and now is owned solely by Nokia. Although the future of Symbian OS with regards to the iPhone OS and Andriod is not clear, it remains the most common up to data.

The Symbian platform is primarily programmed with C++. Symbian API’s include various functions for User Interface and low level control that are not available by other means. The OS also runs Java ME (Java Micro Edition) designed for embedded devices. In addition, the platform offers other tools and utilities for rapid prototyping and developing, which include QT ( to allow very attracting eye candy Graphics User Interface (GUI) and Python (, which is a fast and easy way of developing applications as well as games.

Programming for Symbian devices using the Symbian C++ libraries has several advantages including: low level access to the device functionality, access to native libraries and hardware. For example, one can access the native TTS engine on Symbian S60 3rd edition and S90 devices from Symbian’s C++ libraries very easily. However, if the target devices are not only Symbian OS, then the programmer has to develop different programs that might be sustainably different for every different platform on which they would like to run their program on. The use of Symbian C++ is certainly great, but not easily portable to other platforms.

A solution to the portability problem is to use Java.  Jave ME ( is the Micro Edition of Java that runs a JVM on embedded devices and let bytecode run across platforms without a problem. However, there are some disadvantages of using Java on embedded devices. Apart from speed, Java ME does not allow access to native device functionality. (At least no easy way exists.) The UI components provided by the library are functional, but not attractive. The UI for a professional looking application should be replaced with something other than Java ME (e.g J2ME Polish

Despite those disadvantages, Java ME provides a good solution to the problem of figuring out how to run applications on cell phones. A large number of manufactures ship java support with their devices. Programming in Java is also easier (in terms of hidden bugs), easier to manage across large projects and is very secure. In fact, it is so secure that one can’t access anything in the device from the JVM. Code runs only in the JVM and many security warnings and OK presses are required to access simple things. Another major advantage for using Java is portability.  In the Literacy Tools projects (, portability is a very important consideration. Once the code is written it could run on a large number of cell phones without the need for changing a lot in the code. Some minor tweaks could be needed, but most of those tweaks would be related to screen size.

Programming in J2ME is not the same as programming in J2SE (Java 2 Standard Edition). In J2SE, the programmer has access to huge Java API and an even larger number of externals API’s to virtually do anything. However, J2ME is missing a lot of the familiar Java libraries. Most importantly, J2ME does not support floating point operations! Yes, that means that you cannot do 3.8 + 0.3. Moreover, J2ME does not support serialization. In Java ME this is done by the Record Management System (RMS). You can learn a lot more about the RMS here and here

The large number of missing libraries is not a surprise. Mobile phones are currently much less sophisticated than computers, but they are more likely to be very powerful faster than what we think. The limited User Interface components in javax.microedition.lcdui.* is also not surprising. The UI should be compatible with the least sophisticated device in the market. Getting a professional look and custom functionality will require developing this functionality in house, or using other libraries and frameworks.


Developing an application in J2ME is very similar to writing Java Applets (those little Java programs that run on the web browser and make the web browser hang at many situation). Similar to Applets, J2ME applications are called MIDlets. In order for a piece of code to become a MIDlet it needs to extend the super class javax.microedition.midlet.MIDlet.

MIDlet defines three functions to be implemented. Those functions are

–          protected void startApp() throws MIDletStateChangeException

–          protected void pauseApp()

–          protected void destroyApp(boolean uncoditional) throws MIDletStateChangeException

These functions define the life cycle of the midlet. A very important thing to know before developing any thing is the MIDlet life cycle (

Here is my setup for this project. Java 1.5 ( Java Wireless Toolkit (WTK) 2.5 ( The Eclipse IDE 3.4 ( Eclipse ME plugin to run Java ME ( and some VIM from time to time J using the vimplugin for eclipse ( ). Installing the software and get it up and running is fairly simple. Download everything, configure EclipseME and get started.

Here is a small HelloWorld MIDlet with some comments

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class HelloWorld extends MIDlet implements CommandListener {

Command exitCmd;

TextBox textBox;

HelloWorld() {

exitCmd = new Command(“Exit”, Command.EXIT, 99);

textBox = new TextBox(“HelloBox”, “HelloWorld!”, 50, 10);



protected void startApp() throws MIDletStateChangeException {



protected void pauseApp() {


protected void destroyApp(boolean unconditional)

throws MIDletStateChangeException {


public void commandAction(Command c, Displayable d) {

if(c == exitCmd) {

try {


} catch(MIDletStateChangeException mse) { }




And here is what you should see :]

HelloWorld on the emulator

HelloWorld on the emulator

Some important things to notice:

1-      startApp is the entry point to the application. There is not public static void main(String[] args)

2-      pauseApp is the function that gets called when your program is paused. This happens when you get a phone call for example.

3-      destroyApp is the function that gets called when the application is destroyed. The garbage collector in Java ME is not great. You’ll need to explicitly set objects to null and sometimes call System.gc(); As a rule of thumb, if you know you are not using an object later on, set it explicitly to null and help that garbage collector.

4-      System.exit() function is not part of Java ME.

5-      The static Display access in startApp is very important. Each midlet has access to one display. All midlets use this one display. Whenever you need to add a different component to display you’ll need to replace the existing one with a call like Display.getDisplay(this).setCurrent(component). Creating a class field of type Display (e.g Display display; ) then initializing it in the constructor is useless, you can’t set the display in the constructor. It might save typing, but you need to be aware that the Display is to be only accessed from startApp, pauseApp, destroyApp functions.

6-  startApp function might be called several times. For example, if the application was paused then resumed, startApp will be called. You’ll need to be careful when initializing objects in this function. Otherwise, you’ll run out of heap space unexpectedly, such as if you have a class that extends a Thread. Your game thread, for instance, that runs, takes care of running the game, controlling the speed of the game and destroying it. Then you might want to do something like this in startApp.

protected void startApp() throws MIDletStateChangeException {

if(gameThread == null) {

gameThread = new GameThread(this);


} else {

// game unpaused, don’t recreate the object




Finally, the most well known tip/advice/hint that everybody always strives to do: “Code then optimize :)”. Stay tuned for more Java ME!


3 Responses to "Programming cell phones (part 0)"

[…] Read the original post: Programming cell phones (part 0) « iSTEP Tanzania […]

mobile phones that have built in cameras are my favorite because they can capture those special moments and events ;~,

Wow! This could be one particular of the most helpful blogs We have ever arrive across on this subject. Basically Great. I’m also an expert in this topic therefore I can understand your hard work.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Twitter Feed

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

July 2009
« Jun   Aug »
The opinions expressed by the bloggers are theirs alone, and do not reflect the opinions of Carnegie Mellon University, TechBridgeWorld or the iSTEP program, or any employee thereof. Carnegie Mellon University is not responsible for the accuracy of the information supplied by the bloggers.
%d bloggers like this: