Android 4.4 KitKat

Alors que l’on attendait une version 5 d’Android, Google a surpris tout le monde en annonçant une version 4.4, qualifiée donc de « version mineure ». Mineure car elle apporte peu de changement « visible » pour le grand public et est donc plus difficile à « marketer ». Pourtant sous le capot, on constate un grand nombre d’évolutions importantes que je vais tenter de vous résumer dans cet article.

NFC : Host Card Emulation

Jusqu’à la version 4.3, le support NFC sur les téléphones Android est limité à une fonction de lecture de tags NFC. Ceci permet par exemple de déclencher des actions sur le téléphone en l’approchant d’un tag NFC.

Nous avons d’ailleurs réalisé plusieurs POC à ce sujet avec un grand groupe pharmaceutique français qui étudie actuellement la mise en place de tags NFC dans ses emballages.

Avec KitKat, il sera désormais possible d’émuler un tag NFC avec son téléphone. Cette nouvelle capacité va permettre de dématérialiser un grand nombre de cartes que nous possédons tous : carte de fidélité, carte de transport, et pourquoi pas à terme carte de paiement… Il suffira alors de rapprocher son téléphone NFC d’un lecteur, au lieu de fouiller dans son portefeuille.

Quand on voit le succès rencontré par Passbook qui permet de regrouper des cartes, des tickets, des bons de réduction avec une technologie de code barres ou qrcode, on peut imaginer ce que sera demain l’engouement du « sans-contact ».

Low-power Sensors

Android KitKat introduit un nouveau mode de gestion des capteurs du téléphone (accéléromètre, détecteur de positions, de pression, température etc..) : les événements peuvent désormais être traités par lots, on parle de « sensor batching ». En fonction des besoins, les applications peuvent être notifiées à un intervalle choisi avec un ensemble de données provenant des capteurs. Jusqu’à présent, chaque événement devait être traité par les applications d’une manière unitaire.

Cerise sur le gâteau, cette optimisation est faite au niveau hardware. Concrètement cela veut dire que les applications pourront continuer à « tracker » les événements des différents capteurs même lorsque le téléphone est éteint ou en veille, ce qui a pour effet de réduire drastiquement la consommation de batterie. (ex : une application de randonnée qui enregistre le trajet n’a plus besoin d’être active pendant la randonnée, il suffira de traiter à posteriori les données de position à la fin du parcours.)

Cette fonctionnalité, combinée à de nouvelles puces permettant de détecter les pas, vient se placer en concurrence directe des dispositifs embarqués (ex: les podomètres dans les chaussures.)

Évolution de la WebView

La WebView bénéficie enfin du même moteur que Chrome Android : Chromium ! Une bonne nouvelle qui devrait sans conteste améliorer les performances des applications dites « hybrides » qui embarquent une WebView pour gérer la partie vue.

Ce changement amène un meilleur support des standard HTML5, CSS3 et Javascript avec notamment le support attendu des websockets et des web workers.

Enfin, une nouveauté et non des moindres, est que l’on peut debugger une WebView directement dans Chrome sur le poste du développeur via les Chrome Developer Tools.

Un “vrai” plein écran : Immersive mode

Depuis KitKat les applications peuvent profiter du moindre pixel disponible avec un vrai mode plein écran. Il est désormais possible de cacher entièrement et de façon permanente la « status bar » et la « navigation bar ». Précédemment, cacher la navigation bar n’était possible que jusqu’à ce que l’utilisateur touche l’écran. (utilisé notamment dans les players video).

Dans ce nouveau mode, les applications peuvent capturer les événements de « touch » n’importe où sur l’écran, y compris sur les emplacements habituels des barres. Pour faire réapparaître les barres (qui sont en partie transparentes dans ce mode) par dessus le contenu, un nouveau geste a été introduit :  un swipe de haut en bas en partant de l’extérieur du téléphone.

Préparer l’avenir

Les ingénieurs Google prépare l’avenir en proposant une preview de ce que pourrait être la nouvelle machine virtuelle qui sera amenée à remplacer Dalvik : ART (Android Runtime)
Alors qu’aujourd’hui le bytecode des applications est transformé en instructions natives à chacune de leurs exécutions (via un compilateur Just-In-Time), avec ART il est pré-compilé une bonne fois pour toute à l’installation (on parle de compilation Ahed-Of-Time).

