Du 11 au 15 novembre 2013 en Belgique : 3500 participants, plus de 30 nationalités représentées pour pas moins de 200 présentations. Revenons sur l’un des plus gros évènements du monde java, la conférence Devoxx.
Cette année Xebia était bien représentée avec quatre de ses poulains :
- Pablo Lopez, Bertrand Dechoux : Hadoop data mining swiss army knife (Conférence)
- Pierre Geyvallet au côté de Jean-Laurent de Morlhon : Phantom, Zombie & Karma, Overview of the greatest testing tools for modern web app (Université)
- Thomas Guérin : Google Cloud Messaging in Action! (Tools in action)
En tant que speaker, j’en profite pour vous faire un retour sur les présentations auxquelles j’ai pu assister lors des deux premiers jours mais aussi pour vous parler de ma première expérience à l’international.
GenyMotion the next generation Android emulator
Au cours de cette présentation Daniel Fages a présenté les nouvelles fonctionnalités de la version 2 de Genymotion. Pour rappel Genymotion est un émulateur Android très apprécié des développeurs pour ses performances. Il dispose de widgets permettant par exemple de simuler un positionnement géographique.
Pour cette nouvelle mouture, plusieurs fonctionnalités ont été ajoutées :
- Les versions 2.3 & 4.3 d’Android sont maintenant disponibles
- Un système de drag&drop pour installer simplement un fichier apk
- Un widget de screencasting
- Un "Remote Control Widget” qui permet d’interagir avec le multitouch et l’accéléromètre au travers d’un device physique.
Pour plus de détails, le changelog est disponible ici.
Le seul défaut de cette nouvelle version est la perte des versions “Google Apps” des images Android. Mais la principale annonce reste que Genymotion dispose maintenant d’un modèle économique.
Getting around with Google Maps Android V2
Grâce à ses applications AVéloV et à Vélib, Cyril Mottier a eu l’occasion d’approfondir ses connaissances sur l’utilisation de Google Maps Android V2. Au cours de ce Tools in Action, il en a profité pour nous en faire un retour d’expérience
Pour cette version 2, l’API Maps a été complètement revisitée et surtout grandement simplifiée. L’initialisation d’une carte ne prend maintenant que quelques lignes :
public class MapActivity extends FragmentActivity {
private GoogleMap mMap;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.map_activity);
setUpMapIfNeeded();
}
@Override
protected void onResume() {
super.onResume();
setUpMapIfNeeded();
}
private void setUpMapIfNeeded() {
if (mMap == null) {
mMap = ((SupportMapFragment) getSupportFragmentManager().findFragmentById(R.id.map)).getMap();
if (mMap != null) {
setUpMap(); // Add some POIs to the map
}
}
}
}
De même il n’a jamais été aussi simple d’ajouter des points d’intérêt sur une carte :
private static final LatLng PARIS = new LatLng(48.856614, 2.352222);
private void setUpMap() {
// Move the camera to Paris location
mMap.animateCamera(CameraUpdateFactory.newLatLngZoom(PARIS, 10));
// Add a marker on the map
map.addMarker(new MarkerOptions().position(PARIS).title("Paris"));
}
Cette nouvelle version de Maps fait partie intégrante des Play Services ce qui a pour principal avantage de disposer de mises à jour régulières indépendamment des release de l’OS. Cependant, Maps s’exécute maintenant dans un processus séparé de celui de votre application, une contrepartie non négligeable. Chaque appel aux méthodes de l’API comme setPosition, remove ou addMarker déclenchera un IPC. Il est important d’en limiter leurs nombres afin de conserver des performances acceptables.
Google Maps Android V2 est l’outil indispensable pour vos représentations cartographiques et rendra votre application plus immersive.
Android performance tips
Dans cette présentation nous retrouvons le duo Romain Guy et Chet Haase qui nous parlent des performances sur Android.
Lazy measurement
L’une des grosses améliorations introduite dans la version 4.4 est la nouvelle gestion du cache des "measured dimensions" au sein de la classe View.
Pour rappel, lorsqu’un ViewGroup décide de mesurer ses enfants il appelle la méthode measure(wSpec, hSpec) sur chacun d’entre eux. Lorsqu’un enfant a terminé sa mesure il appelle la méthode setDimensions(width, height). Chaque enfant stocke en cache interne l’association (wSpec, hSpec) -> (width, height). Lors de la prochaine mesure, si les paramètres (wSpec, hSpec) sont en cache cela évite un appel (au minimum) à la méthode onMeasure qui est souvent assez coûteuse.
Avant KitKat seule la dernière mesure était mise en cache. Cette approche était suffisante dans la plupart des cas sauf pour les “multi-pass layouts” comme le RelativeLayout par exemple. Pour résoudre ce problème, toutes les mesures sont cachées jusqu’au prochain requestLayout() qui les invalidera. Grâce à cette amélioration le nombre de mesures peut être réduit de manière drastique.
Display list reordering and merging
Depuis Android 4.3, avant qu’une "display list" ne soit envoyée au GPU pour être affichée elle est tout d’abord réordonnée de manière à avoir les composants du même type qui se suivent. Une fois cette opération terminée il est possible de les merger en regroupant les composants du même type entre eux (par exemple du texte). Cela permet de réduire le nombre d’appels au GPU mais aussi de minimiser les changements d’états qui est une opération très coûteuse au niveau GPU.
Pour la page contact de l’application native le nombre d’appels au driver OpenGL a ainsi été réduit de plus de la moitié (216 appels au lieu de 516).
Overdraw removal
L’overdraw est une mesure essentielle au sein d’une application Android et il faut s’efforcer de le garder le plus faible possible. Un overdraw arrive à chaque fois que l’application demande au système de dessiner une forme au-dessus d’une autre. Un mécanisme de détection d’overdraw inutile a vu le jour afin d’éviter de les dessiner. Néanmoins, il reste à charge du développeur de veiller à ce que l’overdraw de l’application reste faible.
Une immersion à Devoxx
Le fait d’avoir été sélectionné en tant que speaker est tout d’abord une grande satisfaction mais également une sacrée responsabilité. En effet, je devais réaliser une présentation de 30 minutes en anglais devant des personnes de nationalités différentes. Je ne cache pas que cela nécessite beaucoup de travail en amont. De nombreuses répétitions sont nécessaires afin de pouvoir être à l’aise à l’oral et ainsi pouvoir maîtriser les enchaînements de la présentation. Cela m’a aussi permis de me replonger dans le sujet afin d’être incollable pour la séance de questions tant redoutée !
Je ne vous cache pas que le jour J rien ne s’est passé comme je l’espérais. J’avais quelque peu omis la part de stress qu‘engendre le fait d’être seul sur une scène avec un écran digne des cinémas UGC dans son dos. Certes, je n’avais pas l’affluence de Matt Raible, ni celle de la présentation des Google Glass mais pour une première cela reste tout de même impressionnant !
Le moment le plus intimidant a été quand le silence s’est fait dans la salle. L’ingénieur du son m’a fait signe que tout était ok (même s’il avait oublié d’activer mon micro) et je me suis lancé pour 30 minutes de présentation. Je connaissais mon discours sur le bout des doigts, ainsi que mes temps de passage pour chaque partie. Pourtant à mi-parcours, je me suis aperçu que j’étais en avance de cinq minutes. La machine s’enraye quelque peu. Je cherche mes mots, bafouille un peu mais « the show must go on » alors j’enchaîne. Je ralentis le rythme de ma présentation et en arrive à la démonstration. Deuxième imprévu : le build Gradle décide de prendre une longue minute pour builder le projet. Il me restait à improviser. Puis vient le temps d’écrire des notifications pour la démonstration. Je ne pensais pas qu’il était si difficile de taper correctement avec des mains tremblantes. La présentation se termine. Seulement une question posée. Tout s’est plutôt bien passé finalement
De cette première expérience je retiendrais à quel point il est important de bien se préparer pour une présentation mais surtout d’être parer à l’imprévu. Je tire mon chapeau aux speakers des conférences et universités car je réalise maintenant la quantité de travail que cela nécessite.
Conclusion
Que ce soit en tant que participant ou bien speaker, Devoxx reste un endroit incontournable pour un développeur java. L’ambiance y est toujours aussi décontractée ce qui favorise les échanges techniques (entre autres). Quant aux présentations, ce sont toujours des mines d’informations et on revient toujours la tête pleine d’idées (et le ventre plein de bières).