Considérations liées à la conception d’applications mobiles

Le contexte d’exploitation et les caractéristiques physiques des périphériques mobiles nécessitent de porter une attention toute particulière au codage et à la conception. Il est, par exemple, déterminant de rationaliser le code pour assurer une exécution aussi rapide que possible. Il est bien évident que l’optimisation du code a ses limites. Une conception intelligente qui prend en compte les restrictions du périphérique permet également d’éviter que la présentation visuelle ne sollicite trop le système de rendu.

Code

Bien qu’une exécution plus rapide du code constitue toujours un avantage, la vitesse réduite du processeur de la plupart des périphériques mobiles rationalise l’investissement en temps que représente l’écriture de code minimaliste. Par ailleurs, les périphériques mobiles sont quasiment toujours alimentés par batterie. Obtenir un résultat identique en réduisant la puissance de traitement requise utilise moins de batterie.

Création

La taille d’écran réduite, le mode d’interaction par écran tactile, voire l’environnement en évolution constante d’un utilisateur mobile sont autant de facteurs à prendre en compte lors de la conception de l’expérience utilisateur de l’application.

Code et création conjoints

Si l’application fait appel à l’animation, l’optimisation du rendu joue un rôle déterminant. Dans certains cas, l’optimisation du code n’est toutefois pas suffisante. Vous devez concevoir les aspects visuels de l’application de sorte à assurer un rendu performant par le code.

D’importantes techniques d’optimisation sont passées en revue dans le manuel Optimisation de contenu mobile pour la plate-forme Adobe Flash. Les techniques décrites dans ce manuel s’appliquent à tout contenu Flash et AIR, mais jouent un rôle déterminant dans le développement d’applications pour périphériques mobiles performantes.

Cycle de vie d’une application

Lorsque la cible d’action passe d’une application à une autre, AIR fait passer la cadence à 4 images/s et désactive le rendu des graphiques. Une cadence inférieure se traduit souvent par l’interruption des connexions socket et du réseau de diffusion en continu. Si l’application n’utilise pas ces types de connexion, vous pouvez réduire plus encore la cadence.

Au moment opportun, vous devez arrêter la lecture de l’audio et supprimer les écouteurs associés aux capteurs de géolocalisation et de l’accéléromètre. L’objet NativeApplication AIR distribue des événements d’activation et de désactivation. Ces événements permettent de gérer la transition entre l’état actif et l’état d’arrière-plan.

La plupart des systèmes d’exploitation mobiles arrêtent les applications qui s’exécutent en arrière-plan sans avertissement. Grâce à l’enregistrement régulier de l’état d’une application, celle-ci devrait pouvoir restaurer elle-même un état satisfaisant, qu’il s’agisse de la réactivation de l’état actif à partir d’une exécution en arrière-plan ou d’un nouveau lancement.

Densité des informations

En dépit d’une densité (nombre de pixels par pouce) supérieure, la taille physique de l’écran des périphériques mobiles est inférieure à celle d’un ordinateur de bureau. Une même taille de police produit des lettres de taille physique inférieure sur un écran de périphérique mobile que sur un ordinateur de bureau. Par souci de lisibilité, il est souvent nécessaire d’utiliser une taille de police supérieure. En règle générale, 14 points est la plus petite taille de police qu’un utilisateur puisse facilement lire.

Les périphériques mobiles sont souvent utilisés en cours de déplacement et dans des environnements mal éclairés. Faites preuve de réalisme pour évaluer le volume d’informations qu’il est possible d’afficher sans perte de lisibilité. Cette valeur est probablement inférieure à celle d’un écran d’ordinateur de bureau aux dimensions identiques en pixels.

Gardez également à l’esprit le fait que lorsqu’un utilisateur touche l’écran, il masque du doigt ou de la main une partie de ce dernier. Placez les éléments interactifs sur les côtés et au bas de l’écran si l’utilisateur ne se contente pas de les toucher momentanément.

Saisie de texte

La plupart des périphériques gèrent la saisie de texte par le biais d’un clavier virtuel. Souvent peu pratiques à utiliser, les claviers virtuels masquent une partie de l’écran. A l’exception des touches programmables, évitez de faire appel aux événements de clavier.

Envisagez de substituer d’autres solutions aux champs de texte de saisie. Il est, par exemple, inutile d’inviter l’utilisateur à entrer une valeur numérique dans un champ de texte. Proposez deux boutons pour augmenter ou réduire la valeur.

Touches programmables

Les périphériques mobiles comportent un nombre divers de touches programmables, c’est-à-dire des boutons que vous pouvez programmer pour leur affecter différentes fonctions. Respectez les conventions de la plate-forme lorsque vous programmez ces touches dans l’application.

Changements d’orientation de l’écran

Un contenu mobile peut être visualisé en mode portrait ou paysage. Considérez comment l’application gère les changements d’orientation de l’écran. Pour plus d’informations, voir Orientation de la scène.

Baisse de la luminosité de l’écran

AIR ne désactive pas automatiquement la baisse de la luminosité de l’écran en cours de lecture vidéo. Vous disposez de la propriété systemIdleMode de l’objet NativeApplication AIR pour contrôler l’activation du mode d’économie d’énergie du périphérique. (Sur certaines plates-formes, vous devez demander les autorisations appropriées pour que cette fonctionnalité fonctionne.)

