Menu
What options are available for handling text input on Android using Adobe AIR? What are the advantages and drawbacks to each option?
524
The current options available to AIR developers on Android for handling text input are:
I'll discuss some of the advantages and drawbacks of each approach below. If I've missed anything (or if you have other ideas that I haven't thought about) please let me know!
Yes
No
By default, TextInputs running on mobile devices make use of StageText (native text) for input. StageText offers several advantages, as Adobe outlines in their online documentation, including auto-correct, customization of software keyboards, etc.
The biggest disadvantage to using StageText is described in bugbase ticket 3302441. StageText's positioning becomes broken when a user scrolls. Textfields appear outside of their respective TextInputs or, even worse, inside of other TextInputs. The only work-around for this defect is to design a UI that does not allow scrolling. Obviously this can be very difficult for mobile phones and phablets.
Yes
No
This component uses StyleableTextField internally. It is optimized for mobile use.
This component inserts additional, arbitrary characters into the TextInput as a user is typing on certain Android versions (ex. Nook running Android 2.3, Kindle HD running Android 4.0). See bugbase ticket 3547601.
If your application is only localized into English (or latin-based languages) and does not need to support older Android versions then this component may work well for you.
No
Yes
This component uses RichEditableText internally. It is not optimized for mobile use. Beyond that it demonstrates several defects (listed above) that make it unsuitable for use.
This component does not properly handle certain double-byte characters (in languages such as Korean). These characters seem to be inserted into the TextInput (the cursor progresses, visibly) but no text is rendered to the user. (It is possible that this issue could be resolved using an embedded font.) See bugbase ticket 3547591.
While testing the 3rd item mentioned above (input not being accepted on certain devices) an interesting thing was observed. After typing a couple of characters, if a user switches focus to a TextInput that uses the default StageText, at least some of the missing characters will be automatically inserted into the new field.
Yes
No
This approach combines the benefits of StageText with the scrolling functionality of TextInputSkin (spark.skins.mobile). The general idea is to create 1 TextInput that uses StageText and assign it to a fixed location on the screen. This TextInput should be hidden by default. Other TextInputs (using TextInputSkin) can be created and positioned as needed on the stage. When one of these TextInputs gains focus, the hidden surrogate TextInput should be shown and focus should be shifted to it. As text is entered into the surrogate, a change-handler should copy the text to the user-selected TextInput. When the user tabs or clicks to set focus elsewhere the surrogate TextInput should be hidden again.
I can provide a code example of this if desired. There are a couple of drawbacks to this approach (mentioned above) but it's possible that they are the fault of my implementation.
Yes/No
<renderMode> and <fullscreen> this component may work properly for you. Yes
This approach involves displaying a simple HTML page inside of your AIR application using StageWebView. The HTML page contains <input type="text"> objects which make use of Android's native text and software keyboard. Communicating between the HTML page and the parent AIR app though is a bit tricky, since StageWebView does not support Flash-to-JavaScript communication in the same was as ExternalInterface.
Communicating from JavaScript (or HTML) to ActionScript is difficult because StageWebView does not allow ActionScript to add callbacks. StageWebViewBridge offers this functionality has not been updated in some time and when I tried it, I was unable to get content to display using Flex 4.6 and AIR 3.5.
There are still ways to convey information to ActionScript using LocationChangeEvent. The idea behind this is for the AIR app to listen to location changing events and then parse the incoming event.location for information. For simple links this works easily but things get more complicated when it comes to forms. I tried the following approaches before settling on one:
Add an onclick handler to the form-submit button that sets window.location.href to a string containing URL-encoded key/value pairs. This approach does not work for reasons described in bugbase ticket 3362483. Add an onclick handler to the form-submit button that dynamically modifies the form-target to contain URL-encoded key/value pairs and then submits the form. This approach does not work because LocationChangeEvents are not dispatched when form.submit() is called. Add onchange handlers to <input type="text"> tags and modify the href attribute of a "submit" link to contain URL-encoded key/value pairs. When this link is clicked, your ActionScript LocationChangeEvent handler will be invoked and you can parse the incoming data using the URLVariables class.To communicate with JavaScript (call methods, pass parameters) use the StageWebView's loadURL method like this:
_stageWebView.loadURL( 'javascript:yourMethodName( "A string", true )' );
Unfortunately the loadURL method has a void return type (meaning that you can't retrieve data this way).
The biggest drawback to this approach is described in bugbase ticket 3535948. If your AIR application uses <renderMode>direct</renderMode> or <fullscreen>true</fullscreen> then text input via StageWebView will be unusable. (Response will be sluggish. Users will be unable to select or delete characters.) If your app does not require either of those flags then this route may work well for you.
One workaround for the fullscreen limitation is to disable fullscreen mode only when your application needs to make use of a StageWebView. This can be done with StageDisplayState like this:
// Turn off fullscreen
stage.displayState = StageDisplayState.NORMAL;
// Turn on fullscreen
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
The last remaining option (that I'm aware of) is to write a native extension that displays text-inputs and returns data to your AIR application. This is probably the safest (although most disappointing) option of the ones discussed in this thread.
79
We might have a solution that works atleast for our scenarios : http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
