Flash sur Android – Gérer les contraintes de taille, scale, full screen, rotation…
A partir d'Android 2.2 (FroYo), vos applications Flash / Flex pourront être lues directement dans le navigateur de votre mobile, grâce à l'application Flash Player 10.1 que vous pourrez télécharger par l'Android Market. Mais ce nouvel environnement n'est pas aussi facile à apprivoiser que votre environnement bureautique auquel vous êtes habitués. En effet, il faut maintenant gérer la rotation du téléphone, la mise à l'échelle automatique (scale) du navigateur Android, les différences de dpi, etc.
Pour vous aider, Allen Ellison (employée Adobe) a écrit un billet très complet que vous pouvez trouver sous une forme plus lisible sur le site de jeux en ligne Kongregate (coïncidence, c'est Kongregate qui avait sponsorisé mon premier jeu en Flash tout buggé à l'époque rotaZion !):
Adobe Flash Sizing Zen: Android Devices
Je vais traduire ici cet article pour nos amis francophones.
Introduction
Lorsque vous prenez votre contenu Flash (jeux, animations, applications Flex, …) et que vous voulez le faire tourner sur plusieurs plate-formes en utilisant Flash Player 10.1, il y a de nombreuses notions spécifiques que vous devez prendre en compte. Le plus important étant peut-être de vous assurer que votre contenu est à une taille correcte.
Il y a deux modes d'affichage supportés par Flash Player 10.1 sur environnements mobiles: embedded (embarqué dans une page web) et full screen (plein écran). Adobe Air permet de faire des applications natives en dehors du navigateur et dispose d'une plus grande flexibilité (vous pouvez trouver plusieurs articles à ce sujet sur flex-tutorial, Air Android).
Mode Plein écran (Full Screen)
Quand le navigateur Android ouvre une page contenant du contenu Flash, il ne va jamais entrer automatiquement en mode plein écran. Plusieurs actions utilisateur peuvent cependant passer le contenu en plein écran:
- Si le contenu utilise le mécanisme de passage en plein écran classique, celui que l'on peut trouver pour les applications bureautiques (les tags HTML object et embed contiennent la propriété allowFullScreen="true" et qu'une action utilisation modifie le displayState du stage), alors le mode plein écran sera aussi lancé sur plate-formes mobiles. Toutes les restrictions de sécurité/fonctionnalités concernant le passage en plein écran classiques sont aussi appliquées sur plate-formes mobiles.
- Si le tag HTML object contient le paramètre "fullScreenOnSelection", alors le contenu sera lancé en plein écran quand l'utilisateur sélectionne le contenu (par une pression sur le contenu). L'utilisateur va recevoir une notification du passage en plein écran. Toutes les restrictions de sécurité/fonctionnalités concernant le passage en plein écran classiques sont aussi appliquées sur plate-formes mobiles.
- Si l'utilisateur fait une pression longue sur le contenu (lorsqu'il n'est pas en mode plein écran), on lui proposera de passer le contenu en plein écran, peu importe si l'option allowFullScreen est à true ou non. Une pression longue en mode plein écran ne fait rien de spécial. Il n'y a aucune manière de désactiver ce comportement. Une fois en mode plein écran, toutes les restrictions de sécurité/fonctionnalités concernant le passage en plein écran classiques sont aussi appliquées sur plate-formes mobiles.
Une fois que l'utilisateur est sorti du mode plein écran, s'il sélectionne le contenu (même si fullScreenOnSelection="true"), cela n'aura aucun effet. Pour avoir la possibilité de se mettre en plein écran à nouveau, l'utilisateur devra actualiser la page ou changer de page et revenir à celle ayant le contenu Flash.
A cause de ce comportement, il est recommandé aux jeux de se mettre en pause quand ils détectent une sortie du mode plein écran.
Le mode plein écran offre les bénéfices suivants:
- Utilisation maximale de l'écran de l'utilisateur
- Puisqu'une interaction utilisateur est nécessaire au passage en plein écran, vous êtes sur que votre contenu a le focus.
- Vous pouvez bloquer l'écran en mode paysage (mais pas en portrait)
- Vous êtes sûr que votre contenu est à la bonne taille, quelle que soit son orientation
Le mode plein écran a en revanche, les inconvénients suivants:
- Vous ne pouvez pas accéder au clavier (physique ou virtuel) en mode plein écran (même restriction que pour Flash Player desktop)
- Le contenu HTML ne sera pas affiché en plein écran (même si le code JavaScript sera toujours exécuté)
Mode embarqué (Embedded)
Par défaut, quand l'utilisateur navigue vers un URL qui contient au moins du contenu Flash, celui-ci est en mode "embarqué". Il existe une variation de ce mode qui est souvent appelé "selected" ou "focused", correspondant à l'état dans lequel se trouve votre application quand votre utilisateur a effectué une pression sur la zone de contenu. Lorsque cela arrive, le contenu Flash va clignoter brièvement pour indiquer qu'il a reçu le focus.
Ce mode "selected/focused" a les avantages suivants par rapport à un simple état "embarqué":
- Une plus grande priorité par rapport à d'autres contenus Flash (en terme de mémoire par exemple)
- Accès au clavier et au DPAD (Pad directionnel) / Trackball
- Peut recevoir les "gestures" gérées par Flash Player 10.1
Bien que cela ne fonctionne pas encore au moment de l'écriture de cet article, vous pouvez sélectionner automatiquement votre contenu Flash (ce qui ne le fera pas aller en plein écran pour autant).
Quand ce sera supporté, vous pourrez faire:
document.getElementById("YourFlashMovie").focus();
Indiquer à votre page HTML que le contenu est adapté à du mobile
Une fois que l'utilisateur a passé l'animation en plein écran, la gestion de la taille de votre animation est bien plus simple. Mais tant que vous êtes en mode "embarqué", l'avoir à la bonne taille est assez technique.
Pour la déclaration de votre page HTML, l'équipe Flash Player recommande:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml- basic10.dtd"> <html xmlns="http://www.w3.org/19999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ... </head> </html>
pour les raisons suivantes:
- Cela évite le transcoding Verizon (un grand opérateur téléphonique américain)
- Cela évite de marquer (à tort) le contenu comme WAP
- Cela utilise un norme XHTML donnée par le W3C
- Notez que ce type de DTD exclus intentionnellement la gestion des frames HTML.
Bloquer la largeur (width) de votre viewport Android
Le navigateur Android va automatiquement vous permettre de remettre la page à l'échelle (zoom avant / arrière sur la page). Dans notre cas, vous ne voulez sûrement pas ce comportement qui va mettre à petite échelle tout votre contenu.
Pour bloquer ce comportement, cela se passe par la balise meta portant le nom "viewport":
<meta name="viewport" content="target- densitydpi=device-dpi, width=device-width, user-scalable=no"/>
Vous pouvez aussi donner la taille en pixels:
<meta name="viewport" content="target- densitydpi=device-dpi, width=480, user-scalable=no"/>
Il faut noter que certains attributs du viewport sont ignorés par Android: initial-scale, minimum-scale and maximum-scale.
Ne pas autoriser le cache (environnement de développement)
Lorsque vous allez tester votre contenu Flash, vous voudrez sûrement que la page ne soit pas gardée en cache. Si vous ne voulez pas vider le cache manuellement, il existe une balise meta qui permet d'indiquer cela (attention, ne pas mettre en production):
<meta http-equiv="CACHE-CONTROL" content="NO-CACHE">
Utilisation de la librairie SWFObject 2
Pour vous simplifier l'intégration de votre contenu Flash (détection de version, ajout des tags nécessaires sous tous les navigateurs, …), il est conseillé d'utiliser la célèbre librairie JavaScript SWFObject 2.
AIR pour Android – Sortie d'une nouvelle pre-release avec support des composants Flex 4 et Camera
Les développeurs responsable de la pre-release Adobe Air 2.5, compatible avec les plate-formes Android publient assez fréquemment de nouveaux builds, toutes les semaines ou tous les 15 jours. Et ce 20 Juillet est sortie une nouvelle version qui, mine de rien, apporte son lot de nouveautés et de corrections!
Pour récupérer cette nouvelle version, connectez-vous sur le site de la pre-release Air 2.5 et rendez-vous dans la section Download. Pour tout ce qui est installation + développement + déploiement, consultez mon article détaillé:
Air Android – Créer une application Air pour Android (apk), le guide de A à Z
Les nouveautés de cette version du 20 Juillet
Si vous lisez les Release Notes présentes sur le site de la pre-release, voici les nouveautés / bugs corrigés:
In 07/20/2010 build
Following new features have been introduced, please see feature description section below for more details.
- Still Pictures and Videos – CameraUI class
- Mapping Android specific tags from app-xml to Android Manifest
- NetworkInfo class is now supported on Android.
Fixed bugs
- Device debugging doesn't work with Flash CS5 plug-in
- 2635683 – Application using Spark components Crashes on Froyo Emulator
Dans le reste du document, vous avez le détail des nouveautés.
On pourra déjà remarquer un bug corrigé de la plus grande importance, les composants Spark (Flex 4) sont maintenant supportés. Dans les builds précédents, l'application crashait directement. Il semble que cela soit corrigé, ce qui est une excellente nouvelle car les composants Flex 4 sont plus légers et les performances de votre application mobile ne s'en portera que mieux 
.
La classe CameraUI (Still Pictures and Video)
Cette fonctionnalité permet aux développeurs d'accéder à l'application caméra Android. Une nouvelle classe, flash.media.CameraUI a été introduite pour cela. CameraUI lance l'interface native du téléphone pour la capture image ou vidéo. Une fois que l'utilisateur a pris une photo ou une vidéo, le média est sauvegardé dans le "CameraRoll" (la gallerie photo de base des systèmes Android) et est retourné à votre code ActionScript par l'intermédiaire d'un MediaEvent.
Les applications Air pour Android utilisant CameraUI n'ont pas besoin d'avoir la permission d'utiliser la caméra car elles n'accèdent pas directement à la camera Android.
Ajout du mapping de tags Android dans le manifest
Comme on l'a vu dans le tutorial Air Android, et plus spécifiquement dans le tutorial sur l'accès aux données Internet et aux données GPS, on peut définir dans le manifest (fichier XML descripteur de notre application), des permissions et d'autres paramètres. De nouveaux paramètres sont mappés dans ce build comme par exemple:
- "installLocation" pour indiquer si on autorise l'application a être installée en mémoire ou sur la carte SD.
- "excludeFromRecents" pour indiquer que l'on ne veut pas que notre application soit présente parmi la liste des dernières applications ouvertes
- "enabled" pour indiquer que l'on veut afficher ou non l'application une fois installée
- "Uses-feature" pour indiquer que certaines fonctionnalités sont nécessaires pour installer l'application. Par exemple, si vous voulez que votre application soit affichée sur le Market seulement pour les appareils ayant une caméra autofocus, utiliser <uses-feature android:name="android.hardware.camera.autofocus"/>
AIR pour Android – VoiceNotes, une application Air utilisant l'API Microphone Air
Christophe Coenraets a publié ce matin un billet dans lequel il présente une application Air pour Android qu'il a crée:
"VoiceNotes for Android": Sample App using Flex, AIR, and the Microphone API
Cette application, VoiceNotes, est donc une application Air pour Android profitant du dernier ajout du SDK Air 2.5 pour Android: l'API Microphone.
Cette API a été introduite pour Air 2.0 et permet de manipuler directement le flux audio du microphone. Si vous souhaitez en savoir plus sur cette API Microphone Air, je vous conseille cet article:
Using the Microphone capabilities in Adobe AIR 2
Depuis aujourd'hui, cette API est disponible pour vos développement Android! Pour Air Desktop, on parle donc d'un micro-casque par exemple mais dans le contexte Android, c'est le microphone du téléphone qui est utilisé. L'application VoiceNotes permet ainsi d'enregistrer des messages depuis votre mobile. Ils sont ensuite conservés sur la carte SD de votre mobile et peuvent être lus quand vous le souhaitez, une sorte de mémo vocal.
Les sources de l'application ainsi que le fichier APK sont disponibles sur son billet, je vous invite à les télécharger si vous êtes curieux
Flex 4 – Le lien "Données" entre Skin et Composant
Grâce à l’utilisation des States, notre composant a un nouvel aspect graphique. Cependant, le label du bouton est toujours « Bouton ». En effet, celui-ci est codé en dur dans notre fichier MyButtonSkin. Le label que l’on va donner au bouton n’est pas une propriété de la Skin, mais une propriété du composant Button. Pourtant, notre composant Label se trouve dans le Skin, et c’est lui qui doit recevoir ce texte.
C’est là qu’intervient le contrat de type "Données" entre le composant Button et la Skin. La Skin va ainsi indiquer sur quel composant hôte elle peut se greffer. Cela se fait par l’ajout d’une méta-information sur le composant : [HostComponent("chemin vers la classe concernée")].
Depuis la Skin, on pourra alors accéder à ce composant hôte par la propriété « hostComponent ». Pour lier la propriété « label » du composant Button et la propriété « text » du composant Label de la Skin, on va faire un simple DataBinding. Voici les éléments à rajouter dans MyButtonSkin.mxml :
<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark" alpha.disabled=".5">
<fx:Metadata>
[HostComponent("spark.components.Button")]
</fx:Metadata>
...
<s:Label text="{hostComponent.label}" color="0x131313"
textAlign="center"
verticalAlign="middle"
horizontalCenter="0" verticalCenter="1"
left="12" right="12" top="6" bottom="6"
/>
</s:Skin>
Vous pouvez maintenant préciser n’importe quel label, en donnant simplement une valeur à la propriété « label » de votre Button:
Votre composant se comporte maintenant comme vous le souhaitiez, exactement comme le Button Spark de base. Le composant Button de base est d’ailleurs fait de la même manière, avec de base, la classe spark.skins.spark.ButtonSkin.
Vous pouvez si le souhaitez aller voir comment est crée la Skin de base des Button Spark. Pour cela, il vous suffit d’ouvrir la classe ButtonSkin dans Flash Builder. Dans le menu de Flash Builder 4, allez dans Navigate > Open Type… puis tapez « ButtonSkin » dans le champ de recherche.
Adobe Alchemy – Comparaison de performances sur algorithme de tri ActionScript / C++
Adobe Alchemy existe maintenant depuis plusieurs années mais reste toujours dans un état "preview". Cela ne veut cependant pas dire que vous ne pouvez pas l'utiliser
Pour ceux qui ne connaissent pas Adobe Alchemy, c'est une initiative permettant de compiler du code C/C++ pour qu'il puisse être interprété par la machine virtuelle Flash (Flash Player). Le code est compilé en SWF ou en SWC (ActionScript 3), et peut ensuite être utilisé dans un projet Flash / Flex (Flash Player 10 et Adobe Air 1.5 minimum).
On peut donc ré-utiliser des librairies existantes en C/C++ (crypto, parseXML, …) ou bien compiler du code que l'on va écrire soi-même. Les gains de performances sont de l'ordre de 2 à 10 fois plus rapides pour l'exécution du code C/C++ compilé, de quoi faire réfléchir.
Le test sur un algorithme de tri (BubbleSort)
Le blog Comtaste Consulting a publié la semaine dernière, un billet très intéressant comparant l'exécution d'un code similaire en AS3 et C++:
Adobe Alchemy: a comparative example
L'algorithme est celui du Bubble Sort. C'est un algorithme de tri de tableau classique:
Pour voir le code complet de l'implémentation en AS3 et en C++, je vous invite à lire l'article.
Performances obtenues
Le test a été effectué sur le tri d'un tableau de 20 000 entiers, et voilà les résultats:
- Temps passé par l'algorithme ActionScript: 36.5 secondes
- Temps passé par l'algorithme C++: 8.093 secondes
On a donc un gain de temps de 75% !
Voilà, il faut noter qu'Alchemy n'est pas là pour remplacer tout votre AS mais il peut vous être utile pour des traitements lourds.
Si j'ai le temps (et la patience de me remettre sur du C++), je ferai un test sur un de mes algorithmes de traitement qui est assez lent pour beaucoup d'éléments (création de Cluster pour des Markers cartographique fait côté client).
Mes projets (Open Source)
Autres