Au prix d’un temps d’installation plus long, et d’un poids des applications de 10 à 20% plus lourd, il est donc possible d’améliorer les performances à l’exécution tout en économisant de la batterie.

Il est d’ors et déjà possible d’activer ART dans les “Options pour les développeurs” et les retours sont dans l’ensemble assez prometteurs.

Google travaillerait en secret sur ce projet depuis plus de 2 ans, certains avancent même que les poursuites d’Oracle à propos de brevets portant sur la machine virtuelle Dalvik pourraient avoir menées à l’émergence de ce projet.

Un seul mot d’ordre : performance

Un gros travail d’optimisation a eu lieu pour réduire l’utilisation de la mémoire et permettre à des devices peu puissants (512MB de RAM) de faire tourner KitKat. De nouvelles APIs sont désormais disponibles pour détecter ce genre de device (ActivityManager.isLowRamDevice).

Les composants majeurs ont été réécris, le système est plus agressif envers les applications qui consomment le plus, les services sont lancés en petit groupe et en série si le besoin s’en fait sentir.

On peut donc espérer de la part des constructeurs de téléphone, ou à défaut de la communauté, un déploiement de KitKat sur un plus large panel de device que les versions précédentes.

Pour le développeur, cela veut dire qu’il est de plus en plus primordial de s’orienter vers une approche « responsive » des applications, non seulement au niveau de l’affichage (tablette vs téléphone) mais surtout aussi au niveau de leurs fonctionnements et de leurs possibilités.
Ceci afin de tendre vers le but suprême : proposer des applications responsives, fluides et adaptées quelque soit le matériel sur lequel elle sont déployées.

Retour sur DevoxxFR

Jeudi 19 et vendredi 20 avril avait lieu à Paris la conférence DevoxxFR,  par et pour les développeurs java.

La première chose à souligner est l’immense succès de cette première grande conférence puisque nous étions 1250 personnes réunies à l’hôtel Mariott pour les deux derniers jours.

À l’occasion de la sortie des vidéos sur la plateforme Parleys, petit retour sur quelques conférences que j’ai eu l’occasion de voir.

Keynotes

Les deux keynotes qui m’ont particulièrement marquées sont celles de Neal Ford et de Patrick Chanezon.

Dans Abstraction Distractions, Neil Ford nous parle de l’empilement des couches d’abstractions qui envahissent notre quotidien sans qu’on y prête plus vraiment attention et qui peuvent parfois nous induire en erreur. Il nous conseille de toujours avoir à l’esprit ce qui se passe en dessous de la couche que l’on utilise.  Sa keynote est agrémentée d’anecdotes qui font sourire l’auditoire.  Du gros niveau !

Patrick Chanezon enchaîne ensuite avec le portrait d’un développeur en reprenant la trame de The Artist.  On suit le parcours d’un mec qui pendant plusieurs années est le roi du pétrole à coder du cobol dans des SI bien complexes dont seul lui a le secret (=période où Jean Dujardin est une star du cinéma muet).  Puis à l’arrivée de nouvelles technos sympa type mobile, cloud, html5 (=l’arrivée du cinémas parlant) le dev ne s’y intéresse pas et reste dans sa zone de confort.  Malheureusement pour lui ces nouvelles technos prennent de plus en plus de place et notre ami se retrouve rapidement dépassé et remisé au placard (=dépression de Jean Dujardin).

Mais finalement tout est bien qui finit bien car notre développeur se prend en main, réalise qu’il fait partie d’une communauté de passionnés, participe à des jugs et vient à Devoxx. Et finalement cela donne une keynote plutôt rafraîchissante et pleine d’humour.  Bien joué.

Play Framework 2.0

Un mois après la release de la version 2, Sadek Drobi, CTO de Zenexity et Guillaume Bort, cofondateur de Zenexity et créateur de Play Framework retracent l’histoire du web pour expliquer les fondements du framework.

