Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Flex et composants mobile (AIR pour Android – iOS) – Mon approche

Dans mon dernier billet, je faisais une critique des composants adaptés aux mobiles prévus pour la prochaine release du Flex SDK: Flex 4.5 SDK "Hero". Alors certains vont dire que ce n'est pas très juste de critiquer un produit qui n'est pas encore sorti de manière définitive.

Mais le problème se situe plutôt dans la philosophie de ces composants qui est décrite en détail dans les spécifications disponibles sur le site d'Adobe. Pas besoin donc de tester car ces composants vont respecter les spécifications, on sait déjà à quoi s'attendre.

Bref, l'approche de Hero ne me convenant pas, j'ai décidé de créer mon propre framework de composants adaptés aux mobiles, en Flex 3. Dans ce billet (qui sera découpé en plusieurs billets), je vais expliquer la démarche que j'ai suivi, aussi bien au niveau de la réflexion que de la réalisation.

Code en téléchargement?

Quand on lit les forums de la pre-release d'AIR pour Android ou de celui sur le Packager For iPhone, on se rend compte que de nombreuses personnes cherchent un framework avec des composants adaptés aux environnements mobiles. La réponse que donnent les employés d'Adobe modérateurs de ces forums est souvent d'attendre Hero ou de coder en AS3. Il y a donc une vraie demande de la part des développeurs qui, selon moi, ne sera pas satisfaite.

Les développements que j'ai effectué sur les composants pour mobiles font partie de mon travail chez Business Geografic. Ces composants ainsi que les librairies sur lesquelles ils reposent font partie d'un socle qui nous sert à créer des progiciels (propriétaire). En conséquent, je ne peux pas proposer de librairie en téléchargement, ni de snippet de code. Vous pouvez tout de même vous appuyer sur ce que j'explique dans les billets pour créer votre propre implémentation .

Les ingrédients pour un bon framework

Avant de commencer, je vais donner les grands points sur lesquels j'essaie de m'appuyer dans tous mes développements qui sont, pour moi, les "best practices":

• Utiliser au maximum les bases du développement orienté objet
  • Héritage
  • Polymorphisme
  • Objets les plus atomiques possibles (objets simple qui ne font qu'une petite chose et pas tout un process)

• Quand une architecture parait difficile à trouver, regarder du côté des Design Pattern, des gens y ont sûrement déjà réfléchi et trouvé une solution
  • Factory
  • Command
  • Composition

• Ne pas essayer d'optimiser avant qu'il y ait des problèmes de performances
• Avoir le moins de couplage possible entre les classes lorsque celles-ci peuvent être réutilisée / héritées
• Utiliser une communication par évènement (+ ajout des Metadata) pour les processus avant de pouvoir être modulaire
• Pas d'utilisation de framework supplémentaire à Flex qui pourrait nuire à la simplicité du code
• Ne pas créer trop d'abstraction lorsque celle-ci n'est pas utile (pas de possibilité de ré-utilisation des composants par exemple). Préférer un code orienté métier.

Ce n'est peut-être pas grand chose mais une fois appliqués, ces principes m'ont permis de réaliser des développements performants, modulaire et facile à comprendre pour d'autres collaborateurs.

Les résultats attendus

Pour la création d'un bon framework mobile, on peut distinguer plusieurs objectifs:

• Ne pas "niveler par le bas", avoir une ergonomie cohérente avec les interfaces natives de chaque plate-forme. Ce point est sûrement le plus important car il permet à l'utilisateur d'avoir une prise en main directe.
• Permettre de s'interfacer un maximum avec les équipements disponibles sur le portable (GPS, accéléromètre, caméra, …)
• Ne pas simplement prévoir "Android ou Apple", le code doit pouvoir être évolutif suivant les devices mais aussi suivant le type de device (mobile / tablette)
• Respecter le style des interfaces natives
• Les parties spécifiques à chaque device doivent être présentes dans le framework mais invisibles pour les développeurs qui l'utilisent
• Prendre en compte les différences en termes de résolution (DPI / taille d'écran)
• Ne pas penser en terme d'interface Desktop, avoir un démarche orientée mobile / tactile

Les résultats obtenus

Après quelques semaines de développement (disons 2-3 à plein temps), les résultats sont déjà là. Je suis capable de créer facilement une application pour mobile avec AIR 2.5. Celle-ci est cohérente en terme de style et d'ergonomie avec les applications natives de chaque plate-forme. Pour l'instant, seules les devices Android et Apple sont prises en compte mais d'autres devices pourraient assez facilement être ajoutées. Je travaille par exemple sur le SDK BlackBerry fraîchement sorti en beta.

La détection de la device se fait automatiquement, suivant la propriété Capabilites.manufacturer. Cela me permet aussi de surcharger la récupération de cette variable pour pouvoir tester sur mon Android, une application avec le style Apple.

Le développement est complètement agnostique du type de portable utilisé. Ainsi, on ne crée pas une "pop-up Android", on crée une pop-up. Le code va déterminer tout seul si on est sur un Android ou un Apple (ou autre) et instancier la bonne pop-up.

Voici une petite vidéo présentant les résultats obtenus :

Bon alors désolé pour la qualité de la vidéo qui n'est pas top, j'ai fait de mon mieux avec mes petits moyens (vidéo prise avec un appareil photo, parfois calé sur une petite montagne de bouquins ). Dans l'ordre, on peut voir:

• Une application Android créée avec AIR avec un look d'interface native Android (menu, boutons, listes, checkbox, …)
• Ensuite ce n'est pas un crash (on ne le voit pas sur la vidéo mais j'appuie sur le bouton HOME), je repasse sur l'écran d'accueil pour lancer une autre application. Celle-ci partage exactement le même code source sauf qu'elle est forcée "en mode Apple"
• La même application Android en mode Apple avec modification du style (boutons, liste, headers, …) et de l'ergonomie (ActionBar, menu permanent, …)
• La même application Android, lancée sur le simulateur BlackBerry, juste pour vous montrer que cela fonctionne sans aucune modification. On remarquera que je n'ai pas encore modifié le style pour BB, l'application est encore "en mode Apple"

Vous pouvez (parfois rapidement) le voir, tout est encore un peu en chantier. Pour l'instant, il me manque:

• La sauvegarde de l'état applicatif (qui se fera peut-être en ré-utilisant les classes de Flex 4.5)
• Des listes avec smooth-scrolling. Pour l'instant, j'utilise les listes Flex 3 car quand j'ai crée mes composants, Flex 4.5 n'était pas sorti. Flex 3 ne supporte pas le smooth-scrolling par défaut, il se cale toujours sur un élément de la liste lorsque l'on scroll, on ne peut pas avoir un demi-élément affiché ce qui fait un scrolling "haché". Je vais sûrement partir sur le composants Spark List qui gère cela par défaut
• Une version optimisée pour iPad mais je devrais en récupérer un pour le développement courant Novembre
• L'utilisation de plusieurs "set" d'icônes pour différentes devices et différentes résolutions / DPI

N'hésitez pas à réagir grâce aux commentaires !

Dans le prochain billet, une explication sur mes équivalents du View et du ViewNavigator.