¿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?
- punto de entrada de la aplicación android
- Soporte de iframe en móviles
- Android query failed com.android.internal.telephonyCommandException RADIO_NOT_AVAILABLE
- Aplicación de copia de seguridad de Cordova mediante Android Backup Service
- Jquery móvil - valor de visualización en teléfonos android
- ¿Cómo generar enlace waze meetup con fallback web?
- ¿Cómo hacer que el número no sea accesible (similar al bloqueador de llamadas)?
- ¿Puede un APK ser reempaquetado después de una edición de texto menor?
- ¿Qué tan bien soportada es la sensibilidad a la presión en los dispositivos Android?
- ¿Cómo detectar móviles (iOS y Android) utilizando JSP / Java?
- ¿Cómo obtienes MCC y MNC del teléfono en Android?
- Android deja de sugerir palabras
- ¿Cómo consultar las vistas secundarias de una vista principal con Titanium?
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
- Maneja la entrada correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
- Se muestra correctamente en todos los casos? http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png No
- Problemas de alineación vertical al desplazarse.
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)
- Maneja la entrada correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
- Se muestra correctamente en todos los casos? http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png No
- Inserta caracteres aleatorios en ciertas versiones de Android (por ejemplo, Nook con Android 2.3).
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)
- Maneja la entrada correctamente en todos los casos? http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png No
- No acepta ciertos caracteres de doble byte (por ejemplo, coreano).
- No acepta ninguna entrada en ciertos dispositivos (por ejemplo, Samsung Galaxy 10.1 con Android 4.0).
- Se muestra correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
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
- Maneja la entrada correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
- Se muestra correctamente en todos los casos? http://png-1.findicons.com/files/icons/2132/tiny/10/exclamation.png No
- A veces, la animación "show" del teclado de software se dispara dos veces seguidas, creando un efecto visual indeseable.
- A veces, el manejo del enfoque es difícil y puede provocar que StageText-TextInput se muestre sin un teclado de software hasta que el alumno lo toque de nuevo.
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
- Maneja la entrada correctamente en todos los casos? http://png-2.findicons.com/files/icons/1687/free_web_design/16/mini_warning.png Sí / No
- Dependiendo del valor de
<renderMode>
y<fullscreen>
este componente puede funcionar correctamente para usted. - Es un poco difícil de conseguir trabajo.
- Dependiendo del valor de
- Se muestra correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
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 atributohref
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
- Maneja la entrada correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
- Se muestra correctamente en todos los casos? http://png-5.findicons.com/files/icons/1156/fugue/16/tick_small.png Sí
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