Android Makers – Business Technology

05Nous y étions !

Cette année se tenait la première édition de Android Makers, la conférence remplaçant la célèbre Droidcon paris. Organisée par la même formidable équipe, nous nous devions de sponsoriser l’événement !

Durant deux jours, iD.apps était présent, aussi bien dans l’espace sponsors que dans les conférences. Nos développeurs ont pu assister à de nombreuses sessions, toutes plus intéressantes les unes que les autres.

C’était également l’occasion d’échanger avec d’autres équipes, voir d’autres manières d’envisager nos développements, et faire le plein d’idées et de nouvelles technologies pour l’année à venir. Le tout alimenté par Google qui fournissait même le nougat !

Nous organisions également un jeu concours pour faire gagner deux Nvidia Shield ! De nombreux candidats assoiffés de devices Android sont venus tenter leur chance, mais il ne pouvait y avoir que deux vainqueurs ! Chet Haase de Google (est-il encore besoin de le présenter ?) à même participé au second tirage au sort à la fin de la conférence.

Nos top picks

Un certain nombre de conférences nous a particulièrement plu, et nous avons donc demandé à chacun de nos développeurs présents de choisir sa session préférée et nous en parler !

 

The ART of organizing resources

 

On accorde souvent beaucoup d’importance à l’architecture d’un projet et à son organisation. Malheureusement il n’est pas rare de voir des projets où la partie Java est bien organisée et les ressources un vaste chaos. Jeroen Mols (Android developer pour Phillips Hue) nous a proposé une bonne manière d’organiser les ressources. Ce fut intéressant de voir que certaines pratiques que l’on utilise chez iD.apps étaient reprises dans sa présentation. Il a terminé sa conférence avec une cheat sheet que je partage avec vous :

 

Jérémy

Launch Screens: From a Tap to Your App

Cette session mettait en avant les différentes cinématiques de lancement d’une application Android. Elle était proposée par Cyril Mottier, qu’on ne présente plus dans la droidsphère française.

On y découvre la comparaison de deux philosophies de lancement d’applications Android : l’écran de démarrage – splash screen ou branded launch – et l’écran de substitution – ou placeholder screen. Nous y avons découvert les différents critères, liés à l’expérience utilisateur ou au marketing, qui peuvent amener à choisir l’un ou l’autre.

Si vous souhaitez vous-même vous pencher sur la question, Cyril Mottier entre également en détails dans la chronologie du lancement d’une application. Il y indique la marche à suivre pour mesurer le résultat en terme d’expérience utilisateur d’un lancement rapide du squelette de votre application.

Enfin, vous y trouverez une façon de réaliser votre propre placeholder UI, et ainsi donner l’impression à vos utilisateurs que votre application se lance en quelques centaines de millisecondes.

 

Pierre

The Fabulous Journey to Material Design Award

La première journée se terminait en apothéose avec une conférence du célèbre Taylor Ling (qui a même eu l’amabilité de dessiner les t-shirts de la conférence, nous sommes tous fans chez iD.apps !). Il présentait l’application Fabulous qui a reçu un Material Design Award l’an dernier, et les principes utilisés lors de la conception.

J’ai trouvé son approche très intéressante et positive, et honnêtement, l’application Fabulous est vraiment magnifique, ce qui en fait une source d’inspiration sans limite ! Si vous vous intéressez au design de manière générale, regardez la vidéo !

Quentin

Android Things for IoT

Android Things (ou Android pour les objets connectés) est un composant peu connu de la plateforme, mais pas le moins intéressant ! Cette conférence, présentée par le Googler Wayne Piekarski, présentait toutes les bases nécessaires au développement d’un objet connecté sous Android, aussi bien au niveau du hardware que du software. On n’a qu’une seule envie en sortant de là : acheter un Raspberry Pi 3 et équiper son frigo avec un thermomètre connecté !

Quentin

How to reactively load and cache data without even trying

