Application mobile avec Animate (Flash) – quelques règles à observer

Astuces, conseils

ICONE_APPLI_ASTUCESGrâce à Adobe AIR il est désormais possible de transformer ses animations Adobe Animate en applications mobiles ou de bureau. Seule change la façon de publier son animation, je vous invite d’ailleurs à consulter cet article complémentaire : Publier une application mobile avec Adobe Animate et Air – Tutoriel pas à pas. Ainsi, si vous avez déjà conçu des animations pour le web en AS3 vous n’aurez pas de réelle difficulté à bifurquer vers le monde des applications puisque l’outil reste le même. Une facilité qui comporte toutefois des pièges : une application n’est pas une animation dans un navigateur, il convient donc de ne pas faire l’impasse sur certains ajustements techniques et conceptuels. Voici quelques trucs à savoir pour ne pas rater ce virage. Des conseils spécifiques à Adobe Animate, mais que l’on peut pour certains appliquer à d’autres technologies.

Ces astuces sont tirées de mes propres observations et erreurs. Elles s’adressent aux développeurs ayant déjà l’expérience de la création d’animations dynamiques en Animate (ancien Flash)/AS3, et connaissant AIR.

Commençons par explorer ce qui différencie une application mobile d’un contenu pour le web.

Web et applications, les différences

Si comme moi vous avez fait vos armes avec Animate sur le Web et que vous souhaitez maintenant explorer le monde des applications mobiles, vous vous doutez que cette transition implique certains changements dans la façon de penser et concevoir un contenu interactif. Outre les évidentes nouveautés offertes par les fonctionnalités des mobiles et tablettes (GPS, accéléromètre…), il y a aussi des spécificités ergonomiques à observer, ainsi qu’une réflexion à mener à propos des usages de ces appareils.

De nouveaux usages

L’utilisateur d’applications a un comportement différent de l’internaute qui ouvre une animation dans son navigateur. Pensez qu’il a probablement choisi votre application avec soin, l’a achetée puis téléchargée. Il y a donc une attente plus importante que s’il découvrait votre travail au hasard d’un lien sur Internet. On peut supposer aussi qu’il compte y revenir plusieurs fois, on installe rarement une application pour une seule utilisation. De même votre application s’affiche en plein écran, sans menus ni pop-up intempestive, ce qui favorise l’immersion. Bref, autant de raison de soigner la qualité de votre contenu : là où un internaute vous pardonnera facilement quelques approximations, l’utilisateur de votre application sera sans doute plus attentif aux détails, aux transitions, à la fluidité des animations, à la qualité sonore et graphique générale. En gros, une application devrait se situer un cran au-dessus de ce qu’on voit sur le Web (j’ai bien dit « devrait »).

Outre ces considérations générales, il y a aussi des points techniques précis dont vous devez tenir compte.

Ergonomie

La principale différence entre un ordinateur et une tablette, c’est l’écran tactile. Pensez que l’utilisateur se servira de son ou ses doigts, et pas d’une souris, ce qui implique plusieurs changements :

  • Les zones réactives doivent être plus grosses et espacées, car un doigt sur l’écran prend plus de place qu’un curseur (oui, c’est évident, mais c’est typiquement le genre de trucs qu’on oublie la première fois).
  • Il n’y a pas de rollover sur écran tactile ! Seulement un état « cliqué ».
  • Contrairement à un curseur, votre doigt est généralement prolongé par une main, elle-même prolongée par un bras. Pensez que lorsque vous appuyez sur un bouton vous masquez toute la zone sous votre main. Comme nous sommes en majorité droitiers et que nous appuyons avec l’index, il y a donc une zone critique assez définie dans laquelle vous devriez vous abstenir de placer un élément qui réagit de façon immédiate au bouton pressé, sous peine qu’il passe inaperçu.

