Какие опции доступны для обработки ввода текста на Android с помощью Adobe AIR?

Какие опции доступны для обработки ввода текста на Android с помощью Adobe AIR? Каковы преимущества и недостатки каждого варианта?

Текущие параметры, доступные разработчикам AIR для Android для обработки ввода текста:

  • Текст исходного текста StageText (по умолчанию)
  • TextInputSkin (spark.skins.mobile)
  • TextInputSkin (spark.skins.spark)
  • StageText + TextInputSkin (spark.skins.mobile) hybrid
  • StageWebView (объясняется ниже)
  • Собственный вид

Я обсужу некоторые из преимуществ и недостатков каждого подхода ниже. Если я что-то пропустил (или если у вас есть другие идеи, о которых я не думал), пожалуйста, дайте мне знать!


StageText

По умолчанию TextInputs, запущенные на мобильных устройствах, используют TextText (собственный текст) для ввода. StageText предлагает несколько преимуществ, поскольку Adobe очерчивает в своей онлайн-документации , включая автоматическую корректировку, настройку программных клавиатур и т. Д.

Самый большой недостаток использования StageText описан в биг-байте 3302441 . Позиционирование StageText нарушается при прокрутке пользователя. Текстовые поля появляются за пределами их соответствующих текстовых полей или, что еще хуже, внутри других TextInputs. Единственным препятствием для этого дефекта является создание пользовательского интерфейса, который не позволяет прокручивать. Очевидно, это может быть очень сложно для мобильных телефонов и phablets.


TextInputSkin (spark.skins.mobile)

Этот компонент использует встроенный стиль StyleableTextField . Он оптимизирован для использования в мобильных устройствах.

Этот компонент вставляет дополнительные, произвольные символы в TextInput, когда пользователь печатает на некоторых версиях Android (например, Nook под управлением Android 2.3, Kindle HD с Android 4.0). См. Биг-код билета 3547601 .

Если ваше приложение локализовано только на английском (или на латинских языках) и не нуждается в поддержке старых версий Android, этот компонент может работать хорошо для вас.


TextInputSkin (spark.skins.spark)

Этот компонент использует RichEditableText внутренне. Он не оптимизирован для мобильного использования. Помимо этого, он демонстрирует несколько дефектов (перечисленных выше), которые делают его непригодным для использования.

Этот компонент неправильно обрабатывает определенные двухбайтовые символы (на таких языках, как корейский). Эти символы, кажется, вставляются в TextInput (курсор прогрессирует, видимо), но текст не отображается пользователю. (Возможно, эта проблема может быть решена с использованием встроенного шрифта.) См. Биг-код билета 3547591 .

При тестировании третьего пункта, упомянутого выше (ввод не принимался на определенных устройствах), наблюдалась интересная вещь. После ввода нескольких символов, если пользователь переключит фокус на TextInput, который использует StageText по умолчанию, по крайней мере некоторые из отсутствующих символов будут автоматически вставлены в новое поле.


StageText + TextInputSkin (spark.skins.mobile) hybrid

  • Во всех случаях правильно обрабатывать входные данные? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Да
  • Отображается правильно во всех случаях? http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png Нет
    • Иногда анимация «show» программной клавиатуры запускается дважды подряд, создавая нежелательный визуальный эффект.
    • Иногда обработка фокуса сложна и может привести к показу StageText-TextInput без клавиатуры программного обеспечения, пока ученик не коснется его снова.

Этот подход сочетает в себе преимущества StageText с функциональностью прокрутки TextInputSkin (spark.skins.mobile). Общая идея заключается в создании 1 TextInput, который использует StageText и назначает его фиксированному местоположению на экране. Этот TextInput должен быть скрыт по умолчанию. Другие TextInputs (с использованием TextInputSkin) могут быть созданы и размещены по мере необходимости на сцене. Когда один из этих TextInputs получает фокус, скрытый суррогатный TextInput должен быть показан, и фокус должен быть перенесен на него. Когда текст вводится в суррогат, обработчик изменений должен скопировать текст в выбранный пользователем TextInput. Когда пользователь нажимает или щелкает, чтобы установить фокус в другом месте, суррогатный TextInput должен быть снова скрыт.

При желании я могу привести пример кода. Есть несколько недостатков этого подхода (упомянутый выше), но возможно, что это вина моей реализации.


StageWebView

Этот подход включает отображение простой HTML-страницы внутри вашего приложения AIR с помощью StageWebView. HTML-страница содержит объекты <input type="text"> которые используют собственную текстовую и программную клавиатуру Android. Коммуникация между HTML-страницей и родительским AIR-приложением немного сложна, так как StageWebView не поддерживает связь Flash-to-JavaScript в том же виде, что и ExternalInterface .

Общение с JavaScript на Flash

Общение с JavaScript (или HTML) в ActionScript затруднено, потому что StageWebView не позволяет ActionScript добавлять обратные вызовы. StageWebViewBridge предлагает эту функциональность не обновлялось за какое-то время, и когда я это пробовал, мне не удалось отобразить контент, используя Flex 4.6 и AIR 3.5.

Есть еще способы передать информацию в ActionScript с помощью LocationChangeEvent . Идея этого заключается в том, чтобы приложение AIR прослушивало события изменения местоположения и затем анализировало входящее event.location . Для простых ссылок это работает легко, но вещи становятся все более сложными, когда дело доходит до форм. Я пробовал следующие подходы, прежде чем решить одно:

  • http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png Добавьте обработчик onclick в форму-submit, которая устанавливает window.location.href в строку, содержащую URL-кодированный ключ / Значение. Этот подход не работает по причинам, описанным в биг-биде 3362483 .
  • http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png Добавьте обработчик onclick к кнопке формы-отправки, которая динамически изменяет форму-цель, чтобы содержать ключ / значение URL-кодировки Пар, а затем представляет форму. Этот подход не работает, потому что LocationChangeEvents не отправляется при вызове form.submit ().
  • http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Добавить обработчики обмена тегами <input type="text"> и изменить атрибут href ссылки «отправить» на Содержат пары ключ / значение URL-кодировки. Когда эта ссылка будет нажата, вызывается обработчик ActionScript LocationChangeEvent, и вы можете анализировать входящие данные с помощью класса URLVariables .

Общение с Flash на JavaScript

Чтобы связаться с JavaScript (методы вызова, параметры передачи), используйте метод loadURL StageWebView следующим образом:

 _stageWebView.loadURL( 'javascript:yourMethodName( "A string", true )' ); 

К сожалению, метод loadURL имеет тип возврата void (что означает, что вы не можете получить данные таким образом).

Другие трудности

Самый большой недостаток этого подхода описан в биг-дате 3535948 . Если ваше приложение AIR использует <renderMode>direct</renderMode> или <fullscreen>true</fullscreen> то ввод текста через StageWebView будет непригодным для использования. (Ответ будет вялым. Пользователи не смогут выбирать или удалять символы.) Если ваше приложение не требует ни одного из этих флагов, этот маршрут может работать хорошо для вас.

Одним из обходных ограничений для полноэкранного ограничения является отключить полноэкранный режим, только если вашему приложению необходимо использовать StageWebView. Это можно сделать с помощью StageDisplayState следующим образом:

 // Turn off fullscreen stage.displayState = StageDisplayState.NORMAL; // Turn on fullscreen stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE; 

Родной взгляд

Последняя оставшаяся опция (я знаю) – написать собственное расширение, которое отображает текстовые входы и возвращает данные в ваше приложение AIR. Вероятно, это самый безопасный (хотя и самый разочаровывающий) вариант тех, которые обсуждались в этой теме.

У нас может быть решение, которое работает по крайней мере для наших сценариев: http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx