Kevin Hoyt

If you've developed with Flash Lite 1.1, then you know that inline text support isn't really supported. In its place, you have to open the device's text input mechanism. I've personally found this far too constraining for a number of reasons. First and foremost, it's the device's input mechanism (smile)! I want my application to have the feel of my application. Secondly is that in order to use the device text input, you must adhere to the focus mechanisms provided by Flash Lite and by that device. Quite frankly, if I can intercept directional events, I want to say where the focus will go next.

Then it occurred to me that if I can control where the focus is displaying, then I can certainly emulate text input by listening to the keypad events.

I started off implementing this to be as modular as possible such that I (or you) could easily reuse the "component" in other Flash Lite applications. I use a pixel font in my applications, and as such, my first step was simply to measure the characters that I was going to allow. Once I had the values, I hard-coded them into the component. When a character is entered, I know its width and can position a blinking cursor respectively.

This is an obvious limitation of the implementation, but the string of measurements can be easily changed for your own needs. However, you could do away with measuring altogether if you decided that you didn't want to present a highlighting or cursor mechanism. Is that poor UI design? Perhaps it is, but for the added flexibility, it might be perfect in some situations.

After being able to successfully append characters, and measure the presented value, I need to allow for characters that weren't the first on the button (e.g. "a" for the key-press of "2").

Following the convention of most mobile phones, I decided that I'd wait about a second before moving on to the next character. Since my application was running at twelve frames per second, it was relatively easy to setup a movie-clip timer. Before appending the newly entered character, I check the timer to see if it has returned to the first frame. If the timer is one the first frame, then I append the new value, and if the timer is somewhere in-between, I cycle through a range of possibilities.

Because I wanted to maximize reuse and modularity, I had to generalize the code. Abstracting the code to allow for various ranges forces a certain degree of complexity however, I’m certain that it’s still pretty readable. I've added a few subtleties such as checking to see if the character is first or follows a space, and then present case accordingly. The one thing I haven’t added is watching for a change in which key is being pressed, should the key-press occur before the timer is reset. This should be pretty minor to add however, I wanted to get this out as my last post as a Macromedia employee.

You can download the source and play around with it yourself, note however that I’ve not tested this on a phone as I *still* don’t have a phone that supports Flash Lite. If you do test it, and it works, I'd love to hear from you. Following is a Captivate recording of a sample application I built around the inline text component. It's got a little tongue-in-cheek humor given the recent announcements. The application also has a little Easter egg for your enjoyment (smile).