J2ME MIDP 2.0 - A world away from the J2SE world

I have been working on J2ME (Java 2 Micro Edition), particularly MIDP 2.0 (Mobile Information Device Profile) for the last 3 months or so. We have been exploring this profile to develop a POC application that will run on MIDP 2.0 enabled cell phones. Coming from a J2SE background, where we don't really think much about memory and where UI capabilities are assumed to be good, I many times found myself saying.. "What? You cannot even do this? How am I supposed to construct a good-looking UI application then?".

Some obvious things I expected but did not find support for that in MIDP:

1. No file support by default: By default the MIDP 2.0 does not provide you with file IO APIs. So that means you cannot write to / read from files. There is a separate JSR 75, called File Connection Optional Package that provides APIs for accessing file systems on a device.

2. No nesting of panel / container components: In J2ME MIDP 2.0 user interface API, there can be only one outermost container component. This can be a Form, a List or a TextBox. It is not possible to create a container or a panel with child componentns and include that panel as a child of the Form. I found this very restrictive when it comes to building complex, good looking UI screens.

3. Very limited Layout support: Forget all the fancy GridLayout, FlowLayout and GridBagLayouts here! All you can specify is that I want a new line after a component or before a component and that I want all the 3 text fields to appear on one row. And that too, I observed is not necessarily the effect you will get in the end. It all depends on the screen size and the KVM implementation on the device I guess.

4. Key pressed events for characters: Don't you expect that if MIDP 2.0 does provide you with a KeyListener and does generate a keyPressed event, that it should generate these events for character keys as well? Well - you can, but in the case of MIDP 2.0 and cell phone world - it is too much to expect. The reason is that, the keycodes generated for the character keys are / can be different on different cell phones. That is why, MIDP 2.0 as a standard, does not mandate generation of key events for the character keys. Standard key codes and event generation can be assumed only for digits: 0 to 9 and some other keys like # and *.

We were trying to develop a custom text field component and therefore wanted to catch the events for character keys. One of the ways I got to know from someone to implement it, is to have a timer task, set a particular time interval, and map consecutive key presses to characters. For example: If digit 2 is pressed thrice in quick succession, interpret it as 3. Find this a very crude way of doing it and obviously restricts my code to a English key pad.

5. Standard components do not let me set the foreground and background colors: All I wanted was to have a different background color for a label component. I had to develop a custom label component just for that so that I could set the desired background and foreground colors.

The purpose of this blog is not to point out only the negatives or the limitations, the point I am trying to make here is only the absence of some of the things we take for granted in the PC world!