Dans cet article, nous allons dresser le bilan du troisième Coding Dojo Bordelais.

Rappel

Le Coding Dojo de Bordeaux a pour but le développement d’une application web et mobile de consommation locale (circuits courts). Celui-ci s’intègre aux projets de développement durable initiés par le conseil général de Gironde et la CUB (Communauté Urbaine de Bordeaux) : http://www.datalocale.fr/drupal7/blog/concours-derniere-ligne-droite

A partir d’une carte, l’utilisateur pourra visualiser les producteurs effectuant de la vente directe, les marchés ou les magasins vendant des produits locaux, et ceci autour de sa position ou par une recherche localisée ou typée (fruits, légumes, viande etc.).

Objectif de la journée

Cette troisième journée a été orientée sur la finalisation de l’appli web et sur le développement des applis mobiles.

Déroulement du Coding Dojo

Après un petit déjeuner copieux, les binômes ont été formés :

• Finalisation de l’appli web
• Appli Android
• Appli en PhoneGap
• Appli en Ionic
• Tests mobiles
• Scrum masters

Finalisation de l’appli web

Au niveau de l’application Web, plusieurs améliorations ont été apportées :

• refonte de l’architecture en quelque chose de plus “node.js-like”
• ré-écriture de tout le code en coffeescript
• ré-organisation des services : - service d’import de données
• service d’affichage de la partie cliente (AngularJS)
• services utilitaires

Le modèle de données MongoDB a aussi été revu en une table unique de POIs (Points Of Interest), permettant dans le même temps de simplifier l’import et la recherche. Il est maintenant possible de rechercher des POIs par un ou plusieurs champs du modèle, mais aussi grâce à la géolocalisation (par exemple, tous les POIs dans un rayon de 5 km).

Bien entendu, nous nous sommes arrachés les cheveux sur les callbacks Javascript, et nous avons donc mis en place l’utilisation de ParallelJS. Nous sommes actuellement en train d’étudier la mise en place de Promises.

Enfin, pour faire tourner tout ça, nous avons installé et configuré Forever, permettant de gérer très simplement la mise en ligne du service (démarrage, arrêt)… mais pour le moment, nous avons encore quelques problèmes à ce niveau, comme par exemple la gestion des logs, qui sont actuellement… inexistants. A suivre, donc.

Appli Android

Pour l’application Android comme pour les applications PhoneGap et Ionic, il y avait 3 objectifs communs :

1. Affichage de l’appli web en webView
2. Affichage d’une carte Google ou OSM
3. Appel de l’API et affichage des POI sur la carte

L’étape 1 (affichage d’une webView avec l’appli web) était triviale car nous n’avions quasiment qu’à créer le projet Android et c’était bon. Plus précisément nous avons :

• Créé un nouveau projet Android
• Ajouté l’élément dans le layout XML de l’activité principale de l’appli
• Configuré cet élément dans le code pour qu’il ouvre l’URL de l’appli web.

Le design “responsive” de l’API ne permettait pas vraiment un bon rendu de l’appli web dans la web view, mais c’était plus un souci côté appli web que côté appli Android.

Pour la partie d’affichage de la carte sur l’appli, on a eu un peu plus de mal. On est parti directement sur l’intégration de la carte de Google Maps dans notre appli, plutôt que la carte OpenStreetMap utilisée dans l’appli web. C’était un choix de facilité puisqu’Android intègre “par défaut” un composant GoogleMaps, contrairement au composant OpenStreetMap. Mais ce n’était pas tout à fait aussi simple que ça, parce qu’avant de pouvoir afficher une carte Google Map il faut :

1. Installer les “Google Play Services” sur le périphérique targeté
2. Générer une clé SHA-1 correspondant au keystore utilisé pour la compilation de l’application
3. Demander une clé d’API pour l’utilisation de Google Maps sur Android avec la clé SHA-1 générée
4. Configurer le projet de l’application pour faire pointer une référence vers le projet “Google play services” utilisé pour la compilation de l’appli
5. Configurer l’application pour lui dire de faire les requêtes Google Maps avec la clé d’API générée par les services Google

