Le développement Cross plateform abordé au BarCamp

Un BarCamp, comme organisé par barcamp.org, est une réunion technique autour d’un thème spécifique.

Le jeudi 16 septembre 2010, Quang-Hai PHAN et Sylvain MAUCOURT, de la société Deveryware, ont organisé une session sur le thème « Cross Platform Mobile App Development ». L’objectif est de faire se rencontrer des acteurs du développement mobile pour discuter de la possibilité de factoriser les développements malgré la diversité des plateformes mobiles. Vous comprendrez que Android n’était donc pas le centre des débats mais un de composants.

Quoi que chacun ait pu en retirer, l’ambiance était excellente. Les débats étaient assez relevés grâce à des intervenants de qualité. Il y avait de très motivés représentants de start-up, des représentants de sociétés de service informatique et des éditeurs plus âgés que les start-up. Certains se lançaient dans l’activité depuis zéro, d’autres avaient un pied dans une plateforme, et les derniers venaient évaluer la taille de la marche pour passer du web au natif. Et ce public hétérogène a amené une vraie diversité aux discussions. Il y avait une répartition entre vulgarisation et technique pure assez équilibrée pour permettre à tout le monde de se comprendre. Et un indicateur de qualité de la réunion, la quasi absence de troll, seules quelques rares pointes d’humour à chaque fois bien placées. Il ne manquait que l’apéro à la fin pour que les estomacs ne vident pas la salle à partir de 21h. :P

Au niveau du déroulement, aucune présentation ni aucun thème n’étaient défini à l’avance. Le plan de la séance a été débattu en début de celle-ci.

Organisation de la séance

Un brainstorming a été mis en place pour savoir quels étaient les mots clefs qui devaient être abordés, en voici la liste :

• Framework
  • Nom de frameworks
  • Approche
  • Retours d’expérience
  • Ergonomie
  • Testing
  • Performances
  • Appli mobile VS appli native
  • HTML 5
  • Portabilité
  • Conception, modélisation
  • PGCD ?

Je dois dire qu’il y en avait 2 ou 3 de plus sur le paperboard, mais j’étais pris dans la discussion et j’ai oublié de les noter.

Il a été décidé de se centrer sur le Framework, et une ligne de réflexion est apparue :

• Framework
  • Pourquoi ?
    • Le besoin
    • Les moyens
  • Le marché
    • FW natif
    • FW web
  • Feedback
    • Perf
    • Ergonomie de l’application à développer
    • Fonctionnalités
  • Testing

Pourquoi se lancer dans le Cross Développement ?

De façon assez surprenante, tout le monde voulait avoir des retours d’expérience sur les frameworks sans confronter par avance l’approche de chacun de l’utilisation de ce type d’outil. Chacun savait pourquoi il se renseignait, pensant que tout le monde voulait un environnement de développement multi plateforme pour les mêmes raisons. Or, on se rend compte que plusieurs profils de projets se démarquaient:

1. Le projet existe sur une plateforme et doit être porté

Actuellement, le système le plus rentable financièrement est l’iOS d’Apple. Une grande majorité des applications commence pour cette cible et s’ouvre ensuite aux autres. Les deux plateformes ciblées ensuite sont Android et BlackBerryOS. Certains intervenants notaient un changement de situation et de plus en plus de demandes d’abord sur Android puis vers les autres, souvent pour des questions de coût.

1. Le projet a peu de moyens et cherche à savoir ce qui lui coutera le moins cher

C’est le cas typique des start-up innovantes. Elles se retrouvent avec peu de moyens mais des fortes ambitions pour leurs nouvelles technologies. Leur objectif est d’atteindre la plus grande visibilité possible, et donc le maximum de cibles possible.

1. Le projet n’est pas encore chiffré, mais il cherche à être le plus efficace possible

Ce dernier type est souvent l’œuvre de sociétés plus grandes, aux moyens plus larges. Elles voient un potentiel d’amélioration dans l’usage de la mobilité. Elles ont des moyens de veille assez intéressants et pourraient se permettre d’avoir des ressources dédiées à chaque système. Mais elles cherchent à avoir une démarche cohérente pour tous les systèmes.

Les acteurs présents à ce DevCamp étaient tous animés par une envie d’innovation. Et les questions de l’usage d’outils CrossPlateform étaient, au final, assez proches :

• Retour sur investissement
• Visibilité
• Fonctionnalités
• Maintenabilité

Ce sont des problématiques propres à de vrais projets informatiques matures. On peut donc penser qu’une vison CrossPlateform d’un projet mobile est ou doit devenir une preuve de maturité du projet. Si un projet n’est pas mature, pas ambitieux ou à valeur de test, une seule plateforme cible pourrait suffire.

Le marché

Les personnes présentes avaient peu ou pas utilisé de framework de développement multi-plateforme natif, par contre les outils web étaient mieux connus. Au final plusieurs noms sont quand même ressortis.

Pour les frameworks natifs, ont été cités :

1. Titanium (de Appcelerator)

