Feedbacks des talks présentés à la Droidcon 2014

Pour la seconde fois consécutive, la Droidcon s’est tenue à Paris. Xebia y était et nous vous proposons dans cet article quelques feedbacks sur les différents talks qui mêlaient nouveautés, leaks, et speakers renommés : que de bonnes choses…

Keynote de Microsoft by Alex Danvy @danvy, Fred Le Coquil @flecoqui and Etienne Margraff @emargraff !

Et oui, nous avons aussi été surpris, et pour avoir discuté de cette keynote avec Alexis Moussine-Pouchkine, responsable de la relation développeur en France chez Google, ce choix pour une keynote à la Droidcon peut surprendre !

Alex Danvy évangéliste chez Microsoft nous a proposé un tour d’horizon de tous les outils et technologies pour les développeurs mobiles proposés par la firme de Redmond.

Nous avons notamment vu l’application One Note adaptée pour fonctionner avec les wearable et ainsi pouvoir dicter des notes directement sur sa montre. Alex nous a ensuite parlé de Xamarin, l’outil pour développer des applications mobiles natives (iOS, Windows phone et Android) à partir d’un code en C#. Cellenza organise justement très bientôt un tech event "Xamarin : From Zero to Hero" sur ce sujet. Les démonstrations se sont poursuivies vers Unitiy3D et Cordova. Ces deux outils sont, selon Alex, exceptionnellement bien intégrés à l’IDE du géant : Visual Studio. L’IDE permet notamment, et ça a été démontré en plénière par Etienne Margraff, de faire du live reload et du debugging de code packagé dans Cordova.

Microsoft travaille également sur plusieurs projets Open Source rassemblés sous le label de Microsoft Open Technologie. Les plus intéressants nous semble être Web RTC puis son évolution vers ORTC et les Mobiles Services.

Frédéric Le Coquil nous a également parlé des évolutions de la Xbox et notamment de la mise à disposition pour les développeurs d’une API appelée Xbox One Smart Glass permettant d’interagir avec la Xbox (contrôle, lecture de vidéo, etc.) à l’image d’un compagnon.

Pour les next step Microsoft planche sur l’OmniTouch et sur la StationQ

Une keynote qui était animée par Microsoft mais qui reste quand même proche du mobile et d’Android dans le fond.

Scaling Android Development at Twitter by Jan Chong @lessachu

L’idée de cette présentation proposée par Jan était de faire un retour d’expérience sur les développements de l’application Android de Twitter depuis ses débuts jusqu’à aujourd’hui.

La team s’est formée en 2011 autour de 5 personnes (3 dev, 1 QA, 1 design), le ratio était alors de 9 terminaux iOS pour 1 Android.

Au début de l’application, l’objectif était de #shiptIt. Dès que l’application contient de nouvelles fonctionnalités, celle-ci est livrée à l’image du modèle appliqué pour le web. L’inconvénient est que l’application Android a très vite souffert de bugs et que les cycles de déploiements étaient beaucoup plus long.

La team Twitter est donc passé au #testIt, ce qui a conduit à la création de pas moins de 60 versions d’Android à ce jour. Les phases de déploiements et de mise à jour pour les utilisateurs sont désormais de 3 jours s’il n’y a pas de nouvelles permissions à plusieurs semaines dans le cas contraire. Sur iOS, 90% des terminaux sont à jour en 1 journée.

Les problèmes de développement et de bugs sur la version Android, proviennent, selon Jan, de l’immaturité des environnements de développement, des moyens de test et de release.

Twitter a proposé à ses développeurs de se forcer au monde Android afin de les sensibiliser aux contraintes imposées par les outils et la plateforme.

La QA et les tests s’effectuent sur de nombreux téléphones et les bugs en production sont contournés par la désactivation complète ou partielle de telle ou telle fonctionnalité directement en production à l’aide d’un service qui précise, pour chaque terminal, ce qui doit être désactivé.

Les tests sont assurés par l’ensemble de l’équipe et la participation est encouragée à l’aide de feedbacks positifs, de dons de lots et stickers.

Twitter a mis en place un coding style assurant un code uniforme du point de vue de la forme sur toutes les briques de son application.