Si le premier point n’est pas nécessaire sur un téléphone, il est par contre nécessaire sur un émulateur qui n’a pas, par défaut, les services Google Play qui incluent entre autre le Google Play, Google Maps, etc. On a donc du récupérer l’APK de ces services spécifiques à la version d’Android utilisée par notre émulateur puis les installer (heureusement un simple glisser-déposer suffit pour installer un APK dans Genymotion).

L’étape suivante (génération de la clé SHA-1) a été un peu plus simple, mais le problème est d’arriver à partager cette clé SHA-1 entre les différents membres du projet pour que chacun puisse l’inclure dans son keystore. Là on a eu un peu plus de problème, donc la solution temporaire a été de se passer directement du keystore. Attention, cela pose 2 problèmes :

• Il devient compliqué d’utiliser plusieurs clés SHA-1 pour différents projets avec ce principe, pas très évolutif.
• Il faudra inclure la clé SHA-1 dans le keystore de release puisqu’actuellement on ne l’a inclus que dans le keystore de debug.

Le reste est simplement de la configuration de fichier XML ou de référence vers un projet, pas trop de souci la dessus.

La troisième partie (celle de l’appel de l’API et de l’affichage des POI sur la map) n’était pas très compliquée. Nous avons simplement suivi les étapes suivantes :

• Création d’une AsyncTask permettant de réaliser les appels HTTP asynchrones sans bloquer le thread UI.
• Parsing des infos JSON renvoyées dans des POJO grâce à la librairie de parsing JSON Jackson
• Création du listener qui écoutera les retours des appels HTTP
• Ajout des POI sur la carte grâce au composant GoogleMap intégré à Android.

En résumé, l’appli Android en elle-même n’a pas été particulièrement compliquée à réaliser et en terme de fonctionnalités on se situe autour de 80% terminés. Par contre si la partie Google Play Services était à refaire on y réfléchirait un peu plus pour faire les choses plus proprement, notamment au niveau de l’ajout des clés aux différents keystores et du référencement du projet (privilégier un jar plutôt qu’un réel projet) qui nous a posé quelques problèmes entre les différents IDE (Eclipse vs IntelliJ). Au final, on a passé plus de temps sur des problèmes d’installation que sur du développement pur et dur…

L’environnement Android est facile à appréhender pour une application simple, mais peut vite se révéler complexe pour produire du code de qualité, avec des fonctionnalités plus poussées.

NB : On a utilisé l’émulateur GenyMotion pour tester l’appli tout au long de la journée. C’est beaucoup plus fluide que l’émulateur Android de base, ça fait donc gagner pas mal de temps sur les lancements/tests.

Appli avec PhoneGap

PhoneGap est un framework open-source développé par Adobe Systems et basé sur Apache Cordova. Il permet de créer des applications mobiles pour différentes plateformes (Android, iOS, Windows Phone…) en HTML, CSS et JavaScript.

Les applications qui en résultent sont hybrides, ce qui signifie qu’elles ne sont ni vraiment natives, ni purement basées sur les langages HTML, CSS et JavaScript. Pour chaque plateforme, PhoneGap créé un contrôleur qui servira d’interprète avec la technologie associée. Lors de nos développements, nous avons utilisé un émulateur Android Genymotion.

1/ Le premier objectif est d’afficher le site déjà existant dans une application mobile.

Pour cela nous avons utilisé une application Phonegap classique mais au lieu d’afficher le HTML local à l’application nous avons redirigé la WebView vers l’URL du site existant (action effectuée dans le contrôleur PhoneGap spécifique à Android).

2/ Le deuxième objectif est d’afficher directement la Map OpenStreetMap et de prendre en compte la géolocalisation.

Comme précédemment, nous avons utilisé une application PhoneGap classique mais en utilisant le fichier HTML local que l’on a modifiés pour afficher la carte.