Titanium est un framework libre qui permet, à partir de code orienté web de générer des applications natives pour iPhone et Android. Il permet notamment d’accéder grâce à une API aux éléments d’interface et aux fonctionnalités système de chaque OS.

www.appcelerator.com/

1. PhoneGap

Ici aussi, voici un environnement open source. Cette fois-ci outre iPhone et Android, PhoneGap supporte BlackBerryOs (je ne sais pas si la version 6 est comprise), Symbian et WebOS. Ici aussi, les applications sont développées en langage web. Cet environnement propose de debugger les applications de façon très fonctionnelle.

Les retours lors de ce BarCamp étaient très bon sur ce framework.

http://www.phonegap.com/about

1. Elips Studio (de Open Plug)

Proposé par OpenPlug, récemment racheté par Alcatel, Elipse permet de créer du code spécifique à chaque plateforme depuis un code commun en Flex. Il s’intègre d’ailleurs aux outils d’Adobe et propose plusieurs licences. Ils supportent iOS, Windows Mobile (< 6,5), Android et Symbian.

http://www.openplug.com/index.php/products/elips-studio

1. Flash/Flex (de Adobe)

Inutile de présenter Flash/Flex. Si on passe outre les éternelles questions de performances, on peut noter qu’Adobe proposera d’ici très peu de temps la version finale de son outil de compilation pour iPhone. Ainsi, on trouvera les applications sur les systèmes disposant d’une machine Flash (WindowsMobile 7, Android, Symbian et Maemo) et iOs (iPhone et iPad).

http://www.adobe.com/products/flashplayer/

1. Unity

Unity est un moteur 3D impressionnant puisqu’il est disponible sur des plateformes très hétérogènes : Direct3D, OpenGL, Wii, iPhone, Android et navigateur web.

Ici, il ne restera plus qu’à faire les boites de dialogue natives.

http://unity3d.com/

1. Unreal Engine ?

Je rajoute cette librairie qui est disponible pour iOS et qui est annoncée en portage sur Android. A terme c’est tout un framework pour faire de la 3D d’excellente qualité. Mais surtout utile pour les jeux ou la réalité augmentée.

http://www.knowyourmobile.com/mobile-games/mobilegamesnews/598275/unreal_engine_3_sdk_for_ios_and_android_coming.html

Pour les frameworks web, ont été cités :

1. JQueryMobile

JQuery Mobile est la version dédiée aux écrans de smartphones du célèbre framework JavaScript JQuery. La première version stable n’est pas encore disponible. Le projet étant né au début de l’été 2010, les premiers résultats sont attendus pour fin 2010, début 2011.

De nombreuses attentes pèsent sur JQueryMobile de part l’excellente réputation de la version Desktop. Les premières impressions écran venant des versions beta semblent être à la hauteur. Il est intéressant de voir que des designs spécifiques sont prévus pour chaque type d’appareils (smartphones, tablettes…).

Plus d’informations sur http://jquerymobile.com/

A noter, il existe déjà un plugin JQuery pour les écrans tactiles : JQ-Touch, elle cible en priorité l’iPhone. Elle a le gros défaut de ne pas utiliser une version optimisée de JQuery.

http://www.jqtouch.com/

1. Aptana Studio

Aptana est un environnement de développement taillé pour les technologies Web. Il offre l’avantage d’être open source. Il offre des plug-in permettant de l’intégrer directement dans Eclipse.

Sans être fait pour le mobile, il peut s’avérer être un outil intégré complet pour cet objectif.

http://www.aptana.com/

1. Sencha

Sencha est un univers ultra complet. Il va de l’environnement de développement, au débugger de code, en passant par les librairies cross-plateform. Misant sur HTML5, CSS3 et JavaScript, il se veut être un pari sur l’avenir. De plus, il possède des composants dédiés aux mobiles, en plus des composants standards. Il offre aussi des librairies à connecter à d’autres technologies, comme GWT de Google.

A noter qu’il existe deux licences, une pour les projets commerciaux (payante) et une pour les projets open-source (gratuite).

http://www.sencha.com

1. HTML 5

HTML5 est la prochaine version du standard du web pour la description des pages. Actuellement cantonné à du descriptif d’interface, HTML a besoin de Javascript, CSS et autres langages pour faire vivre le web. Cette 5^ème mouture apporte des spécifications de fonctionnalités autres que de la simple interface. Si les premiers débats portaient autour de la gestion de codecs audio et vidéo pour gérer les médias sans ajout de code, actuellement, les discussions portent sur les APIs pour accéder aux fonctionnalités bas niveaux tels que les fichiers ou le GPS par exemple. Une autre fonctionnalité très importante que HTML5 apporte c’est la possiblité d’accéder hors ligne au contenu. Dans le cas des web applications pour les smartphones, c’est vital.

Enfin, si le standard n’est pas encore complètement défini, Apple et Google, par les navigateurs par défaut de iOS et Android, prouvent qu’ils croient en cet outil en implémentant aussi vite que possible les fonctionnalités dans le moteur de rendu web WebKit.