Au départ, le web était constitué de pages statiques puis nous sommes passés dans une phase de langages dynamiques avec notamment PHP, il a fallu ensuite structurer tout ça et c’est à cette époque que sont apparus les premiers frameworks MVC. Plus proche de nous, on a assisté à la démocratisation d’Ajax qui nous a apporté la mise à jour des pages sans besoin de recharger le navigateur.

Aujourd’hui, une page est bien souvent constituée de fragments autonomes, « bindés » sur des flux de données.  Sadek et Guillaume prennent l’exemple de twitter.  Le besoin est réel de structurer ces flux car nous sommes en plein dans l’ère du web temps réel.

C’est sur ce constat qu’a été bâti Play Framework 2,  apporter un socle pour structurer l’interaction avec des streams de manière efficace.

Et voilà du coup ce qu’il est possible de faire : http://console-demo.typesafe.com l’explication ici : http://typesafe.com/products/console

La présentation continue avec comme leitmotiv « don’t fight the web » :  il ne sert à rien d’abstraire le web mais au contraire il faut bâtir en s’appuyant dessus.  Ce que l’on retiendra c’est que Play Framework est un framework stateless full stack qui embrasse le protocole http.

D’un point de vue personnel, cette présentation m’a donné envie d’explorer plus en détail la version 2 de Play, la version 1 apportait déjà beaucoup de fun dans les développements.  Chez DocDoku, nous l’utilisons d’ailleurs en production sur certains projets.

Behind the Scenes of Day-To-Day Software Development at Google

Petra Cross de Google vient nous parler des méthodes de développement chez Google, elle nous présente d’abord la hiérarchie type d’une équipe de développement puis nous parle des méthodes de travail.  On apprend que les maîtres mots sont ‘pragmatisme’ et ‘efficacité’. Par exemple l’équipe de Petra applique l’agilité dans le sens où ils utilisent un backlog de tâches, par contre ils ont totalement supprimé le standup meeting qui selon elle est une perte de temps  (j’entends les agilistes hurler !).

Un concept intéressant massivement utilisé chez Google est le ‘eating your own food’,  il s’agit d’utiliser soit même les produits que l’on conçoit. Ainsi  les googlers utilisent en interne les nighlty build de leurs produits ce qui permet d’avoir un feedback très rapide et de qualité sur les développements.

Conférences Android

J’ai eu l’occasion d’assister à deux conférences sur Android :  « Optimiser vos applications HTML pour Android » et « Android, Graphisme et Performance ». La première présentée par Romain Guy était un condensé de trucs et astuces afin d’optimiser l’IHM des applications Android.

Parmi les astuces et optimisations vues :

  • ViewStub : permet d’instancier (« inflater ») des vues au runtime uniquement si besoin. Cela limite l’empreinte mémoire des View qui peut être très coûteuse, par exemple une TextView vide prend 800 octets en mémoire.
  • StrictMode : outil de debug qui permet d’être notifié lorsqu’une opération lente est effectuée (écriture et lecture disque, opération réseau) ou lorsque une fuite mémoire est détectée (fuite sur les objets sqlite, objet closable non fermé, fuite des activity)
  • GridLayout : nouveau layout introduit d’ICS, moins gourmand que LinearLayout.  Pour les versions Android précédentes, Romain nous conseille RelativeLayout là où c’est possible plutôt que LinearLayout
  •  hierarchyviewer : outil du sdk qui permet de visualiser les grappes de vues et d’analyser leurs performances.

Romain nous détaille également une spécificité des AsyncTask : à partir de l’API level 12 les AsyncTask sont exécutées de manières sérialisées, les unes après les autres. Attention donc à ne pas ralentir la file d’exécution avec une tâche trop longue. Google justifie ce changement en expliquant que la programmation multithread est compliquée. Ils ont donc décidé de revenir sur le comportement par défaut pour limiter les bugs potentiels. Par contre si l’on est sûr que les tâches sont totalement thread-safe, il est tout a fait possible programmatiquement de revenir au comportement précédent.  Ainsi pour paralléliser les AsyncTask il suffit d’appeler :

task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR);

