I often end up using a program called Yudit, a Unicode editor written by Gáspár Sinai, even on a system that has native integrated support for multiple input methods, because it’s available on a wide range of systems and I’m familiar with the input methods bundled with it. For example, even though the same input method is supposedly available on both Microsoft Windows and through SCIM, there may be slight differences in the keyboard layouts that can result in typos if one is not careful.

It seems that the majority of wireless handheld devices ship with only one input method. Yudit does not appear to run on any of the major mobile operating systems, but it would be overkill anyway, since people aren’t likely to want to edit entire Unicode documents on their cell phones. On the other hand, it would be useful to be able to switch input methods, even if only to type a few words into an e-mail, or to look something up in an online dictionary.

In adapting input methods designed for personal computers to cellphones, one immediately runs into the problem that what would have been a single keystroke on a full-sized keyboard becomes a key combination or a series of taps on a keypad. With the predictive text systems used on some cellphones, one also runs into the problem of textonyms.

I wanted to see if I could port some of Yudit’s input methods to a mobile environment, so I ignored these problems for the moment and assumed, for the sake of simplicity, that the device had a full-sized keyboard. I also decided to write a Java MIDlet, because these can be run on a number of different mobile platforms. (Yudit itself is written in C++.)

Even this simplified version of the problem turned out not to be so easy. I tried using the TextField and TextBox classes in the javax.microedition.lcdui package, and while I was able to capture the user’s input and replace it with the appropriate Unicode, neither class handled bidirectional text very well.

I tried mixing the Chinese-CJ (Cangjie), Devanagari, and Farsi input methods (used for entering Chinese, Hindi, and Persian text, respectively), and the result was that my little program became very confused. On some emulated devices, the left and right arrow keys would move the cursor left and right, respectively, while within the Persian text; but on others, the effects of these keys were reversed, as were the effects of the backspace and delete keys.

It would probably take a lot more work to get any of these input methods working properly, but this was only a first attempt, which I wanted to document in case anyone else wanted to try something similar. Also, it’s possible that I would have been more successful if I had used UI libraries specific to a company or manufacturer, such as RIM’s net.rim.device.api.ui package, rather than the generic (and hence not as powerful) javax.microedition.lcdui package.

I’ve included several screenshots of what my little experiment looks like when run on Sun’s Java ME SDK mobile emulator with a generic device, as well as on RIM’s BlackBerry emulator with two different devices. The Devanagari did not render at all on the emulated BlackBerry devices. There were also some small layout problems, which I didn’t fix since this was only supposed to be a quick experiment.

Screenshots of experiment on Sun’s generic emulated mobile phone:

Screenshots of experiment on RIM’s emulated BlackBerry Curve 8300:

Screenshots of experiment on RIM’s emulated BlackBerry Tour 9630:

Considering the size of the mobile device markets in China, India, and the Middle East, getting different input methods to work in a mobile environment is an important (and potentially financially rewarding) problem to tackle.

– davinci

No related posts.