La conférence de Mike Nakhimovich, du New York Times avait pour sujet “How to reactively load and cache data without even trying”. Elle présentait la librairie open source “Store” (https://github.com/NYTimes/Store), développée en interne pour répondre aux problématiques de chargement et persistance des données dans leur application Android.

En plus d’être un orateur clair et sympathique, Mike offre à la communauté des développeurs Android un socle générique pour standardiser le workflow d’acquisition et persistance des données.

La librairie, développée sur une base de RxJava, est un framework visionnaire et très prometteur… Celui-ci offre de nombreuses possibilités de personnalisation (du requêtage, parsing et caching), et des middlewares sont déjà disponibles pour l’intégration avec des librairies tierces bien connues telles que Gson, Moshi, Guava Cache, ou encore Okio.

Aujourd’hui, on ne se passerait plus de Glide ou Picasso qui ont fait la même chose pour le chargement d’images. Il y a fort à parier que ce sera le cas demain pour la gestion de nos données avec Store.

Thank you, Mike!

Christophe

Toothpick: a fresh approach to Dependency Injection on Android

Il y a quelques années, j’ai eu l’occasion d’utiliser RoboGuice. Il était facile à utiliser mais, malheureusement, relativement peu performant. Et puis, dans le cadre d’un autre projet, j’ai voulu utiliser Dagger. Et là… La performance était au rendez-vous, à tout le moins du point de vue de l’exécution ! Côté développeur, la performance a été revue à la baisse 🙂

C’est donc en espérant retrouver cette simplicité dans la syntaxe tout en gardant des performances correctes que je suis allé voir la conférence sur Toothpick. Et j’ai été conquis : un framework d’injection de dépendances simple et performant ! Avec en prime de nouveaux scopes pour des cas particuliers pas si rares que ça dans nos développements (tunnels de paiement, rotation d’écran).

Il va maintenant falloir tester cela sur de nouveaux projets, et voir si les promesses de l'(excellent) orateur sont tenues avant d’inclure Toothpick dans notre trousse à outils.

Retrouvez tous les slides de la conférence ici :

David

L’évolution des notifications – Tips & tricks

Notification : artefact d’interface facilitant les interactions et les feedbacks d’une application avec son utilisateur via le système.

Dans cette présentation, Jeremie Martinez, Trainline (Captain Train), nous a présenté l’évolution des notifications depuis les origines d’Android jusqu’à Marshmallow avec une pointe de visibilité sur Nougat.

Celles-ci sont devenues au fur et à mesure du temps de plus en plus complètes tout en gardant leur simplicité graphique. Mais faut-il encore ne pas en abuser pour ne pas spammer les utilisateurs et les noyer d’informations inutiles !

“Même #Batman peut être spammé de notifications pour sauver #Gotham

Ce simple graphique permet de positionner votre application et de définir si celle-ci a réellement besoin de notifier l’utilisateur pour lui apporter des informations utiles.

Dans le cas présenté, Trainline, l’application informe l’utilisateur à tous les moments cruciaux de son voyage :

  • Quelques heures avant
  • Lorsque le train ne va pas tarder
  • A l’arrivée du train sur le quai
  • Au changement d’horaire possible (avec une mise en couleur du titre et des actions pour se différencier des autres informations moins sensibles)
  • A l’arrivée du train à sa destination finale
  • Et même quelques minutes après l’arrivée pour souhaiter une bonne journée au voyageur ! (notification qui s’auto efface au bout de 15 minutes d’affichage sans action de l’utilisateur)

Toutes ces notifications sont informatives mais permettent une certaine sérénité pour le voyageur. Pour ma part la dernière notification est à considérer comme du spam, pour Trainline c’était juste pour le fun.

Pour conclure il faut peu de notifications pour avoir un utilisateur heureux.

Vous pouvez retrouver tous les slides de la conférence ici :

Melaine

 

Ivre, il commercialisa des apps Android tout seul

Développer ou faire développer son application pour devenir riche voire très riche : utopie ou réalité ? Tel est le sujet abordé par Pierre Benayoun dans sa conférence.

Une présentation pleine de gifs !

A travers son expérience, Pierre Benayoun, nous a montré quels étaient les points clés pour la réalisation et la commercialisation d’une application :

  • Qu’est ce qu’une bonne appli ?
  • Comment l’application trouve-t-elle son public ?
  • Comment gagne t’on de l’argent ?

Plusieurs paramètres non négligeables entrent en ligne de compte pour répondre à ces 3 questions

mais surtout ne pas hésiter à faire, refaire et re-refaire tout en analysant et en apprenant de ses succès comme de ses erreurs.

Tout en gardant à l’esprit que …

L’instant hype de la présentation : la notation rôti avec les mains :

  • 5 doigts OK j’ai tout compris et la présentation était parfaite
  • 0 doigt, poing fermé (petit rôti) : présentation suicidaire, j’aurais mieux fait de rester au lit 😉

Vous pouvez retrouver tous les slides de la conférence ici :

https://docs.google.com/presentation/d/1afPtkSb_BUtD6t61wV2eaVLVzbnYQ9D6quaFCG9D4LI

Melaine

 

Le design mobile c’est pas facile

Nous étions présents dans l’espace sponsors, nous étions dans les rangées de spectateurs avides de connaissances, mais nous étions aussi là-bas, dans la lumière, sur l’estrade tant convoitée des speakers d’Android Makers.

Quentin, un de nos experts Android, passionné de design (et de séries), nous a présenté les difficultés que nous pouvons (et que vous pouvez) rencontrer face à un client ou quelqu’un qui n’est pas du métier.

A travers différentes saynètes, il nous a présenté les solutions qui peuvent être envisagées, afin que tout le monde y trouve son compte : le client, le développeur, le designer, mais surtout, l’utilisateur final.

Vous pouvez retrouver tous les slides de la conférence ici :

David

Show must go on

Pour terminer la conférence, nous avons assisté à un véritable spectacle de la part de Chet, nous laissant ravis de ces deux jours et le sourire aux lèvres, la tête remplie de nouvelles idées à essayer sur nos prochaines applications. Nous vous laissons avec la vidéo si vous souhaitez comprendre un peu mieux le titre de cet article, ou juste rire un moment.

 

Merci à iD.apps pour l’expérience, et à l’an prochain !

Introduction à Android TV

Les applications TV sont aujourd’hui présentes pour mettre en avant du contenu en accès rapide et avec très peu de contraintes. Afin de conserver la meilleure expérience possible il est nécessaire de respecter certains aspects.

Au début, le développement d’une application TV est assez proche du développement d’une application smartphone et tablette. Cependant la documentation pour ce type d’appareil est très pauvre.

Pour aider les développeurs, Google recommande de respecter une certaine ergonomie, expliquée dans une documentation de base (https://www.google.com/design/spec-tv/android-tv/introduction.html). Ce qui change globalement c’est la navigation. En effet, sur TV, la navigation dans l’application se fait par l’intermédiaire de la télécommande, sans contact tactile avec l’écran. C’est pourquoi l’ergonomie des applications TV ressemble finalement assez peu à ce dont on a l’habitude et possède ses propres codes, gestes.

La librairie Leanback, mise à disposition par Google, propose plusieurs composants et différents types de fragments. Certains de ces composants sont présentés dans la documentation précédemment évoquée. Malheureusement celle-ci ne propose pas d’exemple de code. Pour vraiment pouvoir vous lancer dans la création de votre première application TV, il faut se référer au tutoriel officiel suivant : https://codelabs.developers.google.com/codelabs/androidtv-adding-leanback/index.html?index=..%2F..%2Findex#0

Ce tutoriel présente les composants et fragments de base via des exemples de code bien expliqués, bien utile pour se familiariser rapidement avec les applications TV.

Pour aller plus loin, le DIY est de mise. En effet, le développement d’applications TV n’étant pas encore très répandu il faut chercher ce que l’on souhaite faire dans des exemples d’applications proposés par Google. Les deux meilleurs samples de code disponibles et mis à jour régulièrement sur GitHub sont :

atv-leanback-all

Fragments et vues abordés dans l’exemple Github androidtv-Leanback

Figure 2 : Fragments et vues abordés dans l'exemple Github leanback-showcase

Fragments et vues abordés dans l’exemple Github leanback-showcase

Ces deux projets se complètent bien même si le deuxième présente plus de diversité.

 

Ça donne quoi en vrai ?

Dans notre cas, nous avons développé une application présentant différents quiz regroupés par thèmes.

Cette application nous a servi d’expérience pour tester certaines fonctionnalités d’Android TV.

Nous avons commencé par implémenter un BrowseFragment (https://developer.android.com/reference/android/support/v17/leanback/app/BrowseFragment.html) pour l’affichage des quiz de chaque thème. L’ajout de listes de quiz se fait via un ArrayObjectAdapter utilisant un ListRowPresenter (adapter permettant d’ajouter plusieurs élements de type ListRow contenant un header et une liste de card).

Ensuite pour chaque élément de la liste il est possible d’utiliser des CardViews prédéfinis ou des CardViews custom selon le besoin. Le BrowseFragment est au début aisé à prendre en main de part les exemples cités précédemment. En effet, l’adapter permettant d’ajouter des lignes de Cards dans le fragment est plutôt intuitif. En revanche lorsque l’on essaie de customiser les vues la complexité s’accroit car il faut se débrouiller par soi-même pour arriver au but que l’on s’est donné. Il y a en effet très peu d’informations sur les vues personnalisées dans les tutoriels.

Figure 3 : BrowseFragment présentant la liste des thèmes et les quiz correspondant

Le BrowseFragment présente la liste des thèmes et les quiz correspondants

Nous avons également utilisé le DetailFragment afin d’afficher le détail d’un quiz. Par défaut la description et l’image adoptent des layouts prédéfinis, mais il est bien entendu possible d’utiliser les nôtres. Dans ce fragment il est possible d’ajouter des listes de suggestions d’éléments. Dans notre cas, nous avons suggéré les quiz du même thème. Le DetailFragment est le plus difficile à mettre en place car aucun exemple n’explique concrètement comment mettre en place l’adapter afin de réaliser une apparence personnalisée. Notre conseil pour réussir une page sympa est d’utiliser un ArrayObjectAdapter avec en paramètre un ClassPresenterSelector (cela permet d’ajouter et d’ordonner plusieurs adapter différents afin, par exemple, de pouvoir proposer des suggestions sous la description de l’élément courant).

Figure 4 : En tête du DetailFragment d’un quiz

Entête du DetailFragment d’un quiz

Figure 5 : Bas de page du DetailFragment d’un quiz, liste de suggestion

Bas de page du DetailFragment d’un quiz avec une liste de suggestions

Pour la recherche d’un quiz nous avons exploité le SearchFragment qui lui est facile à prendre en main. Le fragment de base suffit, il faut simplement spécifier les différents adapter à utiliser pour l’affichage des résultats.

Figure 6 : SearchFragment après la recherche “sport”

SearchFragment après la recherche “sport”

Le GuidedStepFragment est quant à lui très pratique et facile d’utilisation pour de la configuration. En revanche, dans notre cas, nous l’avons utilisé pour la connexion via email et mot de passe, et cela a posé quelques complications lors de l’ajout des champs de saisie de texte. En effet, ce fragment est principalement élaboré pour contenir des boutons classiques et/ou radios.

Figure 7 : GuidedStepFragment proposant le choix du type de connexion

GuidedStepFragment qui propose le choix du type de connexion

Pour notre application nous avons également implémenté une page de paramètres via le SettingsFragment. Cette page se présente comme un Drawer sur la partie droite de l’écran. Le fichier XML de settings est identique à celui que l’on peut trouver sur les smartphones/tablettes.

Figure 8 : SettingsFragment donnant le choix d’activation de certaines fonctionnalités

SettingsFragment qui donne le choix d’activation de certaines fonctionnalités

 

Le mot de la fin

Comme vous avez pu le constater, la réalisation de cette application nous a permis de passer en revue de nombreux composants Android TV fournis par Google.

La programmation d’applications pour Android TV est très intéressante car elle permet une approche différente des applications utilisées sur nos smartphones/tablettes même si une bonne dose de DIY est nécessaire !

Crosswalk : la WebView du futur !

Comme tous les ans avant la Google I/O, il y a la soirée Day 0 Intel Party. Le nombre de participants à l’I/O ayant augmenté cette année, ce fut encore plus difficile d’y entrer. Mais armés de notre patience, nous avons tout de même réussi ce challenge.

Nous sommes donc entrés dans un lieu insolite, à mi-chemin entre le bar et la place à Food Trucks, le tout accompagné de stands sur divers projets Intel liés au mobile. Le sujet de cet article est l’un de ces projets qui pourra répondre à un besoin que nous avons fréquemment : la WebView.

Aujourd’hui, pour intégrer une WebView dans notre application, nous avons, au choix, les Chrome Custom Tabs, ou une WebView classique.

Intégrer une WebView directement dans l’application n’est pas forcément compliqué, mais amène deux soucis majeurs : les performances et les comportements anormaux qui diffèrent par rapport au browser natif (ou pas à jour).

Intel a pensé à nous et a sorti une librairie qui répond à ces problèmes : Crosswalk (https://crosswalk-project.org/). Celle-ci est disponible sur Android, iOS, WP et Cordova.

Elle intègre une WebView performante qui a toujours le même comportement suivant les versions d’Android. Il s’agit ni plus ni moins que d’une réimplementation de Chromium et son moteur Blink, sous forme de librairie.

Elle a aussi l’avantage d’intégrer des APIs non disponibles dans la WebView standard, comme :

  • WebRTC
  • WebGL
  • Vibration API
  • Presentation API
  • Predictable layout
  • CSS feature queries

Sur le papier, le projet vend du rêve mais il faut tout de même noter un point négatif : le poids de la librairie (19 Mo).

Si cet inconvénient n’est pas un problème pour votre projet, je vous invite fortement à tester cette librairie qui pourra vous éviter pas mal de galères. La migration est très simple car la WebView de Crosswalk a la même interface que la Webview standard, il faudra juste modifier les imports et le nom de la classe.

Pour en savoir plus, voici une vidéo de présentation faite par Intel sur le sujet.

Google I/O : nous y étions !

Mis en avant

Cette année, iD.apps était présent à la Google I/O, avec pas moins de trois participants à la conférence annuelle de Google pour les développeurs. C’est généralement durant cet événement que la firme de Mountain View annonce à la fois ses nouveaux produits pour le grand public, mais aussi les nouveautés à venir sur Android, ou encore les nouveaux outils qu’elle met à disposition des développeurs.

Bien entendu, nous avons envie de vous parler de tout un tas de nouveautés que nous avons adoré ! Mais avant, nous voulions vous faire un petit tour d’horizon de ces trois jours de conférence dans la Silicon Valley !

IMG_20160519_201327

 

Google I/O day 0 et keynote

Cette année, la Google I/O se déroulait pour la première fois au Shoreline Amphitheatre, à Mountain View, juste à côté des locaux de chez Google. Il s’agit d’un amphithéâtre, généralement utilisé pour des concerts, et pouvant accueillir plus de 20000 personnes !

Grande nouveauté donc, la conférence s’est déroulée en plein air, le parking ayant été aménagé d’espaces pour les conférences et autres démos technologiques.

Afin d’obtenir de bonnes places pour la keynote, il était impératif d’arriver le plus tôt possible pour le retrait des billets, le jour précédant celle-ci. En effet, les meilleures places étaient attribuées aux premiers arrivés. Forts de notre envie d’être au premier rang, nous sommes donc partis attendre l’ouverture des retraits de badges, dès 5h du matin ! 2h plus tard, nous avions nos badges, et une place dans la section 101, la mieux placée.

C’est donc au premier rang de la section 101, juste derrière les Googlers, que les experts iD.apps étaient prêts à découvrir les nouveautés que Google allait annoncer. Et nous n’avons pas été déçus !
IMG_20160518_090459

Tout d’abord, Google Home, un boîtier équipé du Google Assistant (évolution de Google Now), qui vous permettra, par la voix, de poser une question, écouter une chanson sur Google Music, ou lancer un appel Hangouts. Si vous connaissez Echo d’Amazon, vous voyez probablement de quoi il s’agit. Si vous voulez en savoir plus, vous pouvez aller visiter la page officielle : https://home.google.com . Sortie cet automne pour en savoir plus !

Google a également présenté deux nouvelles applications : Allo et Duo. Le premier se présente comme un remplaçant de Hangouts, tandis que le second est une sorte de Facetime à la sauce Google. L’intégration de l’assistant Google les rend néanmoins particulièrement puissantes. Les deux applications devraient être disponibles durant l’été !

La VR était également de la partie, avec l’annonce de standards de construction de smartphones VR ready pour Android, sous la marque Daydream. Le tout s’accompagnera d’une nouvelle interface entièrement dédiée à la VR pour ces téléphones. Plus d’informations seront disponibles cet automne.

Google nous a également présenté (ou plutôt re-présenté) les nouveautés à venir sur Android N (notamment le multi-window). Petite surprise néanmoins : les instant apps. D’ici la fin de l’année, il sera possible aux utilisateurs d’Android d’utiliser certaines parties d’une application, sans avoir à l’installer ! Vous pourrez par exemple consulter le détail d’une réservation d’hôtel, sans avoir à installer l’application de la chaîne d’hôtel en question. Le tout disponible à partir de KitKat. Plutôt pas mal non ?

IMG_20160517_073652

Côté développeurs,  Android Studio a désormais une version 2.2 (disponible en version Canary), qui intègre de très nombreuses nouveautés, dont le constraint layout (qui devrait simplifier la vie des développeurs pour construire les interfaces), ou encore un enregistreur de tests fonctionnels pour Espresso. Nous écrirons un article bientôt pour vous donner notre ressenti sur toutes ces nouveautés vraiment intéressantes. En attendant, vous pouvez aller voir la conférence What’s new in Android Studio sur Youtube !

 

Enfin, le meilleur pour la fin : Firebase ! Vous connaissez cette entreprise, récemment acquise par Google, pour sa base de données temps réel très populaire. Désormais, Firebase inclut également un nombre très important d’outils formidables pour les développeurs Android. On y trouvera entre autres :

  • des statistiques d’application poussées (à la Google Analytics) avec de la gestion d’audience
  • du crash reporting (à la Fabric)
  • du paramétrage d’applications (comme Parse le permettait par exemple)
  • de la gestion de liens dynamiques
  • de l’hébergement de ressources web statiques
  • DU PUSH

Oui, vous avez bien lu, du push ! GCM est désormais FCM (Firebase Cloud Messaging), et permet l’envoi de pushs depuis la console Firebase, avec une gestion très poussée des audiences, liée aux statistiques de la partie analytics.

Le plus important : l’ensemble est GRATUIT. Plus besoin donc de passer par des solutions tierces (très) coûteuses pour de l’envoi de pushs ciblés. Le tout fonctionnant sous Android comme iOS. Nous reparlerons bien entendu plus en détails de tous ces changements qui vont avoir un impact important sur notre travail chez iD.apps.

IMG_20160519_142226

 

Les conférences, et autour

En trois jours, nous avons eu l’occasion d’assister à de très nombreuses conférences, sur de nombreux sujets. Bien entendu, Android, mais aussi Firebase, le Material Design, Play Games, ou encore les applications pour les pays émergents. Il fallait s’armer de patience pour assister aux conférences les plus courues, les gens faisant parfois la queue près de 2h en avance !

Heureusement, l’attente se faisant en extérieur, le cadre très agréable et le soleil de Californie adoucissaient un peu ces “pauses”. C’était aussi l’occasion de discuter avec d’autres développeurs venant du monde entier, et d’échanger sur les problèmes que nous rencontrons avec nos clients au quotidien. Et il n’y a pas tant de différence que ça entre la France et la Silicon Valley à ce niveau-là ! Et pour contrer la chaleur, Google n’avait pas lésiné sur les boissons et autres serviettes glacées. Les conférences, ce sont les rencontres avant tout, non ?

Baby foot

Les experts iD.apps prennent une pause entre deux conférences

Malgré ces longues files d’attente, nous avons pu assister à des conférences avec certaines célébrités de Google, comme Chet Hasse, Romain Guy, Nick Butcher ou encore Chris Banes ! Nous avons également vu sur scène le CTO d’Epic games (Unreal Engine), le CEO d’Unity Technologies, et même le très connu Tim O’Reilly. On croise de vrais légendes à la Google I/O !
IMG_20160519_130000

Nous avons également eu l’occasion d’aller tester quelques produits Google (pas Google Home malheureusement), et discuter avec les équipes produits. Comme vous pouvez vous en douter, nous avons longuement dialogué avec les équipes de Firebase, ou encore d’Android Studio. Nous avons aussi testé la réalité virtuelle avec une animation autour de Bohemian Rhapsody de Queen, ou encore la communication entre Android et un robot, avec un bras mécanique non dépourvu de talent artistique ! Sans oublier le projet Tango (https://www.google.com/atap/project-tango/), avec des tablettes montées sur des fusils Nerf pour faire la chasse aux monstres sous un chapiteau. Oui, on a l’air ridicule à courir après des créatures qui n’existent pas.

 

Le mot de la fin, avant la suite

Conclusion : la Google I/O, c’était génial ! Nous avons beaucoup de nouveautés à tester maintenant que nous sommes revenus en France, et il est probable que certaines annonces changent notre travail de tous les jours (avec un gain de productivité peut-être :)). Et nous sommes impatients de tester les nouveaux produits qui sortiront dans les mois à venir. Seule déception (en plus de l’absence de cadeau) : pas de nouveaux téléphones ou tablettes annoncés, mais l’on pouvait s’y attendre.

Suivez de près notre blog dans les semaines à venir pour en savoir plus sur ce que nous avons vu, et nos retours sur les nouveautés Android !

IMG_20160518_100448

Electric Dreams

Mais enfin c’est quoi un Daydream ?

Tout le monde connaît les fameux économiseurs d’écran. Qu’il s’agisse d’un simple logo qui bouge, ou d’un véritable aquarium virtuel, ils existent depuis bien longtemps. Néanmoins, dans le monde du mobile, c’est une notion qui n’existe pas vraiment.

Pourtant, il existe une fonctionnalité qui s’en rapproche sur Android : le daydream (API 17). Celui-ci peut en effet satisfaire les amateurs de poissons rouges en 3D, mais aussi et surtout réaliser tout un tas de traitements utiles : appeler un web service, afficher un flux RSS, et même offrir de l’interaction ! Cela permet d’afficher quelque chose de sympathique lorsque son appareil est en charge ou sur un dock.

Et pour les développeurs Android, il est vraiment très simple de faire vos propres daydreams. Alors, vous êtes convaincu de vous embarquer dans l’aventure ?

 

En route !

Créer un daydream est enfantin ! La première étape consiste à simplement créer une classe héritant de DreamService.

Vous aurez ensuite 4 méthodes à surcharger :

  • onDreamingStarted() : c’est là que les affaires commencent ! Vous pouvez lancer par exemple des animations. Après tout, s’il s’agit d’un économiseur d’écran, il faut que ça bouge un peu !
  • onDreamingStopped() : on se réveille ! C’est ici que le rêve s’arrête, ainsi que les traitements et animations commencés dans la méthode onDreamingStarted
  • onDetachedFromWindow() : à ce moment-là, vous pouvez libérer d’éventuelles ressources comme les listeners.

Vous devez également ajouter votre service à votre manifest. Et voilà, vous êtes prêt !

Nous vous conseillons d’aller voir la doc pour en savoir un peu plus :http://developer.android.com/reference/android/service/dreams/DreamService.html

Quelques méthodes bien utiles…

… A appeler dans la méthode onAttachedToWindow

  • setContentView : pour ajouter une vue à votre daydream
  • setFullscreen : si vous souhaitez conserver ou non l’interface du système
  • setInteractive : indique si l’utilisateur peut interagir avec le daydream ou non. A noter qu’il sera dans ce cas à vous de gérer le réveil (entendez par-là la sortie du daydream).

 

Jusqu’au bout du rêve

Vous vous en serez rendu compte, on peut tout faire, ou presque, sur un daydream ! Chez iD.apps, nous avons décidé de nous amuser à créer un diaporama de photos issues de l’API picture of the day de la NASA (https://api.nasa.gov/api.html). Cela permet d’égayer nos journées avec un joli défilé de photos spatiales.

Space

Et pour vous prouver que vraiment, ce n’est pas compliqué, nous avons publié sur Github le code de notre daydream. N’hésitez pas à aller y jeter un coup d’oeil, et éventuellement le forker pour modifier la source des images. N’hésitez pas non plus à nous soumettre une pull request si vous voulez nous aider à l’améliorer.

https://github.com/idapps/Interstellar-Daydream

Actuellement, le daydream affiche les photos de l’API, ainsi que leur nom et leur description. Ceux-ci changent toutes les minutes, afin de vous laisser le temps de lire le texte.

 

Vers l’infini et au-delà !

Notre daydream de l’espace n’est bien entendu qu’une première version, et pourrait facilement être amélioré. Il est par exemple possible d’ajouter une base de données embarquée pour pouvoir faire défiler des photos venant d’une période de temps plus longue, ou le rendre compatible smartphone et tablette. On pourrait même imaginer un écran de paramètres pour configurer diverses choses comme les temps de transition !

La conclusion est simple : les possibilités sont infinies. Il ne reste plus qu’à trouver l’API de vos rêves !

Couteaux contre annotations : Dagger et Butter Knife VS Android Annotations

Introduction

Chez iD.apps, deux équipes cohabitent: les pro-Android Annotations (AA), et les pro-Dagger/Butter Knife. Nous utilisons l’une ou l’autre solution, mais à chaque nouveau projet, on se re-pose la question : AA ou DG/BK. Nous avons essayé ici de trouver une réponse au débat.

Mais à quoi ça sert ?

Butter Knife est une librairie d’injection de ressources basée sur le système d’annotations Java. Le principe est simple, il suffit d’annoter tous les membres et méthodes d’une classe que l’on souhaite injecter : ce sont généralement des vues, implémentation de clic, de sélection, etc. Quand une classe est annotée, Butter Knife va générer un injecteur pour cette classe. Il suffira de faire un appel à ButterKnife.bind(…) pour injecter tous les membres ou listeners souhaités.

Cela permet d’épurer le code, souvent répétitif (et polluant ?!) de vos classes Android. Finis les findViewById dans vos activités, finis les setOnClickListener dans vos fragments : toutes ces lignes de codes tapées encore et encore sont maintenant générées pour vous à la compilation.

Dagger sert lui aussi à faire de l’injection de dépendances, mais est plutôt complémentaire à Butter Knife, en se basant sur des modules et des composants. Là où Butter Knife gère vos vues et listeners, Dagger va s’occuper de vos singletons et autres modules plus orientés “métier”. Le tout ayant pour objectif de simplifier la vie des développeurs.

Android Annotations suit les mêmes objectifs, mais a une manière de fonctionner bien à lui . En effet, toutes les classes annotées par Android Annotations sont sous-classées par génération, et c’est la classe fille générée qui est à instancier à la place de la classe mère qui a été codée.

On peut ainsi faire appel à nos vues et ressources dans la classe d’origine grâce à des annotations comme @AfterViews et @AfterInject, qui sont respectivement appelée après l’injection des vues et après l’injection des dépendances.

AndroidAnnotation promet de gérer pour vous :

  • l’injection de composants Android (activités, fragment, services, receiver),

  • l’injection de vues,

  • l’injection de dépendances,

  • la gestion d’événements,

  • la gestion des préférences,

  • le multi-threading.

Non contente de tout cet attirail, AndroidAnnotations s’essaye également à l’injection de bibliothèques tierces (OrmLite, Otto, Dagger, RoboGuice, Parceler).

 

Que font Dagger et Butter Knife de bien ?

 

Ces deux librairies ont vraiment pour but la simplicité. Avec Butter Knife, vous n’aurez pas de sous-classes générées, de bugs étranges ou d’options de compilation exotiques. Une dépendance Gradle, un ButterKnife.bind sur votre activité/fragment/vue, et hop, vous pouvez commencer à injecter vos vues et ressources. On a vraiment une impression de facilité très agréable. Et comme son périmètre d’action est relativement limité, vous pourrez très rapidement apprendre à vous en servir.

En somme, Butter Knife fait une seule chose, mais le fait bien !

Dagger va lui être très utile à partir du moment où votre projet va gagner en complexité. Fini le code spaghetti, les helpers qui sortent de nul part, et les dépendances injectées à la main de manière totalement anarchique.

Avec Dagger, basé sur la JSR 330, vous allez pouvoir définir des interfaces (annotés @Component) qui donneront des indications sur ce qui est injecté, et des modules (@Module) qui définiront comment votre dépendance va être injecté. Le tout se base ensuite sur la génération de code à la compilation pour finir le travail.

Dagger simplifie également le test unitaire : il est très facile de changer les composants injectés en fonction du besoin. Par exemple, un composant faisant des appels Webservices dans votre application peut être remplacé par une implémentation renvoyant des mocks dans vos tests unitaires (elle est pas belle, la vie ?)

 

Que fait Android Annotations de bien ?

Android Annotations fait beaucoup de choses, peut-être même trop. Il suffit d’aller voir la liste des annotations disponibles pour s’en rendre compte.  Mais c’est aussi pour ça qu’on l’aime !

AA vous offre plus de choix, mais ajoute donc de fait une lourdeur supplémentaire en faisant tant de choses. C’est aussi à vous de déterminer ce qui vous sera utile ou non. Certaines personnes aiment par exemple l’utiliser pour gérer les SharedPreferences, alors que d’autres non. Là où AA prend tout son sens, c’est en premier lieu pour l’injection de vues, et de ressources en général. Là-dessus, il est plus complet que Butter Knife. J’aime particulièrement l’annotation @AnimationRes, très pratique.

AA gère également la création de Bean, qui vous permettront de vous servir des annotations dans n’importe quelle classe. Cela peut au passage vous aider à créer un singleton facilement, pour gérer vos calls réseaux, votre gestion de la base de données… Tout ce qui peut se passer en background en somme.

En parlant d’asynchronisme, voilà un autre point fort d’AA : la gestion des opérations dans un thread à part et le retour dans l’UI thread. Vous souhaitez faire une opération en background ? Utilisez l’annotation @Background. Vous souhaitez revenir dans l’UI thread? Qu’à cela ne tienne, @UIThread est là pour ça !

Pour moi il s’agit d’une véritable killer feature, et l’un des arguments les plus solides face à Dagger et Butter Knife. Bien sûr, il existe plein de librairies pour faire de l’asynchronisme (Bolts par exemple), mais il est vrai que la simplicité d’AA sur ce sujet est sans égal ou presque.

 

En conclusion ?

Du coup, qu’est-ce qui est le mieux ? Quel est le plus avantageux ? La réponse n’est pas simple. En fait, chacun y trouvera son compte. Certains aimeront la toute puissance d’Android Annotations, qui suffira à elle seule à combler bon nombre de besoins, et d’autres préféreront l’atomicité et le contrôle de Butter Knife et Dagger. Certains auront peur de cet effet “boite noire” d’Android Annotations, où tout le cycle d’injection est caché dans le code généré, alors que d’autre reprocheront à Butter Knife son manque de fonctionnalités ou à Dagger une prise en main ardue et une mise en place un peu lourde.

Mais s’il fallait faire un choix, il serait le suivant : Android  Annotations répond parfaitement au besoin d’une petite application, car il permet de faire énormément de choses en très peu de temps ; par contre, dans le cas d’une application complexe, en constante évolution, peut-être faut-il plutôt vous tourner vers Butter Knife et Dagger, afin de limiter la quantité de code généré, et ainsi garder un contrôle plus complet sur votre code.

 

Pour en savoir plus

Dagger 2 : http://google.github.io/dagger/

Butter Knife : http://jakewharton.github.io/butterknife/

Android Annotations : http://androidannotations.org/

Présentation sur Dagger : http://fr.slideshare.net/pyricau/sharper-better-faster-dagger-droidcon-sf