Le fait de se servir de ses doigts plutôt que d’une souris peut aussi être source de bugs… Oui, car vous êtes né avec 10 doigts (sauf facétie de la nature), alors que sur ordinateur vous n’utilisez qu’un seul curseur. Il arrivera donc inévitablement que l’utilisateur appuie à plusieurs endroits simultanément, ce qui peut faire surgir des problèmes inédits. Exemple : vous pressez un bouton dans un coin de l’écran, et durant la fraction de seconde qui précède l’affichage de l’écran suivant vous pressez un second bouton dans le coin opposé. Un comportement que vous n’aviez pas prévu, que vous étiez dans l’impossibilité de tester avec la souris… et qui peut avoir des conséquences inattendues. Pensez-y lorsque vous développerez votre application. Et méfiez-vous, cette situation arrive plus souvent qu’on ne le croit, surtout avec les enfants qui appuient frénétiquement sur tout ce qui bouge. La meilleure pratique pour éviter ce genre de surprises est d’arrêter les écouteurs qui pourraient poser problème dès qu’un bouton est pressé, avant toute autre action.

Des conseils généraux auxquels s’ajoutent quelques particularités techniques spécifiques à Animate, à commencer par la gestion de l’affichage.

Gestion de l’affichage

Les smartphones et tablettes ont des spécificités techniques qui diffèrent de celles de nos ordinateurs de bureau : taille d’écran, gestion de la mémoire… Des particularités qui, lorsqu’elles rencontrent celles d’Animate, peuvent donner des résultats inattendus. Il faut en tenir compte lors de la conception.

Performances

En vous appliquant à respecter quelques conseils simples, qui sont grosso modo les mêmes que pour le web, vous serez capables d’afficher des graphismes en haute définition et des animations complexes tout en conservant un frame rate très correct. Pour ma part, je vise 25 images/seconde : c’est une cadence déjà très fluide (la même qu’en vidéo) et bien moins gourmande qu’un 50 ou 60 FPS pour une différence minime. A vous bien sûr de trouver le bon compromis entre fluidité, contraintes matérielles et complexité de vos animations.

Quel mode de rendu ?

Lorsque vous publierez votre application depuis Animate, il vous sera demandé de choisir un « mode de rendu ». Vous aurez deux choix : mode CPU (vous solliciterez le processeur) ou GPU (vous solliciterez le Chipset graphique). Si vous comptez afficher beaucoup d’animations (et puisque vous concevez votre application avec Animate c’est sans doute le cas), ne cherchez pas : la seconde solution est de loin la meilleure. Néanmoins attention : choisir le mode GPU provoque certains dommages collatéraux qu’il est facile d’éviter si vous en êtes conscients avant de commencer à travailler :

  • Vous ne pouvez pas utiliser les filtres d’Animate (flou, ombre portée, contraste…) qui seront en effet ignorés avec ce mode de rendu, que vous les appliquiez manuellement depuis le panneau des filtres ou dynamiquement en ActionScript. Si vous en avez absolument besoin, choisissez le mode CPU, ou bien essayez de les reproduire autrement (l’ombre peut être un MovieClip dupliqué, la teinte peut être changée manuellement…)
  • Vous devrez éviter la plupart des modes de fusion (obscurcir, superposition, etc.) qui ne sont pas pris en charge par ce mode de rendu. Heureusement, le mode produit fonctionne, et c’est sans doute le plus pratique.
  • Quelques autres restrictions existent, elles sont listées ici.

Gestion de la mémoire

Vous devez comprendre comment le player gère la mémoire et respecter en conséquence quelques pratiques qui feront une grande différence dans la fluidité de vos animations.

Il y a dans Animate un « garbage collector », un camion poubelle qui passe un peu quand ça lui chante pour « ramasser » et « jeter » les objets qu’il considère comme n’étant plus utilisés. Exemple : un bitmap précédemment chargé qui se trouve désormais en dehors de la zone visible de votre écran sera jeté aux oubliettes au bout d’un délai variable, qui dépend en partie des performances de l’appareil.

Un comportement plutôt logique et vertueux, mais dont l’automatisation n’arrange pas toujours nos affaires. Par exemple, si vous souhaitez ré-afficher ce bitmap sur la scène peu après l’en avoir fait sortir, vous vous exposez à ce que le player doive le recharger dans le cas où les éboueurs seraient passés prématurément. Cela peut

