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

La grosse déception du jour: OpenPlug

Si vous cherchez à créer une application pour plate-formes mobiles, vous êtes sûrement tombé à un moment sur OpenPlug. Dans sa présentation, OpenPlug fait une annonce plutôt accrocheuse: Développez vos applications mobiles comme vous développez vos applications Web. Vu que l'arrivée du Framework Flex Slider (pour mobiles) et de Flash Player 10.1 sur toutes les plate-formes se fait encore attendre, je me suis dit que OpenPlug serait ma solution pour mes dev mobiles.

OpenPlug est pour l'instant en version 3, beta3 (gratuite), ce n'est pas une version finale.

Sur le papier, on écrit du Flex comme dans la vie de tous les jours et on peut compiler en natif, des applications pour iPhone, Android et Windows Mobile (entre autres). Après plusieurs semaines, j'ai enfin pris le temps de tester la bête. Disposant d'un portable sous Android (HTC Magic), je pouvais donc tester sur l'émulateur et en vrai, parfait.

OpenPlug est une "Suite" logicielle comprenant un plug-in pour Flex Builder, divers compilateurs, simulateurs et autres utilitaires. L'installation se passe sans trop de problèmes et on nous demande d'utiliser le Framework "Elips", un framework crée par OpenPlug basé sur une Flex 3.2 d'après ce que j'ai vu sur leurs forums. Parfait, je compilais jusque-là avec Flex 3.2, tout devrais marcher impec.

Ma première application avec OpenPlug

Je crée une application (type Air) en compilant avec leur framework, balance un <mx:Label> comme dans leur application de démonstration. Launch, ouverture du simulateur (qui m'a rappelé le temps où j'avais tenté de faire un peu de J2ME). Une fenêtre s'ouvre avec l'image du portable simulé puis une autre contenant l'application Air et magie, elles font une sorte de fusion qui fait que notre application apparaît dans la fenêtre du téléphone.

