iSTEP Tanzania

Author Archive

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!


The UEFA champions league final was yesterday. It was a pretty sad moment to know that I might not watch the game especially that Barcelone is playing. However, Eric came to the rescue and offered to take us out to watch the game, no more sad moments :). We met at Chicken Hut and head to Lilly’s Garden to watch the game on a big projector.

The game was supposed to start at 21:45, we got there around 21:00 minus epsilon, but the place was already full. Actually, we can never say full \footnote{After the daladala experience nothing is ever full}. We sat there got drinks. The Bavaria 0.0% alcohol apple flavored was sooo gooood…

21:45 the game started and everybody was cheering everybody. It was awesome! This is how people cheer in a soccer match 🙂

Of course, Barcelone won the game. A lot of people, including me were very happy. Eric, on the other hand, was a Man Utd fan. He didn’t like that fact too much, but he had certainly enjoyed the game. The game was great.

One very interesting thing about watching soccer outdoors on a projector is butterflies. They are very attracted to the projector light and for a while I thought that there huge birds flying by the screens. But… Wait a minute… There are not birds at night! Those are just butterflies trying to kill themselves!

We got home by 00:00 feeling very tired, but happy for the victory. Our daily schedule have been waking up @ 7:00 to get ready to walk to work (w2w) by 8:00. But, feeling very tired we woke up today @ 8:00 and head off to our meeting with the primary school.

We walked a lot today… we still have to walk back home tonight, but walking is good. It is always good to walk. In any case, we went to the school in the morning. Got there on time and met with one of the teachers.

The teacher was very friendly, welcoming and very excited about our project. Although the meeting was by no means techy, it was very helpful and informative. The school is going to close for holidays very soon. Teachers are very busy with the final exams and getting student reports done. Nevertheless, they were happy to meet with us before their holiday starts. We are looking forward for our next meeting with the teachers, where we are going to get a better idea on the challenges they face and get started with developing a solution.

Now, monkeys! If you are following us on Twitter, you’ll know that we saw a lot of monkeys recently. Here are some pictures of the monkeys living *next door*.

Can you count the three monkeys?

Can you count the three monkeys?

Monkeys are having fun!

Monkeys are having fun!

Some monkeys dont like pictures

Some monkeys don't like pictures

Some onkeys like cameras

Some monkeys like cameras

Chillin monkey!!!

Chillin' monkey!

Brad & Dan looking for monkeys

Brad & Dan looking for monkeys

Finally, a (group picture – 1) of the team working very hard in the office

the team in the office working really hard

The team in the office working really hard

Twitter Feed

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

July 2018
« 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.