Some Spark text controls have been optimized for use in
mobile applications. When possible, use the following text controls:
The text controls that allow user interaction (TextArea and TextInput)
use the StageText class as the underlying
input mechanism. StageText hooks into the native text controls of
the underlying OS. As a result, these text controls behave like
native controls rather than typical Flex controls.
The benefits of using StageText include the following on devices
that support them:
Native performance and look and feel
of the soft keyboard
Auto-completion
Auto-correction
Touch-based text selection
Customizable soft keyboards
Key restrictions
Adobe evangelist Christian Cantrell describes the advantages and disadvantages of
using StageText-based controls.
TextField-based
versions of the TextArea and TextInput control are also available. You
can use these versions to embed fonts or use some other functionality
that is not available on the StageText-based versions.
Skins for mobile text controls
When you create a mobile application, Flex automatically applies
the mobile theme. As a result, the Spark TextInput and TextArea
controls use the following StageText-based mobile skins by default:
The StageTextAreaSkin and StageTextInputSkin classes are optimized
for mobile applications and are based on the
StageTextSkinBase class. They
act as a wrapper around the native text input classes. However,
they do not support the following features of the non-TextField-based
skins:
Supported by TextField-based controls
|
Not supported by TextField-based controls
either
|
|---|
Scrolling forms
Text measurement
Clipping
Embedded
fonts
Fractional alpha values
Flash Text Engine (FTE)
Access
to low-level keyboard events such as keyUp and keyDown
|
Text Layout Framework (TLF)
Bi-directionality
and mirroring
Compact Font Format (CFF)
RichEditableText
for text rendering
HTML text
|
Some of these limitations can be worked around by using the TextField-based versions.
To use the TextField-based versions of the text input controls,
point their skin classes to the TextField versions,
TextInputSkin and
TextAreaSkin;
for example:
<s:TextInput skinClass="spark.skins.mobile.TextInputSkin" text="TextField-based Skin"/>
The Spark Label control does not use a skin, but also does not
use TLF.
TLF in a mobile application
In general, avoid text controls that use Text Layout Framework
(TLF) in mobile applications. The mobile skins of the TextArea and
TextInput controls are optimized for mobile applications and do
not use TLF as their desktop and web-based counterparts do. TLF
is used in applications for providing a rich set of controls over
text rendering.
Avoid the following text controls in a mobile application, because
they use TLF and their skins are not optimized for mobile applications:
Input with soft keyboards
When a user places the focus on a text control that takes input,
mobile devices without keyboards display a soft keyboard. You have
some control over the available keys and other properties of the
soft keyboard. For example, you can enable auto-correction and auto-capitalization,
and you can select among several predetermined keyboard layouts.
For more information, see Use the soft keyboard in a mobile application.
Scrolling with text input controls
The default mobile skins for the TextInput and TextArea controls
do not support scrolling forms. In other words, you cannot display
these controls in forms or views that require the control to scroll.
If you do, visual artifacts appear that are a result of the way
the controls are implemented.
To use text input controls in a scrolling container, use the TextField-based
skins rather than the StageText-based skins. For more information,
see Scrolling considerations with StageText.
Transitions with text input controls
To animate smoothly, the runtime replace StageText controls with
bitmaps captured from them whenever an animation plays. This can
cause a slight delay at the beginning of transition animations and
can also cause some visual artifacts at the beginning and the end
of the animations.
The slight delay is the time taken to capture bitmap representations
of the text in the components. This delay increases as the area
and number of StageText-based controls increases. To reduce the
delay, avoid animating large or numerous StageText-based components.
Popups with text input controls
StageText-based text inputs outside of the topmost popup are
replaced with bitmap representations when a popup appears. As a
result:
Use modal popups rather than non-modal popups.
When a modal popup is shown, components outside of the popup are
expected to lose their interactivity. In these cases, the replacement
of StageTexts with bitmaps is less noticeable.
StageText-based components should only be used inside popups
that implement the IFocusManagerContainer interface. For example,
use SkinnableContainer or one of its derivatives as the basis for
popups.
Use a Callout container when text
components in lower layers should remain active. If a text component
owns a callout, the text component remains active and sets the callout’s
arrow to point to that text component. This is a natural cue to
the user that the text component can still be used.
Avoid using multiple popups simultaneously. When more than
one popup is visible at one time, only the topmost popup is interactive.
If popups do not overlap, however, users will not be able to determine
which popup is topmost.
When non-modal popups overlap text controls, position the
popup so that the overlap is near-total. If the user cannot see
the text, they will be less likely to assume that the text control
should still be interactive.
Embed fonts in a mobile application
You cannot use embedded fonts in a text input control that uses
StageText. Instead, use the TextField-based skins for the text input
controls. You also cannot use the Label control with embedded fonts
because it uses FTE, which requires CFF-based fonts. CFF fonts do
not perform well in mobile applications.
For more information, see Embed fonts in a mobile application.
StageText control class hierarchy
The StageText classes (TextInput and TextArea) have a complex
class hierarchy. The base classes themselves have the following
hierarchy:
UIComponent
|
SkinnableComponent
|
SkinnableTextBase
|
TextInput/TextArea
As with all Spark classes, the skin classes have their own hierarchy:
UIComponent
|
MobileSkin StyleableStageText
| |
StageTextSkinBase: textDisplay
|
StageTextInputSkin/StageTextAreaSkin
In the base skin class, the textDisplay property
provides the hook to the native text input as a StyleableStageText object.
This class is also responsible for defining which styles are available
on the StageText-based text input controls.