devenir embêtant si l’objet en question (bitmap ou autre) est destiné à disparaître puis réapparaître régulièrement. Car plus l’objet est lourd, plus il mettra longtemps à être chargé dans la display list, la liste des objets affichés. Un
temps de chargement qui peut nuire à la fluidité de vos animations, puisqu’il se traduit parfois par un temps de latence inhabituel sur une image.

pic_displaylist_adobe_scout
Le pic vert correspond au chargement d’un gros bitmap dans la display list. Le fait qu’il dépasse la ligne rouge, qui représente le frame rate, indique que ce chargement a ralenti l’animation sur une image. Mesure réalisée avec Adobe Scout.

 

Exemple concret : sur Petites Choses le joueur fait défiler un décor urbain, composé en partie d’immeubles. Ces immeubles, qui sont des bitmaps individuels, entrent et sortent régulièrement de l’écran, au gré de l’utilisateur.

Initialement, j’ai voulu créer autant de bitmaps différents qu’il y avait d’immeubles. Un choix malvenu, puisque le défilement du décor était régulièrement interrompu par des temps de pause dus au chargement incessant des bitmaps. La mémoire de l’appareil était en effet trop limitée pour conserver chaque immeuble en mémoire, ceux-ci étaient donc déchargés par le garbage collector dès qu’ils étaient en dehors de la scène, et rechargés lorsque l’utilisateur revenait en arrière.

La solution consiste alors à réutiliser au maximum les mêmes objets. En effet, un même objet dupliqué 100 fois sera bien moins gourmand que 100 objets chargés une fois. Évidemment, l’utilisation d’un seul objet limite la créativité. Mais sans aller jusque là, essayez de n’utiliser, dans un cas comme celui-ci, que 3 ou 4 objets différents que vous dupliquerez et transformerez directement dans Animate (en changeant leur taille, en les retournant, en jouant sur la teinte…) plutôt qu’une vingtaine préalablement modifiés dans Photoshop. Faites des tests avec Adobe Scout pour trouver le bon compromis, selon votre appareil et le nombre d’objets à charger, jusqu’à ce que vous ayez convenablement limité les temps de latence. Je vous conseille de ne pas faire vos tests sur un appareil trop récent, qui risquerait par ses performances de masquer les lacunes rencontrées par la majorité des utilisateurs.

immeubles1
Afficher plusieurs objets très similaires n’est pas une solution appropriée
immeubles2
Limiter le nombre d’objets et les dupliquer puis transformer dans Animate permet d’optimiser la mémoire, mais aussi la taille de votre application.

 

Parallèlement, pensez à décharger manuellement la mémoire au moment opportun : faites un removeChild lorsqu’un objet n’est plus utilisé (ce qui ne garantit pas qu’il sera déchargé de la mémoire immédiatement mais indiquera au player qu’il peut l’être), et auparavant stoppez toutes ses animations en cours, arrêtez ses écouteurs, etc. Plus vous allègerez la mémoire de vous-même, et moins le player aura besoin de recourir à son garbage collector.

Ces précautions vous permettront de limiter mais jamais d’éviter complètement ces brefs moments de lag dus au chargement d’objets lourds. Essayez donc de les contrôler au maximum : ajoutez vos objets au moment le plus approprié, là où cela ne perturbera pas l’utilisateur. Pensez à ajouter certains objets à la scène en avance, même s’ils ne seront pas visibles immédiatement. Il vaut mieux concentrer les ralentissements au même moment, quitte à perdre quelques secondes sur un écran de chargement, plutôt que de les disséminer de façon anarchique.

Bitmaps vs. vectoriel

Si j’ai pris comme exemple le chargement de bitmaps pour illustrer le comportement de la mémoire, c’est parce qu’en opposition au vectoriel ils pèsent bien plus lourds. Ils n’ont d’intérêt que lorsque vous souhaitez un rendu graphique particulier, que l’on ne peut pas obtenir en dessinant directement dans Animate ou Illustrator. Le choix entre l’un ou l’autre dépendra évidemment de votre parti pris graphique. Ces deux techniques ont chacune leur intérêt, et quelques spécificités dues au passage sur tablettes et mobiles :