Les tests unitaires sont exécutés à chaque changement des sources, les tests fonctionnels sont exécutés toutes les heures sur de nombreux terminaux et les tests de performance sont exécutés tous les jours.

Twitter utilises notamment Robotium, Expresso et UIAutomator.

Les releases sont mensuelles et se découpent ainsi :

Week 1 : développement 

Week 2 : développement

Week 3 : bug fixes et performance

Week 4 : blocage du code et tests

Plusieurs cycles de 4 semaines se chevauchent en décalé pour assurer une meilleure productivité.

Twitter release ses nouvelles applications d’abord en version Alpha puis Beta à travers les services proposés par Google Play.

Byte code manipulation for Android at Groupon by Stéphane Nicolas

Ce talk fait directement écho l’avénement de l’annotation processing sur Android. Beaucoup de bibliothèques dépendent aujourd’hui de ce principe qui intervient durant le build pour préparer les éléments qui vont améliorer le fonctionnement au runtime : citons par exemple Dagger, Butterknife, RoboGuice, IcePick, etc.

Durant son talk, Stéphane est revenu sur la différence entre le dynamic byte code weaving et le static byte code weaving. Le premier correspond à une modification du code alors que celui est en cours d’exécution tandis que l’autre approche n’intervient que dans la phase de build pour ajouter les petits bouts de code qui vont bien. Seule la seconde option est possible sur Android et le weaving peut intervenir :

1. après la compilation javac
2. avant la construction du DEX
3. après la construction du DEX

Les bibliothèques d’aujourd’hui interviennent surtout après l’étape 1.

Afin d’injecter le code nécessaire à l’étape 1, les différentes bibliothèques et notamment RoboGuice reposent sur l’API javassist qui est plus simple et fonctionne sur Dalvik et sur ART, mais pas sur le DEX.

RoboGuice, grâce à cette API est notamment capable de :

• injecter une vue
• injecter une classe
• s’occuper de l’état d’une activité ou d’un fragment, etc.

Le tout est directement injecté dans le code à la compilation.

Même si RoboGuice peut permettre de gagner du temps, les bibliothèques de ce genre sont tout de même à utiliser avec précaution car le debug est souvent très compliqué.

Plus d’information sur https://github.com/roboguice/roboguice et sur https://github.com/stephanenicolas/injects

The making of an app: from having an idea to shipping it by Fabien Devos by @Fabien_Devos

Fabien Devos nous a exposé les key points à respecter lorsqu’une idée se transforme en side project qui est ensuite livré en beta.

D’abord, pour Fabien une idée n’a pas de valeur : en effet, il n’existe pas de place de marché, ni d’application ou site web permettant d’acheter et de vendre des idées, CQFD, c’est donc qu’une idée ne vaut rien… Ce qui est important selon Fabien c’est l’application MVP, et ce n’est pas Minimum Viable Product mais Minimum Viable Prototype. Aussi, la fonction principale d’un MVP doit pouvoir être concrétisée en 48h.

Une fois la key feature développée en un temps très court il faut poser les claviers et revenir aux bases : qu’est-ce que j’ai fait, qu’est ce que je dois encore faire, est-ce qu’il existe des bonnes pratiques ou des patrons de conception pour ce que je veux faire ? Selon Fabien il est plus important de revenir aux fondamentaux pour bien partir plutôt que de se lancer directement dans l’empilement des fonctionnalités. Fabien a illustré ses propos en parlant d’un side project dans lequel il doit traiter des lignes de code : il a donc commencé par revoir comment créer, interpréter puis lire une grammaire avec un parseur.

Le patron de conception pour un parseur c’est :

1. un lexeur qui analyse et transforme les phrases en mots
2. un parseur qui crée un arbre de possibilité
3. un évalutateur qui évalue l’expression

Le deuxième point important est d’essayer de décorréler ce qui change de ce qui persiste : les vues changent, l’algorithme ne change pas.

Quelques conseils :