Appels téléphoniques entrants

Le moteur d’exécution d’AIR coupe automatiquement le son lorsque l’utilisateur effectue ou reçoit un appel téléphonique. Sous Android, définissez l’autorisation Android READ_PHONE_STATE dans le descripteur de l’application si celle-ci lit l’audio lorsqu’elle s’exécute en arrière-plan. Android interdit sinon au moteur d’exécution de détecter les appels téléphoniques et de couper le son automatiquement. Voir Autorisations Android.

Cibles tactiles

Tenez compte de la taille des cibles tactiles lorsque vous concevez les boutons et autres éléments de l’interface utilisateur touchés par l’utilisateur. Assurez-vous que la taille de ces éléments est suffisamment élevée pour que l’utilisateur puisse facilement les activer du doigt sur un écran tactile. Veillez également à ménager un espace suffisant entre cibles tactiles. Pour un écran de téléphone à résolution élevée standard, la superficie d’une cible tactile doit mesurer environ 44 pixels sur 57 pixels.

Taille d’installation d’un package d’application

Les périphériques mobiles disposent généralement d’un espace de stockage considérablement plus réduit que les ordinateurs de bureau pour installer applications et données. Réduisez la taille d’un package en supprimant les actifs et bibliothèques inutilisés.

Sous Android, le package d’une application n’est pas extrait dans des fichiers distincts lors de l’installation de cette dernière. Les actifs sont décompressés dans un espace de stockage temporaire lorsqu’il est nécessaire d’y accéder. Pour réduire l’encombrement mémoire des actifs décompressés, fermez les flux d’URL et de fichier, une fois le chargement des actifs terminé.

Accès au système de fichiers

Les restrictions relatives au système de fichiers varient selon le système d’exploitation mobile. Elles diffèrent souvent des restrictions imposées par les systèmes d’exploitation de bureau. L’emplacement d’enregistrement des fichiers et données risque par conséquent de varier selon la plate-forme.

Les variations en matière de système de fichiers ont pour conséquence que les raccourcis associés aux répertoires communs fournis par la classe File d’AIR ne sont pas toujours disponibles. Le tableau suivant indique les raccourcis disponibles sous Android et iOS :

 

Android

iOS

File.applicationDirectory

Lecture seule via une URL (et non le chemin natif)

Lecture seule

File.applicationStorageDirectory

Disponible

Disponible

File.cacheDirectory

Disponible

Disponible

File.desktopDirectory

Racine de la carte SD

Non disponible

File.documentsDirectory

Racine de la carte SD

Disponible

File.userDirectory

Racine de la carte SD

Non disponible

File.createTempDirectory()

Disponible

Disponible

File.createTempFile()

Disponible

Disponible

Les directives d’Apple concernant les applications iOS définissent des règles spécifiques concernant les emplacements de stockage à utiliser pour les fichiers dans différentes situations. Par exemple, l’une des directives est que seuls les fichiers contenant des données saisies par l’utilisateur ou des données qui ne peuvent pas être générées ou téléchargées à nouveau doivent être stockées dans le répertoire désigné pour la sauvegarde à distance. Pour plus d’informations sur la conformité aux directives d’Apple sur la sauvegarde des fichiers et la mise en cache, voir Contrôle de la sauvegarde et de la mise en cache des fichiers.

Composants de l’interface utilisateur

Adobe a développé une version de la structure d’application Flex optimisée pour les plates-formes mobiles. Pour plus d’informations, voir Développement d’applications mobiles avec Flex et Flash Builder.

Des projets de composants à usage communautaire adaptés aux applications mobiles sont également disponibles. Parmi ces API figurent :

Rendu des graphiques par accélération matérielle via l’API Stage3D

A partir d’AIR 3.2, AIR for Mobile prend en charge le rendu des graphiques par accélération matérielle via l’API Stage 3D. Les API ActionScript Stage3D sont un ensemble d’API à accélération matérielle par GPU permettant d’utiliser des fonctionnalités 2D et 3D avancées. Ces API de bas niveau permettent aux développeurs de tirer profit de l’accélération matérielle par GPU pour augmenter les performances de façon significative. Il est également possible d’utiliser des moteurs de jeu prenant en charge les API ActionScript Stage3D.

Pour plus d’informations, voir Moteurs de jeu, 3D et Stage 3D.

Lissage vidéo

Afin d’améliorer les performances, le lissage vidéo est désactivé sur AIR.

Fonctions natives

De nombreuses plates-formes mobiles proposent des fonctions qui ne sont pas encore accessibles via l’API AIR standard. A partir d’AIR 3, vous pouvez étendre AIR avec vos propres bibliothèques de code natives. Ces bibliothèques d’extensions natives peuvent accéder aux fonctions disponibles sur le système d’exploitation, voire même aux fonctions propres à un périphérique donné. Il est possible d’écrire les extensions natives en langage C sur iOS, et en langage Java ou C sur Android. Pour plus d’informations sur le développement d’extensions natives, voir Présentation des extensions natives pour Adobe AIR.