Le dessin vectoriel, outre son poids quasi-nul, a l’immense avantage de s’adapter à la taille de l’écran puisque le rendu est calculé en temps réel. Vous n’aurez donc pas besoin de prévoir plusieurs versions de vos graphismes et animations. La qualité est garantie, quelle que soit la résolution. Toutefois, le pendant de cette particularité est un temps de calcul sans doute légèrement supérieur lors de l’affichage de chaque image. Un ralentissement presque imperceptible, mais qui peut se faire sentir si vous avez de nombreuses formes vectorielles complexes.

A ce propos, évitez les dégradés en vectoriel, qui selon mon expérience sont très mal gérés sur ces appareils. J’ai constaté un bond incroyable dans le frame rate, juste pour un dégradé riquiqui transformé en couleur unie.

Enfin, j’ai remarqué un problème d’affichage qui semble spécifique aux écrans Retina : l’apparition d’artefacts à l’intérieur d’aplats de couleurs vectoriels. Après divers tâtonnements, il s’avère que ce bug d’affichage est lié à la rotation du MovieClip qui contient la forme ! Si la rotation est appliquée directement sur la forme, il n’y a pas ce problème. Dans la mesure du possible, essayez d’en tenir compte.

artefact
Non, pas de problème d’acné pour ce personnage de J’apprends à lire l’heure, l’apparition inopinée de points blancs provient de la rotation d’un des MovieClip parents.

 

Quant aux bitmaps, terme qui recouvre en fait tous les formats d’image non vectorielle (jpeg, png, calques psd…), ils vont eux aussi s’adapter à la taille de l’écran. En réalité, c’est leur conteneur, la scène, qui est redimensionnée selon l’écran de l’appareil, et donc étire ou réduit ses objets enfants. Un comportement qui oblige à se poser quelques questions : si vous avez conçu des images en haute définition, destinées à s’afficher sur des écrans Retina d’une résolution de 2048 x 1536 pixels (iPad), il n’est pas forcément judicieux d’afficher les mêmes images sur des écrans beaucoup plus petits, comme celui de l’iPhone 4 (960 x 540 pixels). Outre le fait que vous allez surcharger la mémoire de l’appareil pour rien, vous vous exposez également à un rendu très moche à cause de la mauvaise gestion du redimensionnement des images par Animate. S’ils sont trop réduits, vos bitmaps vont scintiller. La meilleure pratique est donc de prévoir au moins deux tailles pour chaque image. Redimensionnez vos bitmaps dans Photoshop, et importez-en deux versions dans la bibliothèque d’Animate. Vous chargerez l’une ou l’autre selon la taille de l’écran.

oiseau_def
L’oiseau de droite, en basse définition, s’affichera pourtant mieux sur les petits écrans et monopolisera moins de mémoire.

 

Comme vous ne pourrez jamais prévoir une taille d’image pour chaque résolution d’écran, atténuez les problèmes de redimensionnement en activant l’anti-aliasing dans Animate (« autoriser le lissage » dans les paramètres de compression). Ainsi vous n’aurez que très peu de perte de qualité sur des bitmaps légèrement redimensionnés. Je ne compte plus les animations dans lesquelles l’absence de ce paramètre vient gâcher un univers graphique pourtant soigné…

Enfin, je vous conseille de gérer manuellement le taux de compression de chaque bitmap que vous importerez dans Animate. Selon les caractéristiques de votre image, un taux à 50 % pourra en effet suffire, là où un autre bitmap nécessitera
au contraire une compression minime. Un procédé un peu fastidieux mais moins hasardeux qu’une compression fixe, et qui peut vous faire gagner plusieurs mégaoctets au bout du compte.

Compatibilité entre les appareils

Si vous prévoyez de rendre votre application compatible tablettes ET smartphones, vous avez donc compris qu’il allait falloir adapter l’affichage selon le type d’appareil. Outre la gestion des différentes résolutions de bitmaps, nous avons aussi évoqué la nécessité de modifier la taille des boutons,
ou des textes. Car le doigt et les yeux de l’utilisateur, eux, ne sont pas redimensionnés avec l’écran ! Il existe différentes façons de détecter les caractéristiques de l’appareil avec Air, grâce à la classe flash.system.Capabilities.