Mon Label est bien là, parfait, je vais créer une ComboBox pour voir si elle est interprétée comme les ComboBox HTML (celles du navigateur HTML sous Android s'ouvrent avec une liste plein écran, lisible et scrollable). Alors, j'ouvre un tag, tape "mx:Com" puis Ctrl+Espace pour activer l'auto-complétion et là … rien (enfin si, mx:Component ). Retour en arrière, je reviens sur "mx:", Ctrl + Espace. Surprise, voici ce qui apparait:

Bon, admettons, pas de ComboBox (et pas de DataGrid, certains l'auront remarqué au passage). Mais on a le composant de type mx:List, faisons le test avec un dataProvider contenant quelques objets String. Launch et voilà le résultat dans le simulateur:

Et oui, ce bout de truc au milieu, c'est ma List (les deux "boutons" ont l'air d'être mes boutons de scroll, pour le Batman en bas, je ne sais pas).  Pour ne pas m'arrêter bêtement là, je RTFM (Read The Fucking Manual) que l'on peut trouver sur la partie développeur du site d'OpenPlug. Dans la catégorie API Reference, on a l'équivalent de la Livedocs pour le framework OpenPlug. Bon déjà, c'est dans une sorte de frame, pas très pratique pour la navigation.

Je trouve un package intéressant, le package "openplug.elips.controls" contenant de composants Alert, GroupList, List, HTML, NavigationButtonBar. Je teste avec GroupList et List, même résultat, j'abandonne (j'ai testé avec le fonctionnement classique des composants Flex instanciés en MXML, peut-être faut-il faire autrement). Le <mx:Button> marche correctement, lui, c'est bon signe.

Un déploiement laborieux

Tampis, je tente mon application avec mon Button et mon Label pour voir comment ça rend sur mon Android. Pour le déploiement, ce n'est pas si simple, les explications sont souvent "allez voir ce qui se dit sur le site du SDK d'Android". Après quelques heures pour se battre avec les drivers / erreurs, j'arrive enfin à envoyer mon application (fichier .apk) sur mon mobile.

Je vais écrire un tutorial détaillé sur toutes les manipulations à faire (sous Windows XP et 7) pour ceux qui veulent tester leur application OpenPlug sous Android.

L'application apparaît bien dans mon menu d'application Android. Le lancement est plutôt long (pour une application avec un bouton et un label), environ 15-20 secondes. Au moment où je n'y crois plus, l'application apparait. J'ai bien mon label et mon bouton qui réagit au "click" (au "touch" dans mon cas). Petite victoire en quelques heures, voici un début de résultat.

Utilisation de librairies / code existant

Puisque ce n'est pas pour faire des micro-démos que je teste OpenPlug, je décide d'utiliser ma librairie cartographique que j'ai codé chez Business Geografic (une sorte d'API Google Maps pour le serveur d'application utilisé chez BG) et de la lier à mon projet. La liaison en elle-même se passe plutôt bien, on dirait que cela fonctionne. Je lance le débugger, BIM, erreur d'exécution. Apparemment, la propriété "rawChildren" sur la classe Container que j'utilisais n'est pas présente dans le Framework Flex version Elips. Tampis, je fais un simple addChild() pour voir ce qui se passe.

Ouverture du simulateur et là, grande joie, ma carte WMS apparaît avec les différentes tuiles qui la composent. Bien sûr, la navigation ne fonctionne pas puisque tout est basé sur les interactions souris et pas des interactions "touch". Tampis, je veux voir le résultat sur mon portable ! Maintenant que j'ai tout bien configuré les drivers et autres, je me dit que je ne vais pas y passer la nuit, ça va marcher direct. Je lance la compilation du packaging APK, au bout de 1.5 secondes, ça plante, la compilation n'arrive pas à trouver certaines classes de ma librairie (celles qui l'instancie en MXML avec utilisation du namespace de la librairie).

Après plusieurs tests infructueux et des recherches sur le forum qui ne donnent étrangement rien, je décide de la jouer bourrin et de copier toutes les classes de ma librairie dans mon projet. Pas le temps de packager le projet, j'obtiens des erreurs de compilation. Notamment sur des classes utilisant des tags Embed sur des images. La classe BitmapData quelque chose n'est pas disponible dans le framework Elips. C'est pas grave, je n'avais pas besoin des icônes pour mon application, je supprime toute cela et ça devrait marcher. A ce moment-la, apparaissent d'autres erreurs de compilation que  j'arrive facilement à corriger (ma librairie est pure AS3, pas de référence vers des composants Flex).

Au fur et à mesure que je fusille mon code pour le rendre compatible avec le framework d'OpenPlug, d'autres erreurs apparaissent. Certaines sont presque logiques (évènements liés au click et propriétés liées à la souris), mais d'autres sont tellement basique que je ne m'y attendais pas! Voici quelques perles en ce qui concerne les éléments manquants du framework:

• La classe Sprite existe mais pas la classe Shape!
• Les propriétés "scaleX" et "scaleY" n'existent pas dans leur implémentation
• La classe Matrix est inutilisable (on ne peut pas setter de coefficients, ni transformer des valeurs)
• La classe MovieClip n'est pas implémentée
• La classe Point ne dispose pas des méthodes clone() et distance() par exemple
• …et bien d'autres

Bref, je voulais arriver à compiler mon application donc j'ai tout cassé à grand coups de commentaires et bien sûr (après 30 minutes de prise de tête), mon application ne fonctionne plus du tout.

Des promesses moyennement tenues

Le produit OpenPlug étant en beta, on ne peut pas leur demander un service parfait et c'est normal. Mais pour une version 3 beta3 (qui présage une version payante donc), je m'attendais à plus abouti. En tout cas, ne se voilons pas la face; à moins d'avoir des librairies minuscules qui ne font rien d'extraordinaire, vous ne pourrez pas utiliser votre code AS3/Flex existant. De même, on se rend vite compte que l'on ne peut pas créer les applications mobile comme on crée les applications Flex, il faut se taper l'apprentissage de leur framework.

Alors au final, on a quoi ?

Même si cette critique fait plutôt mal (je suis vraiment déçu par le produit), on peut quand même remarquer le travail fait par les équipes d'OpenPlug. En effet, ils arrivent quand même à compiler de l'AS / MXML en C++ pour ensuite être packagé sur la plupart des plate-formes mobiles. Rien que pour cela, ils méritent une ovation (ils sont les seuls à le faire à ma connaissance à part Adobe et son packageur iPhone).

Seulement, la promesse est alléchante mais on reste un peu sur sa faim. Si je devais utiliser OpenPlug pour le développement d'applications mobiles, je devrais reprendre la plupart de mes développements de 0, ce qui est rageant. De plus, en parcourant la documentation, je n'ai pu voir que très peu de possibilité d'interaction avec les commandes de l'appareil mobile, à vérifier tout de même.

Certaines étapes du déploiement sont plutôt mal documentées, c'est dommage. Je vais publier un tutorial présentant les étapes à suivre pour pouvoir développer sous Android avec OpenPlug (sous Windows en tout cas).

Vous avez essayé? Vous en pensez quoi?

Je serai très curieux de savoir ce que vous pensez d'OpenPlug, et encore plus si vous l'avez testé (et sur d'autres plate-formes qu'Android). N'hésitez pas à laisser un commentaire ou à m'envoyer un mail. Je cherchais une solution dans mes cordes pour les applications mobiles avant l'arrivée de FP 10.1 mais je vais devoir explorer d'autres pistes, notamment du JavaScript (sick)…