• ne refactorer le code que quand c’est nécessaire, sinon c’est peut être (sans doute) une perte de temps
• faire des tests unitaires qui assurent que des commits venant de personnes différentes ne cassent pas la solution mais seulement sur les algorithmes qui soutiennent la key feature (pour ne pas perdre de temps)
• ajouter autant que possible (en mode dev) des messages ennuyeux pour se forcer à corriger tel ou tel bug
• si vous travaillez à plusieurs, faire des codes reviews pour que chacun connaisse le code des autres (trouver les bugs critiques, partager la connaissance)
• demander de l’aide (sécurité, big data, hébergement, etc.) parce que nous sommes développeurs, pas omniscient
• parler de son projet, en conférence, autour de soi pour avoir des feedbacks rapide
• livrer même si ce n’est pas terminé : si vous ne vous sentez pas un peu sale à la première livraison c’est que vous avez perdu du temps à peaufiner
• se fixer des deadlines, une conférence, une présentation à des investisseurs, etc. est le meilleur moyen de rester focus sur l’avancement du projet

Fabien a terminé sur ce dernier conseil pour… nous livrer en avant première son application !

Hacked

VIP : http://www.hackedapp.com/vip.html

Projet side développé à deux, soutenu par les outils et bibliothèques suivants :

• Github
• Crashlytics
• Flurry
• Heroku
• Android studio
• ORM Lite
• Butter Knife
• Retrofit

Une belle application pour les développeurs, un grand coup de pub, BRAVO !

Genymotion: the leak session by Eyal Lezmy @Eyal_Lezmy and Charles-Henry Prunier

Dans ce talk nous avons été régalé de nouveautés concernant l’excellent émulateur Android proposé par Genymobile.

D’abord cela fait plus de 4 mois qu’aucune version n’a été déployée. Malgré les 28 000 tests déjà en place, chaque évolution prend du temps.

Il semble que ces 4 mois correspondent en fait à 4 nouveautés que Eyal nous présente en avant première.

1. la gestion du réseau avec la possibilité de simuler une connexion (4G, WiFi, 3G, Edge, GPRS, etc.) avec en prime la simulation de pertes de paquets, disponible à la fin de la semaine.
2. simuler la réception d’un appel ou d’un SMS
3. un ensemble de commande pour lancer, arrêter, relancer et gérer les terminaux virtuels directement depuis le terminal
4. Java API Binocle pour lancer, arrêter et gérer les terminaux virtuels directement depuis Gradle

Génial non ? Tout ça devrait être disponible dans le mois selon Eyal. En tous les cas, nous avons hâte d’essayer !

The secret to build cross platform mobile apps: how the big guys do it by Ali Parr @alistairp at Parse (Facebook)

Ali a commencé sa présentation par mettre en avant que la technologie va de plus en plus vite, le premier vol remonte à 1903, puis le jet power en 1928, puis la première compagnie aérienne qui transporte des particuliers en 1947, puis la lune en 1969 et pour finir le concorde en 1973. Tant d’évolutions technologiques qui n’ont cessées d’arriver de plus en plus vite.

Le changement va plus vite.

Pour essayer de coller à ce modèle, chez Facebook, les développeurs font presque tous les mois des hackathons permettant à chacun d’étayer ses connaissance sur un sujet et pourquoi pas proposer une killer feature (comme le like).

Tous les projets chez Facebook sont rassemblés selon les technologies, tous les projets Android sont rassemblés dans un même dépôt ce qui permet à n’importe quel développeur de l’équipe de soumettre du code pour n’importe quel projet. Si le projet est bien scalable (i.e. : plus il y a de développeurs et plus l’application grandit vite… et bien) et plus le projet a des chances de succès.

Ali a pris l’exemple de Candy Crush qui a vu ses utilisateurs passer de 40 MAU au Q4 2012 à 400 MAU au Q4 2013 et ça a continué de monter.

La performance d’une application et sa diffusion vient également du fait qu’elle soit cross platform. Facebook s’est essayé au cross platform en proposant une application HTML5, considéré alors comme l’alternative idéale au tout natif. Résultat : 1 étoile sur les stores. Facebook a fait machine arrière et est maintenant remonté à 3 ou 4 étoiles.

Au lieu de faire de l’engineering first Facebook fait maintenant du people (client) first.

Faire une application cross platform est très dur, une app se doit d’être :

• rapide
• scalable
• cross platform
• mais le cross platform c’est dur !

Ali n’a pas la solution, et Facebook non plus, mais il nous donne quand même quelques conseils :