Dans le cas où vous souhaiteriez adapter vos bitmaps à la définition de l’appareil, il vous suffit de détecter la résolution de celui-ci et charger les images correspondantes.

Mais en ce qui concerne la gestion de la dimension des textes et boutons, ce qui importe c’est de connaître la taille physique de l’écran. Pour cela, ne tenez pas uniquement compte de la résolution : il existe des tablettes dont la résolution est inférieure à celle de certains smartphones. Je vous conseille plutôt de comparer cette résolution avec le nombre de pixels par pouce, afin d’en déduire la taille de l’écran en nombre de pouces, qui est une mesure « humaine » concrète. Pour ma part, je considère qu’un appareil est un smartphone en dessous de 5 pouces, j’affiche donc des boutons et textes plus gros.

En plus de la taille, vous allez également vous trouver face à un problème lié aux différentes proportions des écrans : on passe ainsi d’un format 4/3 avec l’iPad à un format nettement plus allongé sur l’iPhone 5 ou beaucoup de tablettes Android. Il existe alors deux bonnes pratiques, l’une pouvant être complémentaire de l’autre :

  • Prenez comme base le format le plus compact (4/3), c’est à dire que votre scène fera par exemple 1024 x 768 pixels. Vous y concentrerez donc tout le contenu utile (boutons, textes), afin que vos éléments importants soient toujours affichés, quel que soit l’appareil. Mais attention : sur un écran plus large, le player affichera ce qui se trouve à l’extérieur de la scène, sur les côtés (c’est son comportement par défaut, même si vous pouvez le changer). Prévoyez alors des marges qui n’affichent rien d’essentiel, mais qui donneront l’impression que vous exploitez toute la surface de l’écran. Lorsque vous faites sortir un élément de la scène, pensez à le déplacer en dehors de ces marges.
  • Vous pouvez également placer vos éléments dynamiquement, en tenant compte de la zone réellement affichée. C’est une bonne solution pour les objets indépendants tels que boutons de navigation.

zone_utile
Suivant la même logique, évoquons maintenant la question du son.

Gestion du son

D’une manière générale, je n’ai pas vraiment relevé de différence dans la gestion de l’audio par Animate dans une application mobile ou un navigateur web. Néanmoins, à l’instar de l’affichage, il existe tout de même quelques points qui méritent d’être évoqués lors de cette transition d’un support à l’autre.

Tout d’abord, pensez que les tablettes et mobiles ont un son pas terrible (même si des progrès spectaculaires ont été réalisés). Ben oui, on ne peut pas espérer être à la fois de plus en plus plat et économe en énergie tout en résonnant comme une chaîne Hi-Fi, dont la qualité sonore tient – entre autres – à son encombrement. Aussi, bien que l’utilisateur ait la possibilité d’améliorer l’audio en branchant un casque ou une paire d’enceintes sur sa tablette, partez du principe que vos sons sortiront directement de l’appareil et doivent être agréables malgré tout. Faites des essais et des corrections éventuelles. Pensez notamment que vos basses seront moins audibles, il peut être utile de les booster un peu.

Mais vous pouvez aussi tirer parti des caractéristiques du matériel, par exemple en utilisant le bouton mute sur les appareils Apple. Cet interrupteur, destiné à passer le mobile en mode silence, existe aussi sur iPad. Pour ma part, je trouve que son comportement normal est de couper tous les sons, et pas seulement celui de la sonnerie. C’est pourquoi j’en tiens compte dans mes applications. Mais beaucoup d’autres ne le font pas (parfois par choix), si bien que j’ai constaté le problème suivant : des utilisateurs m’ont écrit pour se plaindre qu’il n’y avait pas de son dans Petites Choses… En fait c’est parce que le bouton mute de leur iPad était activé, mais comme le reste de leurs applications n’en tenait pas compte, ils rencontraient ce problème pour la première fois ! Si vous décidez d’utiliser ce bouton, je vous conseille d’indiquer par un pictogramme que le son a été volontairement coupé, cela mettra la puce à l’oreille (ah ah) de l’utilisateur distrait.