Une information résumée sur http://fr.wikipedia.org/wiki/HTML5

1. GWT

Les outils Web de Google sont devenus une arme absolue pour le web. Ils permettent de développer en Java, avec la puissance de ce langage, pour générer du code JavaScript optimisé et cross-plateforme. Sans être réellement dédié au mobile, on remarquera que Google Maps, développé avec GWT, fonctionne très bien sur un Nexus One.

On voit que le débat entre WebApps et applications natives a encore de beaux jours devant lui, chaque solution n’apportant pas la réponse parfaite.

On note toutefois de gros défauts dans chacun par rapport à l’autre. Pour les WebApps, le volume de données à échanger, le peu d’API systèmes accessibles et la réactivité peuvent être un frein. De l’autre coté, la diversité des APIs rend le développement compliqué et la maintenance à mettre en place peuvent faire peur sur la durée de vie de l’application.

Les retours d’expérience

Au milieu de tout cela, quelques outils ont pu être utilisés.

Le concepteur de Elips Studio, présent avec nous, nous expliquait privilégier les outils d’Adobe (sur lesquels sont basés leurs outils) car une grande société veut justement être moteur sur le CrossPlateform. Ils veulent donc les suivre et profiter de cette locomotive.

Une approche a été souvent évoquée, c’est celle d’utiliser les outils CrossPlateform pour gérer le noyau de l’application. C’est en général toutes les fonctionnalités autour de la base de données qui sont ainsi implémentées. Cela permet de venir développer par-dessus une interface utilisateur propre à chaque système, répondant aux habitudes de chaque utilisateur.

Pour rester dans les problématiques d’UI, un participant notait avoir réalisé deux projets natifs en parallèles. A chaque fois, les cibles étaient les marchés iOS et Android. Dans le premier projet, toutes les interfaces étaient basées sur le modèle de iOS sans bouton système. Dans le deuxième, chaque cible avait son interface propre, avec notamment l’introduction des boutons des téléphones Android. Le résultat a été sans appel, le projet avec l’UI uniforme s’est très mal vendu sur Android, alors que l’autre n’a pas posé de problème par rapport aux objectifs. Cette démonstration a confronté beaucoup de points de vue sur la nécessité d’éviter d’uniformiser les interfaces. Si les consommateurs font des choix sur leur achat de mobile, mieux vaut les conforter dans leur choix grâce aux applications.

De nombreux reproches ont été faits aux outils basés sur JavaScript. Si les fonctionnalités qui en résultent sont satisfaisantes, ce sont les contraintes en développement qui posent problème. Que ce soit pour les outils qui génèrent du natif que pour du web, la phase de codage pose problème.

En terme de performances, les avis sont assez partagés. En fonction des types d’applications, des cibles et des outils, les résultats peuvent être bien différents. Mais le terme explicite de « boite à bouton » est revenu plusieurs fois pour évoquer le type d’application qui correspondait bien aux outils CrossPlateform que ce soit web ou natif.

Un petit point a permis d’évoquer le développement 3D. Et là Unity semble être une bonne solution. Permettant de développer pour iOS et Android, le framework cherche à s’ouvrir vers d’autres systèmes. Permettant des développements en C/C++, il permet en même temps d’éviter un besoin de formation trop conséquent des développeurs. Soit dit en passant, si des besoins d’interfaces standards se faisaient ressentir en plus du noyau 3D, cet outil semble être assez facile à intégrer dans le code des applications pour chaque système.

Testing

Pour finir, nous avons brièvement évoqué le testing.

Certains framework comme PhoneGap semblent permettre de tester efficacement l’application « à la main ». Les bugs remontés permettent de développer des « bug fixs » pour les autres systèmes en même temps.

Certains ont aussi évoqué avoir utilisé des services de « cloud testing ». Ce sont des sites web basés à l’étranger qui proposent de soumettre l’application à une multitude d’appareils différents et de remonter le log de bug. Si le service ne prend que les fichiers exécutables, il est souvent hébergé à l’étranger. Quid de la sécurité industrielle ?

Ma conclusion

Pour moi, si on en a les moyens, le mieux est d’avoir une ressource par système mais un pilote de projet et une conception multi plateforme. Chaque ressource peut « localiser » l’application pour chaque cible, optimisant l’expérience utilisateur, et le pilotage multiplateforme permet d’assurer les mêmes fonctionnalités à toutes les versions. Ce mode de fonctionnement me parait être le plus qualitatif. En revanche, il est le plus coûteux. Je pense qu’avec une vision à moyen terme (un an ou deux), il est possible d’atteindre une excellente productivité en ayant une phase de conception et une gestion de projet intelligente.

Dans le cadre d’un projet en POC (Proof of concept), la vision multiplateforme semble inutile voire handicapante.

Par contre, pour des projets dont l’interface n’est pas révolutionnaire, ce type d’outils web ou natifs peuvent apporter une réponse rapide pour solutionner le problème.