29 Oct 2010

Qwerty and data input in J2ME

When developing mobile applications (including games), there are two ways to allow data input from users. The first is to use the native J2ME data input api like TextField or TextBox.

1
2
TextField text = new TextField("Enter amount:", "", 8, TextField.DECIMAL);
<p>

This calls the phone's native data input mode that allows easy text entering and formatting for the user.

The second method is developing a pseudo data input layer yourself. It involves listening to keypad inputs, using these inputs to construct the data string and display these (mostly in a drawn box) to the user on the fly. And building this, is a very complex thing. Normally, developers are advised to stick to using the native api. While it makes their work easier, it also makes data entering and formatting (copy, paste, etc) easier to the users.

You may however be tempted to ask why some developers build and mobile applications have their own data input model. Why may you even want to consider this option for your application? A lot. Personally, building an autocomplete for the user is the top reason I ever gave it a shot. Autocomplete shows the user similar/related input to their entry as they type. This is however not possible when you use the native data input api. One, because you can't get what the user is typing until he/she is done and clicks Ok and two, because the data input screen takes over the whole screen and covers you own gui.

That said, people design their custom data input layer in different ways. I have not been lucky to get the full source code of any sample application (Mehn, I'd love to know how Opera Mini pull this stunt. Their inline editing rocks). Or maybe it is that I've not really looked around that much. Which ways, the first approach to developing your own data input model is knowing what keys the user pressed as the keys are read in as numerical codes in J2ME. For standard numerical keypads, it is a piece of cake as the canvas api provides them already as KEY_NUM0, KEY_NUM1, KEY_NUM2, KEY_NUM3, KEY_NUM4, KEY_NUM5, KEY_NUM6, KEY_NUM7, KEY_NUM8, KEY_NUM9, KEY_STAR, and KEY_POUND. The main problem is with qwerty keypads. To help me with discovering the the key code for qwerty keyboards, I wrote a simple java mobile application to help with. Called keyMapper, the application simply detects and outputs the code and name of the pressed key.

Download the application and source code

 

Looking for a simple marketing automation tool to automate your customer onboarding, retention and lifecycle emails? Check out Engage and signup for free.

 

My name is Opeyemi Obembe. I build things for web and mobile and write about my experiments. Follow me on Twitter–@kehers.

 

Next post: LBS - discovering location with cellid