Mis à part ces quelques réflexions, la gestion du son ne change pas spécialement par rapport aux animations pour le web, d’un point de vue technique du moins. Car le passage vers le monde des applications peut être l’occasion d’aborder le sound design différemment. Pourquoi ne pas moduler l’audio selon l’ambiance sonore autour de l’utilisateur, grâce au micro ? Multiplier les notes de musique selon le nombre de doigts sur l’écran, grâce au multitouch ? Utiliser l’accéléromètre pour changer l’intensité d’une note ? Mais là, je m’égare…

Vous aviez l’habitude de vous adapter aux navigateurs ? Vous allez maintenant devoir vous adapter aux différents OS.

S’adapter aux OS

Un des nombreux avantages de Air, c’est sa capacité à publier une même animation Animate en application iOS ou Android sans vous obliger à reprendre le développement à zéro. Théoriquement, vous n’avez même pas besoin de changer une seule ligne de code de l’un à l’autre. Néanmoins, certaines différences matérielles et logicielles méritent que l’on s’attarde sur quelques améliorations qui feront de votre application géniale une application parfaitement géniale sur chaque OS !

Quitter convenablement l’application

Lorsque vous fermez une application sur iOS, elle reste présente dans la mémoire mais se fige automatiquement. Ce qui signifie que vous la retrouverez telle que vous l’avez laissée à la prochaine ouverture (sauf si vous la quittez manuellement). C’est du moins son comportement par défaut, que vous pouvez modifier avec Air : il est possible de forcer une application à s’arrêter complètement dès que vous pressez le bouton « Home » (pour l’obliger à reprendre du début à chaque ouverture), ou à l’inverse de continuer à jouer l’audio même en tâche de fond. Mais sans intervention de votre part, les animations comme l’audio seront juste suspendus, jusqu’à ce qu’elle revienne au premier plan.

Sur Android, le comportement par défaut est différent : lorsque vous fermez une application Air elle continue à se jouer en arrière plan, ce qui signifie que vous continuerez à entendre l’audio… ce qui est plutôt perturbant, surtout lorsque l’utilisateur reçoit un coup de fil. Pour forcer l’arrêt lorsque vous quittez, vous devrez écouter l’événement DEACTIVATE :

NativeApplication.nativeApplication.addEventListener( Event.DEACTIVATE, _onDeactivate) ;

Puis dans votre fonction onDeactivate, forcez l’arrêt comme suit :

private function _onDeactivate(e:Event):void {
NativeApplication.nativeApplication.exit() ;
}

Enfin, pour que l’application se coupe lorsque l’utilisateur reçoit un appel sur son smartphone, cochez READ_PHONE_STATE dans l’onglet des autorisations, lors de la publication.

params_android4

Utiliser le bouton « retour » d’Android

Sur les appareils Android, vous disposez en plus du bouton « Home » d’un bouton « retour » et d’un bouton « paramètres« . S’ils ne sont pas présents matériellement, ils s’affichent en bas de l’écran. Je vous conseille de vous servir au moins du bouton « retour ». L’utilisateur d’Android a l’habitude, en effet, de revenir en arrière de cette manière. Or, si ce bouton n’est pas pris en charge par votre programme, le fait d’appuyer dessus fermera l’application. Un peu frustrant pour celui qui voulait juste revenir à votre menu principal…

Pour exploiter ce bouton, écoutez l’événement KeyboardEvent.KEY_DOWN :

NativeApplication.nativeApplication.addEventListener( KeyboardEvent.KEY_DOWN, _handleKeys ) ;

Et dans la fonction _handleKeys, stoppez la propagation de l’événément (sans quoi votre application se fermerait quand même) PUIS appliquez le comportement
désiré :

private function _handleKeys(event:KeyboardEvent):void {
if( event.keyCode == Keyboard.BACK ) {
event.preventDefault() ;
event.stopImmediatePropagation() ;
_retourMenu() ; // la fonction qui fait revenir au menu précédent, par exemple.
}
}

Apple vs. Google