• livrer souvent (pour avoir des feedbacks)
• connaitre son public et le comportement des utilisateurs : Ali a pris l’exemple du site OkCupid qui remarque que quand ils cachent les photos des profils des utilisateurs lors d’une journée spéciale les conversations sont plus longues et les rencontres IRL plus fréquentes. Quand les photos sont mises à nouveau la plus part des conversations s’arrêtent. Ce qui nous amène à l’AB testing : proposer quelque chose de différent à plusieurs utilisateurs de façon aléatoire.
• Ali préconise aussi de ne garder en interne que ce qui représente le core du produit : l’hébergement, les notifications, l’emailing, etc. peut être externalisé pour laisser du temps et des fonds au développement des cores features.

Rx-Fy all the things by Benjamin Augustin @Dorvaryn at Novoda

La concurrence et les gestion du flux des données est compliqué commence Benjamin dans son talk sur la programmation réactive sur Android. C’est vrai, des callbacks qui s’empilent des conditions à n’en plus finir contribuent à augmenter la dette technique.

Alors comment faire ?

Benjamin nous a présenté une approche intéressante basé sur l’implémentation de RxJava pour Android. Netflix en est l’un des plus importants contributeurs.

https://github.com/ReactiveX/RxAndroid

Robotium vs Espresso: get ready to rumble ! by Thomas Guerin @Tom404_ at Xebia

Tester une application sous Android n’est pas simple, qui plus est lorsqu’il s’agit de faire des scénarii fonctionnels. Lors de cette présentation Thomas a passé en revue deux frameworks de tests fonctionnels : Robotium et Espresso.

Lors d’un match sous haute tension les coups se sont enchaînées. De l’API simpliste de Robotium contre celle d’Espresso composable et évolutive. Vient alors l’instabilité et la lenteur des tests Robotium face à la rapidité et l’efficacité des tests Espresso. L’issue du match semblait joué d’avance. Mais Espresso qui est toujours en preview n’est pas parfait, des bugs plus que gênants noircissent le tableau. Une version (temporaire) corrigée d’Espresso est disponible ici : https://github.com/tguerin/double-espresso.

Les slides peuvent être consultées en ligne.

Défragmenter vos apps avec Mortar ! by Pierre-Yves Ricau @Piwai at Square

Square également a pour habitude de faire des hackathons. Tous les trimestres, les développeurs peuvent développer pendant 1 semaine ce qu’ils veulent.

Mais revenons à la présentation :

Avant une application Android c’était : N vues -> N activités

Maintenant, avec les fragments, les applications possèdent 1 ou 2 activités et autant de fragments que de vue ou de composés de vue.

Selon Pierre-Yves les fragments sont assimilés à une "salade périgourdine" dans le sens où ils font beaucoup trop de chose :

• créer la vue
• gérer la vue
• couche métier

Les fragments sont donc difficiles à tester.

Une première solution est d’utiliser des vues customs qui sont responsables d’un comportement.

Mais les vues customs ne sont pas plus faciles à tester .

Pierre-Yves nous propose donc le patron de conception suivant :

Utiliser un presenter qui contient le business. Celui-ci est informé quand la vue est construite et les passe les informations à afficher. Lorsque la vue a un événement elle se contente de l’envoyer au presenter.

Le presenter est alors beaucoup plus facile à tester si la vue est mockée.

Pour allez plus loin, le presenter est transformé en singleton qui garde donc son état même si la vue perd le sien (changement de configuration, rotation, etc.)

Guice ou Dagger permet de définir un presenter comme un singleton et de l’injecter automatiquement dans la vue.

Mais comment s’assurer que le singleton est bien garbage collecté ?

C’est là que Mortar entre en jeu !

Mortar propose de créer un scope dans lequel le presenter et la vue vivent. Ainsi quand le scope n’a plus lieu d’être le presenter est également détruit.

Pour gérer la back stack (bouton back des terminaux) Square a développer une bibliothèque permettant de restaurer efficacement les écrans : Flow

Le projet Dagger est en version 1 mais la version 2 est en cours de développement, il n’y a pas encore de date de sortie.

Conclusion

Les talks proposés à la Droidcon 2014 étaient intéressants, parfois techniques, parfois plutôt business ce qui a permis d’aborder des sujets variés. Le niveau était là, même si l’organisation des Bar Camp était un peu hasardeuse.

Vivement l’année prochaine !