Current options available to AIR for Android developers for text input processing:
- StageText native text (default)
- TextInputSkin (spark.skins.mobile)
- TextInputSkin (spark.skins.spark)
- StageText + TextInputSkin (spark.skins.mobile) hybrid
- StageWebView (explained below)
- Native view
I will talk about some of the advantages and disadvantages of each approach below. If I missed something (or if you have other ideas that I did not think about), please let me know!
Stagetext
- Does input handle correctly in all cases?
Yes - Is it displayed correctly in all cases?
No- Problems with vertical alignment when scrolling.
By default, TextInputs running on mobile devices use StageText (native text) for input. StageText offers several benefits that Adobe highlights in its online documentation , including auto-correction, customization of soft keyboards, etc.
The biggest drawback to using StageText is described in bug database ticket 3302441 . StageText positioning is broken when the user scrolls. Text fields appear outside their respective TextInputs or, even worse, inside other TextInputs. The only workaround to fix this defect is to create a user interface that does not allow scrolling. Obviously, this can be very difficult for mobile phones and phablets.
- Does input handle correctly in all cases? Yes
- Is it displayed correctly in all cases? No
- Inserts random characters into specific versions of Android (e.g. Nook running Android 2.3).
This component uses StyleableTextField for internal use. It is optimized for mobile use.
This component inserts additional arbitrary characters into TextInput when a user types on certain versions of Android (e.g. Nook running Android 2.3, Kindle HD running Android 4.0). See ticket to bug database 3547601 .
If your application is localized only in English (or Latin) and does not require support for older versions of Android, this component may suit you.
- Does input handle correctly in all cases?
No- Does not accept certain double-byte characters (e.g., Korean).
- It does not accept input on certain devices (for example, Samsung Galaxy 10.1 running Android 4.0).
- Is it displayed correctly in all cases? Yes
This component uses RichEditableText for internal use. It is not optimized for mobile use. In addition, it exhibits several defects (listed above) that make it unusable.
This component does not properly handle certain double-byte characters (in languages such as Korean). These characters seem to be inserted into TextInput (the cursor is progressing, noticeably), but the text is not displayed to the user. (It is possible that this problem can be solved with the built-in font.) See bugbase ticket 3547591 .
During testing of the third paragraph mentioned above (input is not accepted on some devices), an interesting thing was discovered. After entering a pair of characters, if the user switches focus to TextInput, which uses StageText by default, at least some of the missing characters will be automatically inserted into the new field.
StageText + TextInputSkin (spark.skins.mobile) hybrid
- Does input handle correctly in all cases? Yes
- Is it displayed correctly in all cases? No
- Sometimes the soft keyboard “shows” the animation, runs twice in a row, creating an undesirable visual effect.
- Sometimes focus processing is difficult and may cause StageText-TextInput to be displayed without a soft keyboard until the student touches it again.
This approach combines the benefits of StageText with the scroll 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 placed as needed on the scene. When one of these TextInputs receives focus, the hidden surrogate TextInput should be shown and the focus should be shifted to it. When the text is entered into the surrogate, the change handler must copy the text to the TextInput selected by the user. When the user nests or clicks to set the focus elsewhere, the surrogate TextInput should be hidden again.
I can provide sample code for this if desired. This approach has a couple of drawbacks (mentioned above), but it is possible that they are a mistake in my implementation.
- Does input handle correctly in all cases? Well no
- Depending on the value of
<renderMode> and <fullscreen> this component may work correctly for you. - It's a little hard to get a job.
- Is it displayed correctly in all cases? Yes
This approach involves displaying a simple HTML page inside an AIR application using StageWebView. The HTML page contains <input type="text"> objects that use native Android text and a soft keyboard. However, the relationship between the HTML page and the parent AIR application is a bit complicated, because StageWebView does not support Flash-JavaScript interaction, as does ExternalInterface .
Communication from JavaScript to Flash
Communication from JavaScript (or HTML) with ActionScript is difficult because StageWebView does not allow ActionScript to add callbacks. StageWebViewBridge suggests that this feature should not be updated for some time, and when I tried it, I was unable to display the content using Flex 4.6 and AIR 3.5.
There are still ways to pass information to ActionScript using LocationChangeEvent . The idea is for an AIR application to listen for location-related 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, which sets the
window.location.href string containing URL-encoded key / value pairs. This approach does not work for the reasons described in the error database ticket 3362483 . - Add an onclick handler to the form submit button, which dynamically changes the form target to contain URL-encoded key / value pairs, and then submit the form. This approach does not work, since LocationChangeEvents are not dispatched when form.submit () is called.
- Add onchange handlers to the
<input type="text"> tags and change the href attribute of the "submit" link to contain URL-encoded key / value pairs. Clicking on this link will call your ActionScript LocationChangeEvent handler, and you can parse the incoming data using the URLVariables class.
Communication from Flash to JavaScript
To interact with JavaScript (call methods, pass parameters), use the loadURL StageWebView method , for example:
_stageWebView.loadURL( 'javascript:yourMethodName( "A string", true )' );
Unfortunately, the loadURL method has a return type of void (this means that you cannot get the data this way).
Other difficulties
The biggest drawback of this approach is described in the bug application 3535948 . If your AIR application uses <renderMode>direct</renderMode> or <fullscreen>true</fullscreen> , text input through StageWebView will not be possible. (The answer will be sluggish. Users will not be able to select or delete characters.) If your application does not require any of these flags, this route may be useful to you.
One workaround to limit full-screen mode is to disable full-screen mode only when your application needs to use StageWebView. This can be done using StageDisplayState as follows:
Own view
- Does input handle correctly in all cases? Yes
- Is it displayed correctly in all cases? Yes
The last remaining option (which I know of) is to write your own extension that displays text input and returns data to your AIR application. This is perhaps the safest (albeit the most disappointing) option discussed in this thread.