La deuxième conférence Android est celle du googler Nicolas Roard qui travaille sur la webview Android. Nicolas nous délivre quelques astuces pour optimiser les performances dans une webview.  Il nous recommande de privilégier le CSS3 plutôt que le javascript lorsque l’on souhaite faire une animation.

Il nous explique également comment forcer la création de layers qui seront accélérés de façon hardware à partir de la version 3.  Pour cela il suffit d’appliquer une propriété css de transform 3D sur un élément.  On peut également créer un layer sur un scroll afin d’obtenir un rendu proche du natif grâce à la propriété css overflow scroll.

Attention tout de même, ces layers ont certes un rendu fluide mais ils sont très couteux. Il est donc conseillé de les utiliser avec parcimonie, par exemple uniquement durant une animation.

Nicolas termine par 25 minutes de questions/réponses. Les questions majoritairement posées tournent autour des performances de la webview qui souffre de la comparaison avec l’application Google Chrome pour Android.

Il nous explique que même si les deux s’appuient sur le moteur de rendu webkit, les contraintes ne sont pas les mêmes. La webview fait partie intégrante du framework, l’équipe a donc des contraintes quant à la mémoire et l’espace disque utilisé, la webview doit être compatible avec un maximum de choses et rétro compatible avec les précédentes releases. L’équipe de Nicolas a notamment fourni un effort de travail spécifique pour afficher correctement les widgets jquery mobile.

Toutes ces contraintes ne sont pas applicables à Chrome, Chrome est téléchargé depuis le market, c’est un choix de l’utilisateur, par conséquent ils ont beaucoup plus de liberté. Ils peuvent prendre des décisions, avancer vite et releaser souvent, chose impossible à faire pour la webview qui doit attendre une nouvelle version d’Android pour être mise à jour.

Nicolas conclut en nous assurant que les deux équipes mettent en commun beaucoup de travail et que tout le monde en tire un bénéfice.

Quickies

Entre midi et deux avaient lieu les quickies, un format court de conférences où en 15 minutes un speaker présente un sujet qui lui tient à cœur.

J’ai pu notamment voir Mathilde Lemee nous présenter son projet FluentLenium qui facilite l’écriture des tests Selenium en proposant une API très lisible (d’où le fluent !). Et effectivement quand on regarde l’exemple de base, on comprend tout de suite le test :

public class BingTest extends FluentTest {
    @Test
    public void title_of_bing_should_contain_search_query_name() {
        goTo("http://www.bing.com");
        fill("#sb_form_q").with("FluentLenium");
        submit("#sb_form_go");
        assertThat(title()).contains("FluentLenium");
    }
}

FluentLenium s’appuie sur les selectors CSS (même si les regex sont possibles). Enfin la dernière chose à noter sur le projet est qu’il est agnostique du framework d’assertion, ainsi jUnit Assert, Hamcrest et Fest-assert sont supportés.

Un deuxième quickie assez fun fut celui de Philippe Antoine qui s’est proposé de recoder en live le tetris de Martin Kleppe dont une version est jouable ici : http://jsbin.com/egiqul/49

La spécificité initiale de ce Tétris est d’être codé en 140 caractères, cette performance est possible en utilisant le décalage binaire.

Philippe se lance donc dans la réalisation du Tétris avec l’aide de la salle,  il en profite pour nous montrer comment faire du TDD en javascript avec QUnit. Un quickie original qui a bien plu.

Code Story

Pendant les deux jours de conférences, une équipe de quatre développeurs a codé en live une application from scratch. Chaque slot de conférence a donné lieu à un sprint. Ils ont fonctionné en pair programming avec un binôme codant pour la salle : ordinateur relié au vidéo projecteur en commentant le code.  J’ai eu l’occasion d’assister à un sprint, et par la même occasion j’ai pu découvrir Trello un super outil très souple et très simple de gestion de projet.

Conclusion

En tant que développeur, je me suis régalé durant ce Devoxx, j’ai pu satisfaire ma curiosité sur des sujets totalement nouveaux pour moi, comme me plonger dans des astuces plus techniques sur des sujets comme Android.  Si je devais dégager des keywords de cette grande et belle conférence, je choisirais :  cloud, mobile, html5 & javascript, NoSQL.