Petit (re) tour des Bétas Firebase
Si comme moi vous avez bavé devant le Firebase Dev Summit 2017 mais que vous n’avez pas eu le temps de tester les nouveautés, voici un bref aperçu en image des dernières Béta de la suite d’outils mobile de Google, j’ai nommé Firebase.
N.B. : Pour commencer je tiens à préciser que tout ce qui est décrit ici utilise les fonctionnalités gratuites de Firebase, et qu’il y aura du code dans ce post. Pour ceux qui ne sont pas familiers avec tout ça ou qui n’ont jamais mis les mains dedans voilà quelques liens utiles :
Disclaimer : Vous pouvez retrouver le code de mon pot pourri Android sur Github, c’est du Java je suis pas un Hypster du Kotlin. Pour ceux qui ne savent pas ce que c’est, un pot pourri est un mélange de trucs qui a pour but de sentir bon, CQFD.
1) Performance Monitoring
En deux mots, cet outil permet de mesurer des temps de traitement afin de vous permettre d’optimiser votre application. Une expérience utilisateur dégradée entraîne souvent la désinstallation d’une application, monitorer les performances de votre application vous permettra de détecter les traitements anormalement longs. Dans cet exemple on va mesurer le temps d’affichage du contenu d’une WebView !
Oui on sait WebView = mort d’un chaton mais ça sert bien notre exemple donc je suis pardonné…
Donc comme je disais on va essayer de charger une page web (le site BEWIZYU par exemple) dans notre app et de monitorer le temps d’affichage de celle-ci. Pour ça rien de plus simple, on configure les dépendances Gradle et on pose notre Trace comme suit :
Ensuite on lance notre application et on attend, on attend, on attend… C’est assez frustrant pendant le développement parce que c’est très long (1/2j) à arriver sur la console. Mais une fois que c’est là on est content et on constate que les données relevées sont plutôt intéressantes.
👍 Par défaut on a également le droit à des stats sur les appels réseaux émis par nos apps. Plutôt pas mal foutu et intéressant avec des répartitions par MIME/type et code retour (200, 4XX, 5XX), des temps de réponse moyens et des tailles de payload envoyés/reçus. Tout ça par version d’OS, version d’App, niveau d’API, etc… A creuser dans un autre post peut-être 😊
C’est toujours intéressant de savoir mesurer des temps de chargement à distance donc je vous encourage à en abuser.
2) A/B Testing (Remote Config, le principe est le même pour les notifs)
Maintenant qu’on sait mesurer le temps de chargement de notre contenu web on va essayer de comparer deux manières de le générer.
Faisons entrer dans l’arène :
Disons que nous avons une application existante qui utilise du HTML brut et que notre cellule R&D (ouais parce qu’on est un grand groupe et tout) nous assure qu’on gagnerait en performances avec ReactJS. Grâce aux Remote Config et l’A/B Testing nous allons pouvoir valider cette hypothèse sur une partie de nos utilisateurs.
Pour ce faire nous allons enregistrer les temps de chargement pour chacune de ces deux méthodes dans notre WebView, cela nous permettra ensuite de valider ou infirmer l’hypothèse et de basculer l’intégralité de nos utilisateurs sur la solution la plus performante (et donner une promotion à /virer notre responsable R&D).
Voici donc notre test A/B créé à l’aide de la doc of course.
La configuration comporte 3 étapes :
- La Cible, c’est à dire la ou les applications visées par le test, le pourcentage d’utilisateurs à intégrer dans le panel ainsi que des critères de version ou de langue (pratique pour le push par exemple) ou encore issus des autres outils Firebase (Analytics, Predicitons, etc…)
- La Variante, une variable issue de Remote Config qui va être modifiée selon la cible.
- L’Objectif, la metric que vous voulez concrétement voir s’améliorer sur votre panel de test. Comme d’habitude cette mesure peut être choisie dans une liste pré-définies (engagement, fidélisation, …), ou en lien avec Crashlytics (crash-free users) ou encore via vos Events issus de Firebase Analytics. Dommage j’aurais bien aimé donner comme objectif la Trace précédemment créée… Peut-être dans une prochaine release! 🤞
Pour intégrer ça dans votre app rien de plus simple.
J’ai choisi d’héberger les pages webs d’exemple sur Firebase également par soucis de cohérence / flemme => Voir le dossier web du repo.
Ensuite il ne vous reste plus qu’à attendre que vos utilisateurs fassent le sale boulot et prendre une décision en conséquence. Forcément de mon côté c’est me, myself and I donc Firebase ne me trouve pas de “meilleure” variante.
Si aucune solution ne se démarque vous pouvez “augmenter la distribution”, c’est à dire augmenter le nombre d’utilisateur présents dans votre panel de test afin d’avoir plus de données à comparer. Par contre si une solution sort du lot vous pouvez l’étendre à tout vos utilisateur via le menu, 3 petits points sur la droite > Déployer à 100%.
L’A/B Testing côté Notifications est exactement le même mais la variante et les objectifs sont différents. On joue surtout avec le message à envoyer et on contrôle plutôt avec un “taux d’ouverture de la notification”.
Pour conclure, l’A/B Testing c’est la vie. Toute personne un tant soit peu concernée par ses utilisateurs devrait s’en servir.
3) Crashlytics
C’est le nouvel outil de rapport de crash acquis par Google plus tôt cette année. On va l’utiliser pour s’assurer qu’on casse rien en faisant notre petite expérience :) => https://firebase.google.com/docs/crash/android pour l’installation, aucune ligne de code n’est nécessaire dans un premier temps pour recevoir le suivi des crash.
Disclaimer : Je suis pas du tout objectif car gros fanboy de Fabric/Crashlytics
L’intégration a beau être mille fois meilleure que Firebase Crash Reporting (aka the 💩) elle n’en reste pas moins bien en dessous de ce que proposait Fabric… Autant on peut dire que les données sont bien présentes et que l’intégration dans le code est toujours aussi simple (quoi que pas complètement brandée Firebase, exemple la dépendance sur io.fabric.tools:gradle ou les appels réseau sur settings.crashlytics.com), autant niveau UX/UI les gars de Fabric doivent avoir les yeux et les oreilles qui saignent… Mais bon, on va dire qu’on est sur la bonne voie.
Le dashboard n’est pas beau mais les détails techniques sont toujours aussi pertinents donc on ne se plaint pas. Exemple ce magnifique crash causé par moi-même quand je me suis gourré de constructeur dans ma WebView.
👌 Nouveauté intéressante de Firebase Analytics, la StreamView. Pas aussi puissante que celle d’Answers et à première vue plutôt complexe à utiliser. Mais elle a le mérite d’exister comme on dit!
La vraie révolution Fabric étant basée sur Crashlytics + Answers, l’intégration de Crashlytics seul n’est pas suffisante. On a bien du crash reporting mais Firebase Analytics ne couvre pas toutes les metadatas qu’apportait Fabric 😭
En conclusion, il me semble important de souligner que ces outils ont beau être simples et puissants au premier abord, il n’en reste pas moins qu’une forte réflexion amont est nécessaire afin d’en tirer parti.
Une campagne d’A/B Testing se doit d’être réfléchie en terme d’entrants et de metrics de contrôle. De même, mesurer les performances de tout et n’importe quoi dans une application n’a pas de sens, il faut savoir reconnaître et cibler les chemins critiques de vos applications.
Quoi qu’il en soit c’est toujours meilleur quand c’est gratuit !
Voilà pour aujourd’hui, dans le prochain article si j’ai le temps je me lancerai dans Firestore, Predictions ou le serverside-rendering via Functions ou un truc qui n’a rien à voir.
Enjoy! 😘
“Remember - BEWIZYU, always”…