Cela revient à faire une application HTML classique en utilisant, éventuellement, les API PhoneGap pour accéder aux fonctionnalités du mobile.

Après avoir affiché la carte, nous avons essayé d’utiliser la géolocalisation du mobile en passant par un plugin PhoneGap mais sans succès car après de très longues recherches nous nous sommes aperçus que le plugin est déprécié.

En conclusion, PhoneGap est mal documenté et difficile d’accès pour les novices. Ce qui le rend complexe à implémenter mais nous avons pu nous rendre compte de la puissance de son API.

Appli avec Ionic

Ionic est un framework de développement d’application pour plateforme mobile en mode hybride :  application native utilisant une webview pour afficher le contenu HTML.

Ionic est basé sur Cordova (ex : PhoneGap) et AngularJS. Ce framework propose des outils pour faciliter le packaging, les tests ainsi qu’un large panel de composant graphique (flat design).

Durant cette séance de coding nous avions pour objectifs :

1. d’afficher une carte type Google Maps et créer une application packagée pour Android ou iOS
2. de porter la fonctionnalité existante sur l’application web (AngularJS) d’affichage des POI
3. de porter les autres fonctionnalités : recherche, création de POI

L’étape n°1 de création d’une webview pour afficher une carte aurait du être triviale. Cependant nous avons eu quelques difficultés. Tout d’abord, nous n’avons pas réalisé d’application iOS car nous n’avions pas les prérequis Ionic pour cela, notre XCode n’étant pas à jour. Nous nous sommes rapidement rabattu sur le développement uniquement Android avec test via l’émulateur Genymotion.

Pour l’affichage de la carte nous pensions pouvoir rediriger (définition d’une route AngularJS) vers Google Maps mais cela ne semblait pas autorisé.

Nous avons donc repris et nettoyé le template de code généré par Ionic et intégré le code existant pour afficher une carte via les directives AngularJS Leaflet.

• Attention, au regard des informations que nous avons pu glaner sur internet, il semble y avoir des conflits sur prise en compte des inputs entre la carte et le conteneur ionic, mais nous n’avons pas constaté de soucis sur notre émulateur.

Afin d’avancer sur d’autres fonctionnalités, nous avons fait l’impasse sur la prise en compte de la position GPS de l’utilisateur car, lors de tests rapides, cela ne marchait pas : problème d’appel de service cross domaine.

Cf: http://forum.ionicframework.com/t/making-rest-call-from-ionic/1998/4

Nous nous sommes concentrés sur l’appel au service REST pour les fonctions recherche des POI et ajout de POI. En attendant de récupérer des données réelles, les appels de services ont été bouchonné en JS en retournant des données JSON statiques, nous permettant de garder la logique de traitement.

Comme l’application existante était en AngularJS, nous avons pu réintégrer la logique des contrôleurs et des services sans soucis et nous nous sommes concentrés sur l’adaptation du rendu visuel en utilisant les composants Ionic.

Après une journée semée d’embûches, nous sommes arrivés à un résultat visuellement intéressant type mockup (pas d’appel réel) et nous avons pu constaté à quel point il est facile de construire, tester et déployer des applications mobiles avec Ionic.

Cependant compte tenu du paradigme pris par Ionic MVC coté client, nous nous sommes confrontés à un certain nombre de soucis (appel cross domain, redirection) que nous aurions pu traiter habituellement via du code natif.

Nous espérons avoir l’occasion de finaliser cette application et tester le déploiement sur iOS.

Inoic nous conforte quand à la puissance et l’intérêt d’AngularJS ainsi que l’approche de dev multi device “mobile-first”.

Framework de tests mobile

Pour effectuer des tests fonctionnels sur les applications mobiles, nous souhaitions trouver un framework qui puisse les effectuer sur l’ensemble des plateformes mobiles (Android, iOS et Windows Phone). Ceci n’étant pas possible du fait que les frameworks ont besoins de librairies bien spécifiques à chaque système, deux applications en priorité ont été testés :