Outre ces différences matérielles et logicielles, vous voudrez peut-être vous adapter à la plateforme qui distribue votre application. Par exemple,
si vous affichez un lien pour noter votre application, le lien devra pointer vers le bon store. Ou alors, vous souhaiterez vous conformer à des « lignes éditoriales » divergentes : rappelons par exemple qu’Apple est assez pointilleux sur certains critères, et parfois porté sur la censure, alors que Google ne modère pas (encore) les applications Android.

Là aussi la solution consiste en un bout de code très simple, qui vous permet de détecter l’OS et d’adapter le programme en conséquence :

private function _isAndroid():Boolean {
var result:Boolean=false ;
result = Capabilities.manufacturer.indexOf('Android') &gt ; -1 ;
return result ;
}

Ensuite :

if (isAndroid()) {
// splash screen qui montre une pomme aux seins nus et un Steve Jobs démoniaque
}

Conclusion

N’étant pas à proprement parler un développeur et n’ayant encore que peu d’applications à mon actif, vous comprendrez que ces quelques conseils ne sont que le fruit des observations que j’ai pu mener jusqu’ici. Il existe certainement beaucoup d’autres réflexions à mener lorsqu’on décide de passer d’Animate pour web vers les applications. J’espère néanmoins que cette liste non exhaustive vous aura fait gagner un peu de temps. J’attends avec impatience vos commentaires, afin d’enrichir cet article au fur et à mesure.

Enfin, je vous invite à lire ces deux articles complémentaires : Publier une application mobile avec Adobe Animate et Air – Tutoriel pas à pas, et Lancer et promouvoir une appli mobile sans budget marketing.

9 réponses à “Application mobile avec Animate (Flash) – quelques règles à observer”

  1. Anne

    Bravo pour cet article ! Super clair, même pour une super néophyte et très encourageant ! Merci !

    Répondre
  2. cyril

    Merci pour ces articles qui sont d’une aide certaine et agréablement bien rédigés.

    Petite question : quelle est la marche a suivre pour sauvegarder des préférences, enregistrer des données, sauver un score etc… on parse du XML comme habituellement ou bien il existe d’autres méthodes ?

    Merci bcp !

    Répondre
    • Benjamin Gibeaux

      Oui tout à fait, on peut écrire dans un XML qu’on stocke dans le applicationStorageDirectory, c’est la méthode que j’utilise, mais on peut aussi embarquer une base de données (jamais fait mais je sais que c’est possible).

      Répondre
      • Jimmy

        Avez vous trouvé comment faire pour tester en local avec une base de données MYSQL lors de conversion de swf vers application de Android ?

        Répondre
  3. daniel baudry

    Merci pour les infos. Je viens seulement de les lire après avoir arrêté la programmation AS3, ne voyant pas de possibilités d’exporter mes productions techniques sur tablettes et mobiles.
    Ceci me réconforte. Toutefois, pour des développements très lourds (industrie, par exemple), la version d’essai serait de 2 ou trois mois, cela me permettrait de bien viser mes objectifs et les capacités de l’outil.

    Répondre
  4. Abdelfatteh Saied

    Merci , conseils précieux.
    Question :
    Lequel est plus puissant : Animate cc ou Android Studio ?
    Merci

    Répondre
    • Benjamin Gibeaux

      Bonjour, je ne connais pas du tout Android Studio et en quoi ça diffère de Animate CC, mais je suppose que la préférence pour l’un ou l’autre de ces outils va dépendre principalement de la forme désirée de l’application. L’intérêt de Animate résidant dans le fait de pouvoir dessiner et animer des éléments. Mis à part ça, l’atout de Animate c’est aussi de pouvoir publier d’un seul coup votre application pour Android et iOS !

      Répondre
  5. haimeur

    bonjour benjamin merci beaucoup pour toute les explication !
    mais j ai un petit soucis quand je integre le moteur air dans l’application est je publie application et je test mon application sur mon telephone quand je lance application ce ferme et me di que application s’est arrete si je integre pas le moteur dans l’application est j ‘ai installer le air depuis android ca marche merci pour toute vos reponse

    Répondre

LAISSEZ UNE REPONSE

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *