¿Qué opciones están disponibles para manejar la introducción de texto en Android con Adobe AIR?

¿Qué opciones están disponibles para manejar la introducción de texto en Android con Adobe AIR? ¿Cuáles son las ventajas y desventajas de cada opción?

Las opciones actuales disponibles para los desarrolladores de AIR en Android para gestionar la introducción de texto son:

  • Texto nativo de StageText (predeterminado)
  • TextInputSkin (spark.skins.mobile)
  • TextInputSkin (spark.skins.spark)
  • StageText + TextInputSkin (spark.skins.mobile) híbrido
  • StageWebView (explicado a continuación)
  • Vista nativa

Voy a discutir algunas de las ventajas y desventajas de cada enfoque a continuación. Si he perdido algo (o si tiene otras ideas que no he pensado) por favor hágamelo saber!


StageText

De forma predeterminada, TextInputs que se ejecutan en dispositivos móviles utilizan StageText (texto nativo) para la entrada. StageText ofrece varias ventajas, como Adobe describe en su documentación en línea , incluyendo corrección automática, personalización de teclados de software, etc.

La mayor desventaja del uso de StageText se describe en el ticket 3302441 de bugbase . El posicionamiento de StageText se rompe cuando un usuario se desplaza. Los campos de texto aparecen fuera de sus respectivas TextInputs o, peor aún, dentro de otras TextInputs. El único trabajo alrededor de este defecto es diseñar una interfaz de usuario que no permite el desplazamiento. Obviamente esto puede ser muy difícil para teléfonos móviles y phablets.


TextInputSkin (spark.skins.mobile)

Este componente utiliza StyleableTextField internamente. Está optimizado para el uso móvil.

Este componente inserta caracteres adicionales y arbitrarios en TextInput como un usuario está escribiendo en ciertas versiones de Android (por ejemplo, Nook con Android 2.3, Kindle HD con Android 4.0). Vea el boleto de bugbase 3547601 .

Si su aplicación sólo está localizada en inglés (o en idiomas latinos) y no necesita soportar versiones anteriores de Android, entonces este componente puede funcionar bien para usted.


TextInputSkin (spark.skins.spark)

Este componente utiliza RichEditableText internamente. No está optimizado para el uso móvil. Más allá de eso demuestra varios defectos (enumerados arriba) que lo hacen inadecuado para el uso.

Este componente no maneja correctamente ciertos caracteres de doble byte (en idiomas como el coreano). Estos caracteres parecen ser insertados en el TextInput (el cursor avanza, visiblemente) pero no se procesa ningún texto al usuario. (Es posible que este problema se pueda resolver usando una fuente incorporada.) Vea el boleto de bugbase 3547591 .

Al probar el tercer elemento mencionado anteriormente (entrada no se aceptan en ciertos dispositivos) una cosa interesante se observó. Después de escribir un par de caracteres, si un usuario cambia el foco a un TextInput que utiliza el StageText predeterminado, al menos algunos de los caracteres que faltan se insertarán automáticamente en el nuevo campo.


StageText + TextInputSkin (spark.skins.mobile) híbrido

Este enfoque combina los beneficios de StageText con la funcionalidad de desplazamiento de TextInputSkin (spark.skins.mobile). La idea general es crear 1 TextInput que use StageText y asignarlo a una ubicación fija en la pantalla. Este TextInput debe ser ocultado por defecto. Otras TextInputs (usando TextInputSkin) se pueden crear y posicionar según sea necesario en el escenario. Cuando uno de estos TextInputs gana el foco, el sustituto escondido TextInput debe ser mostrado y el foco debe ser desplazado a él. A medida que el texto se introduce en el sustituto, un manipulador de cambios debe copiar el texto al TextInput seleccionado por el usuario. Cuando el usuario hace una pestaña o hace clic para establecer el foco en otra parte, el TextInput sustituto debe estar oculto de nuevo.

Puedo proporcionar un ejemplo del código de esto si está deseado. Hay un par de inconvenientes a este enfoque (mencionado anteriormente), pero es posible que sean la culpa de mi aplicación.


StageWebView

Este enfoque implica mostrar una página HTML simple dentro de la aplicación de AIR con StageWebView. La página HTML contiene <input type="text"> objetos que utilizan el teclado nativo de texto y software de Android. Sin embargo, la comunicación entre la página HTML y la aplicación primaria de AIR es un poco complicada, ya que StageWebView no admite la comunicación Flash-a-JavaScript en la misma que ExternalInterface .

Comunicación desde JavaScript a Flash

La comunicación desde JavaScript (o HTML) a ActionScript es difícil porque StageWebView no permite que ActionScript agregue devoluciones de llamada. StageWebViewBridge ofrece esta funcionalidad no se ha actualizado en algún momento y cuando lo intenté, no pude obtener contenido para mostrar utilizando Flex 4.6 y AIR 3.5.

Todavía hay formas de transmitir información a ActionScript mediante LocationChangeEvent . La idea detrás de esto es que la aplicación de AIR escuche los eventos que cambian la ubicación y luego analiza el event.location entrante. Para los acoplamientos simples esto trabaja fácilmente pero las cosas consiguen más complicadas cuando viene a las formas. He intentado los siguientes enfoques antes de resolver en uno:

  • http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png Añada un controlador onclick al botón form-submit que establece window.location.href en una cadena que contiene una clave codificada por URL / Pares de valores. Este enfoque no funciona por las razones descritas en el ticket 3362483 de bugbase .
  • http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png Agregar un controlador onclick al botón de envío de formulario que modifica dinámicamente el destino de formulario para que contenga clave / valor codificado en URL Pares y luego envía el formulario. Este enfoque no funciona porque LocationChangeEvents no se envían cuando form.submit () se llama.
  • http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Agregue los controladores onchange a las etiquetas <input type="text"> y modifique el atributo href de un enlace "submit" Contienen pares clave / valor codificados por URL. Cuando se hace clic en este enlace, se invocará el controlador de ActionScript LocationChangeEvent y se podrán analizar los datos entrantes mediante la clase URLVariables .

Comunicación desde Flash a JavaScript

Para comunicarse con JavaScript (métodos de llamada, parámetros de paso), utilice el método loadURL de StageWebView de la siguiente manera:

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

Desafortunadamente, el método loadURL tiene un tipo de retorno vacío (lo que significa que no puede recuperar datos de esta manera).

Otras dificultades

El inconveniente más grande de este enfoque se describe en el boleto de bugbase 3535948 . Si su aplicación de AIR utiliza <renderMode>direct</renderMode> o <fullscreen>true</fullscreen> , la entrada de texto a través de StageWebView será inutilizable. (La respuesta será lenta, los usuarios no podrán seleccionar o eliminar caracteres). Si su aplicación no requiere ninguno de esos indicadores, esta ruta puede funcionar bien para usted.

Una solución para la limitación de pantalla completa es deshabilitar el modo de pantalla completa sólo cuando su aplicación necesita hacer uso de un StageWebView. Esto se puede hacer con StageDisplayState como esto:

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

Vista nativa

La última opción restante (que conozco) es escribir una extensión nativa que muestra las entradas de texto y devuelve datos a la aplicación de AIR. Esta es probablemente la opción más segura (aunque más decepcionante) de las discutidas en este hilo.

Podríamos tener una solución que funcione al menos para nuestros escenarios: http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx

  • ¿Cuáles son las diferencias entre T-Mobile G1 (marca HTC Dream) y ADP1 de Google (dispositivo para desarrolladores)?
  • Android: error de transferencia: sistema de archivos de sólo lectura
  • Conexión a un puerto bluetooth específico en un dispositivo bluetooth mediante Android
  • Reducir el impacto de la batería de las aplicaciones que descargan contenido a través de una radio de teléfono inteligente
  • Convención de nomenclatura de ID de Android: minúsculas con subrayado vs. caso de camello
  • Android / Mobile Webkit CSS Antecedentes-Adjunto: fijo ¿No funciona?
  • ADB no reconoce mi dispositivo
  • ¿Es valioso el appcelerator Titanium para el desarrollo de aplicaciones basadas en cámara en ipad, iphone y android?
  • Elementos relativamente posicionado en desplazable absolutamente posicionado div "retraso" en el desplazamiento
  • Abrir el navegador nativo de una aplicación de Android
  • Phonegap android - evento deviceready no disparado
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.