Consideraciones sobre el diseño de aplicaciones móviles

Si la aplicación deja de seleccionar otra aplicación, AIR elimina la velocidad de fotogramas en 4 fotogramas por segundo y deja de representar los gráficos. En valores inferiores a esta velocidad de fotogramas, la red de transmisión y las conexiones de socket tienden a bloquearse. Si la aplicación no utiliza estas conexiones, la velocidad de fotogramas se puede disminuir aún más.

Si es adecuado, se debe detener la reproducción de audio y eliminar los detectores en los sensores del acelerómetro y localización geográfica. El objeto NativeApplication de AIR distribuye eventos de activación y desactivación. Utilice estos eventos para administrar la transición entre el estado activo y de fondo.

Las mayor parte de los sistemas operativos móviles finalizan las aplicaciones de fondo sin aviso. Al guardar el estado de la aplicación con frecuencia, la aplicación debe poder restaurarse a sí misma a un estado razonable si vuelve a su estado activo desde el segundi plano o se inicia de nuevo.

El tamaño físico de la pantalla de los dispositivos móviles es inferior al de los equipos de escritorio, aunque su densidad de píxeles (píxeles por pulgada=) es mayor. El mismo tamaño de fuente producirá letras que son físicamente más pequeñas en la pantalla del dispositivo móvil que en un equipo de escritorio. A menudo se debe emplear una fuente más grande para garantizar la legibilidad. En general, punto 14 es el tamaño de fuente más pequeño que se puede leer fácilmente.

La mayoría de los dispositivos móviles se utilizan en el momento y con malas condiciones de iluminación. Analice cuánta información puede mostrar en pantalla de forma realista y con legibilidad. Suele ser menor que la que visualizaría en una pantalla con las mismas dimensiones de píxeles en un equipo de escritorio.

También se debe tener en cuenta que cuando un usuario está tocando la pantalla, los dedos y la mano bloquean parte de la vista de la pantalla. Sitúe los elementos interactivos en los lados y la parte inferior de la pantalla cuando el usuario ya no tenga que interactuar con los mismos durante más tiempo que un toque momentáneo.

Muchos dispositivos utilizan un teclado virtual para la introducción de texto. Los teclados virtuales oscurecen parte de la pantalla y su uso es a veces complejo. Evite confiar en los eventos de teclado (excepto para las teclas programables).

Considere alternativas de implementación a los campos de introducción de texto. Por ejemplo, para que el usuario introduzca un valor numérico no es necesario disponer de un campo de texto. Puede incluir dos botones para aumentar o disminuir el valor.

Los dispositivos móviles incluyen un número variado de teclas programables. Las teclas programables son botones que se programan para tener diferentes funciones. Siga las convenciones de la plataforma para estas teclas en la aplicación.

El contenido móvil se puede visualizar en orientación vertical y horizontal. Por ello, debe tener en cuenta qué hará la aplicación cuando cambie la orientación de la pantalla. Para obtener más información, consulte Orientación del escenario .

AIR no evita automáticamente que la pantalla se atenúe mientras se reproduce el vídeo. Se puede utilizar la propiedad systemIdleMode del objeto NativeApplication de AIR para controlar si el dispositivo entrará en modo de ahorro de energía. (En algunas plataformas, se deben solicitar los permisos adecuados para que funcione esta característica.)

El motor de ejecución de AIR silencia el audio automáticamente cuando el usuario realiza o recibe una llamada de teléfono. En Android, se debe establecer el permiso READ_PHONE_STATE de Android en el descriptor de la aplicación si esta reproduce audio mientras esté en segundo plano. De lo contrario, Android evita que el motor de ejecución detecte llamadas de teléfono y silencia el audio automáticamente. Consulte Permisos de Android .

Tenga en cuenta el tamaño de los destinos de selección cuando diseñe botones y otros elementos de la interfaz de usuario que este tocará durante el uso. Estos elementos deben ser lo suficientemente grandes como para activarlos cómodamente con un dedo en una pantalla táctil. Asimismo, asegúrese de que dispone de espacio suficiente entre los destinos. El área de destino debe ser de unos 44 píxeles a 57 píxeles en cada lado para una pantalla de dispositivo móvil típica de ppp elevados.

Los dispositivos móviles suelen tener menos espacio de almacenamiento para instalar aplicaciones y datos que los equipos de escritorio. Minimice el tamaño del paquete eliminado los recursos y las bibliotecas no utilizados.

En Android, el paquete de la aplicación no se extrae en archivos independientes cuando se instala la aplicación. Los recursos se descomprimen en un almacenamiento temporal cuando se accede a los mismos. Para reducir esta superficie de almacenamiento del recurso descomprimido, cierre las transmisiones de URL y archivos cuando los recursos se hayan cargado por completo.

Los diferentes sistemas operativos móviles imponen distintas restricciones al acceso al sistema de archivos y estas limitaciones tienden a ser distintas de las aplicadas por los sistemas operativos de escritorio. Por lo tanto, el lugar adecuado para guardar los archivos y los datos puede variar según la plataforma.

Una consecuencia de la variación en los sistemas de archivos es que los métodos abreviados a los directorios comunes proporcionados por la clase File de AIR no siempre están disponibles. La siguiente tabla muestra qué métodos abreviados se pueden usar en Android y iOS:

Las directrices de Apple para aplicaciones de iOS estipulan normas específicas para determinar las ubicaciones de almacenamiento de archivos según el caso. Por ejemplo: un directorio designado como ubicación remota para albergar copias de seguridad únicamente puede contener archivos con datos introducidos por usuarios o información que no sea posible volver a generar o cargar. Para obtener información sobre cómo cumplir con las directrices de Apple para copia de seguridad y almacenamiento de archivos en caché, consulte Control de copias de seguridad y almacenamiento en caché .

Adobe ha desarrollado una versión optimizada para móvil de la arquitectura de Flex. Para obtener más información, consulte Developing Mobile Applications with Flex and Flash Builder .

Los proyectos del componente Community adecuados para las aplicaciones móviles también están disponibles. Se incluyen:

• Feathers UI controls for Starling de Josh Tynjala

• Versión de aspecto configurable de componentes mínimos de Derrick Grigg

• Componentes as3flobile de Todd Anderson

Desde AIR 3.2, AIR para móviles admite procesamiento de gráficos acelerados Stage 3D. Las API Stage3D de ActionScript son un conjunto de API de bajo nivel con aceleración por GPU que permiten usar funciones 2D y 3D avanzadas. Estas API de bajo nivel ofrecen flexibilidad a los desarrolladores para poder aprovechar la aceleración por hardware de GPU y mejorar significativamente el rendimiento. También puede utilizar motores de juegos que admitan las API Stage3D de ActionScript.

Para obtener más información, consulte Motores de juegos, 3D y Stage3D .

Para mejorar el rendimiento, el suavizado de vídeo está desactivado en AIR.

Muchas plataformas para móvil incluyen funciones a las que aún no se puede acceder desde la API estándar de AIR. En AIR 3, es posible ampliar AIR con sus propias bibliotecas nativas de código. Estas bibliotecas de extensiones nativas pueden acceder a funciones disponibles en el sistema operativo e incluso a funciones específicas de un dispositivo determinado. Las extensiones nativas se pueden escribir en C en iOS, y en Java o en C en Android. Para obtener información sobre el desarrollo de extensiones nativas, consulte Introducción a extensiones nativas para Adobe AIR .