• Appium
• Robotium

Appium est un framework qui présente l’avantage de pouvoir tester des applications natives ou hybrides sur les systèmes Android et iOS. Pour l’utiliser, il faut télécharger un serveur sur le site officiel qui va attendre le lancement des tests Selenium pour les interpréter et les jouer sur l’environnement souhaité.

Robotium est un framework pour les tests fonctionnels, mais seulement pour les systèmes Android. Pour l’utiliser, il faut télécharger un fichier jar du framework et l’importer dans Eclipse.

Les deux frameworks utilisent Selenium pour effectuer les tests fonctionnels.

Pour tous les avantages présentés, nous avons donc choisi de partir sur le framework d’Appium.

Environnement pour tester ces deux frameworks :

• Genymotion (pour émuler un système Android)
• Serveur Appium
• Eclipse (avec ADT et le plugin Genymotion installés)

Après de multiples tests sur Appium, nous n’avons pas réussi à faire fonctionner le framework. Le problème principal est que nous n’arrivions pas à faire la correspondance entre le serveur d’Appium et la VM sur Genymotion. Quand nous lancions les tests Selenium, aucun test n’était effectué sur la VM. Le serveur arrivait à détecter que la VM était fonctionnelle et dans les propriétés du serveur, toutes les informations concernant l’application étaient bien renseignées.

Dans un second temps, nous avons tout de même testé Robotium, avec quelques tests assez basiques, pour voir s’il était plus simple de faire les tests sur ce framework. Le résultat à été assez rapide à constater puisqu’en 5 – 10 min, nous pouvions déjà lancer des tests fonctionnels sur la VM de Genymotion.

En conclusion, Appium qui présentaient plus d’avantage que Robotium s’est révélé assez compliqué à exécuter et n’a pas donné satisfaction. Au contraire, Robotium s’est révélé assez simple d’utilisation et fonctionnel. Il faudrait se pencher un peu plus sur l’utilisation d’Appium, savoir pourquoi nous ne sommes pas arrivés à faire fonctionner les tests. Sinon, Robotium est une bonne alternative, mais que pour les systèmes Android.

Scrum masters

Un dernier binôme a joué le rôle de scrum master :

• organisation du Coding Dojo
• affectation des tâches et des priorités
• assistance à chaque binôme au cours de la journée

Bien que nous ayons créé ce binôme de scrum masters, nous avons encore eu des problèmes d’interblocage entre les binômes. Par exemple des binômes attendaient la création des services de l’API ce qui les a pas mal bloqués. Il faudra réfléchir à comment éviter à tout prix ces interblocages. Peut-être que le projet n’est pas encore assez vaste fonctionnellement pour que plusieurs binômes travaillent dessus en même temps.

D’autres idées pour les scrums masters du prochain CD :

• timeboxer les US, les faire plus courtes
• faire un mini daily meeting en milieu de journée pour ré-orienter si besoin
• faire une mini rétro en fin de journée après les démos

Conclusion

L’appli web est quasi finie, il reste quelques ajustements à faire sur la recherche. La stack technique est très plaisante et très rapide à travailler. Nous avons eu des problèmes avec Mongoose qui nous bloquait dans les possibilités de recherche et avons dû faire des contournements.

L’écriture d’applis multi OS n’est pas si aisée que cela. Il faut toujours un environnement de chaque OS/devkit et parfois ré-écrire 3 fois une partie de l’appli.

Les frameworks de tests mobile open source/gratuits ne sont pas légions et ne permettent pas de tester tous les OS.

Nous avons décidé de faire des mini Coding Dojos pour finaliser tout cela. Ce seront des sessions d’une heure en fin de journée chaque semaine, sur la base du volontariat. Le but est de faire quelques tâches rapides chaque semaine pour pouvoir présenter rapidement une appli fonctionnelle.

POC du Coding Dojo : https://github.com/mleneveut/eat-local

Appli web : http://coding-dojo.ippon-technologies.net