Monitoring d’une application mobile avec React Native

UNE ASSISTANCE TECHNIQUE ? NOUS SOMMES DISPONIBLES UNE ASSISTANCE TECHNIQUE ? NOUS SOMMES DISPONIBLES

Accéder au sommaire de “Guide pratique du développeur React Native”

Le monitoring d’une application mobile est fondamental tant il existe des dizaines de combinaisons possibles entre les systèmes d’exploitation, leurs versions et les types de périphériques potentiels. Cet article de Wikipedia liste les 28 versions d’Android ! Lorsqu’on y ajoute les mobiles, les modèles et les marques, il peut y avoir plusieurs centaines de combinaisons, rien que pour Android. Côté iOS, il existe une quinzaine de versions et une vingtaine de modèles.

Lorsqu’on développe une application pour le Web, seuls Chrome, Firefox, Edge et Safari sur Windows et Mac suffisent à couvrir 99% de ses utilisateurs. Le monde mobile n’a malheureusement pas cette chance. Il faut des outils adaptés, ce domaine ne laisse aucune place à l’improvisation.

Faire l’impasse sur cette partie vous expose à de nombreuses difficultés car la satisfaction client en dépend. On ne compte plus le nombre de notes et avis utilisateurs sur les stores impactées essentiellement par des applications qui plantent régulièrement ou des applications simplement pas ou peu réactives.

Comment comprendre le contexte et la nature d’un bug ayant causé un crash si aucun journal d’événement n’est créé ? Comment identifier précisément le mobile vulnérable à un bug puis le corriger et vérifier l’efficacité du correctif ? C’est tout l’objet de cet article.

Google Firebase

Cet article se focalise essentiellement sur Google Firebase. C’est encore une fois un avis subjectif.

Pour avoir eu la possibilité de tester plusieurs plateformes Cloud, Firebase est l’outil le plus simple à mettre en oeuvre, l’offre Spark ne nécessite aucune saisie préalable de moyen de paiement et surtout, l’intégration avec React Native au travers du SDK RN Firebase est d’une efficacité redoutable. Dossardeur fonctionne en production aujourd’hui avec des volumes assez significatifs et plusieurs centaines d’utilisateurs sans avoir déboursé un seul euro.

L’offre Spark intègre non seulement le test, la captation d’audience et la distribution en béta mais aussi et surtout Crashlytics/Fabriq, fruit du récent rachat de la société éponyme. La console firebase intègre à un seul et même endroit tous les outils de qualité nécessaires.

Qualité

La Qualité en production est le service qui regroupe la stabilité d’une application mobile (Crash, …) et ses performances (latence, temps d’exécution,…). Si vous avez une application extrêmement stable mais aux performances calamiteuses, l’expérience utilisateur en sera impacté. L’inverse est également vrai. La qualité est le résultat apporté par le couple Stabilité & Performance.

Audience

L’autre paramètre à prendre en compte concernant une application mobile est l’audience. Qui utilise mon application et comment ? Dans un but commercial (cibler les besoins) ou simplement pour mieux comprendre ses utilisateurs. Certains écrans sont peu ou pas utilisés ? Cela signifie peut-être qu’ils ne répondent à aucun besoin. D’autres, au contraire, sont centraux et incontournables ? Il est peut-être temps de concentrer ses effort sur ceux là afin d’optimiser leur performance de manière spécifique.

Dans les deux cas précédents, Google Firebase apporte une réponse complète.

React Native Firebase

Il est important de bien comprendre dans un écosystème dont les Cloud assurent les services techniques  que les SDK sont incontournables. Le SDK est la glue qui fait le lien entre l’application Android/iOS et Google Firebase. Les remontées d’information doivent être opérées du mobile vers la plateforme dans toutes les situations. Ce SDK doit être stable, aussi complet que les services proposés par le Cloud et surtout bien documenté.

React Native Firebase rempli toutes ses exigences. Initié par la société Invertase, RNFirebase a contribué à l’adoption de Google Firebase dans le monde React Native. Il suffit simplement d’ajouter les dépendances de React Native Firebase dans son projet pour bénéficier instantanément des services de Google Firebase avec le Spark Plan gratuit.

React Native Firebase supporte TypeScript, gère les Hooks React, et fournit tous les services de Google Firebase :

  • AdMob : Affichage des bandeaux de publicité sur son application
  • Analytics : L’analyse d’audience. Ce service est utilisé dans Dossardeur.
  • Authentication : Permet à une application de gérer de multiples modèles d’authentification (Social, Github, …) avec un minimum de code
  • Cloud Firestore : La base de données noSQL de Google
  • Cloud Functions : Gestion des fonctions Serverless
  • Cloud Messaging : Gestion des Notifications. Ce service est utilisé dans Dossardeur
  • Cloud Storage : Serveur de contenu (images, vidéos, assets en tous genres, …)
  • Crashlytics : Fruit du rachat de la société éponyme, un temps appelé Fabric. Ce service joue un rôle majeur dans Dossardeur pour gérer les crash.
  • Dynamic Links : Les liens natifs multi plate-formes sont souvent un casse tête à gérer. Les liens dynamiques facilitent la création de liens vers des applications natives.
  • In-app Messaging : Ce sont les notifications affichées au sein d’une application.
  • Instance ID : Identifier de manière unique une application mobile à un instant T (notification, appel de services avec un jeton, etc…)
  • ML Kit Natural Language et ML Kit Vision : Outils de Machine Learning
  • Performance Monitoring : Outils pour la traçabilité et le monitoring. Ce service est utilisé dans Dossardeur pour tracer les goulots d’étranglement.
  • Realtime Database : Base de données temps réel
  • Remote Config : Permet de stocker des informations globales sécurisées d’une application. Ce service est utilisé dans Dossardeur pour stocker des informations contextuelles comme une maintenance ponctuelle du serveur ou l’authentification anonyme.

Installation et configuration

L’installation et la configuration de RNFirebase pour iOS et Android est parfaitement bien documentée, il faut tirer un chapeau à l’équipe de développement car les évolutions de Google Firebase sont constantes, le SDK React Native se doit de les suivre régulièrement.

Performance et traçabilité dans Dossardeur

Les bénéfices apportés par Google Firebase sont inestimables pour Dossardeur. Réaliser de tels services techniques en mode DIY (Do It Yourself) aurait été simplement impossible. Un des exemples de ces bénéfices est la traçabilité des crash avec Crashlytics. Le nombre de versions d’OS (iOS & Android) est tel que certains périphériques peuvent générer un nombre important de crash. Il faut pouvoir les déceler très tôt, les corriger et vérifier la disparition des instabilités. En ajoutant dans le code React quelques lignes de ce type, l’application mobile devient instantanément gérée :

import firebase from '@react-native-firebase/app';
export const bootstrap = async (store :GlobalState ) => {
    logInfo('[Bootstrap] starting ....');
    firebase.crashlytics().setCrashlyticsCollectionEnabled(!__DEV__);
    firebase.analytics().setAnalyticsCollectionEnabled(!__DEV__);
    firebase.perf().setPerformanceCollectionEnabled(!__DEV__);
    (...)
}

Lorsqu’un crash survient, un évènement détaillé est écrit dans un journal interne. Ce journal est envoyé au serveur Google Firebase qui va centraliser les crash par catégorie (mobile, version de l’application, système d’exploitation, etc…) adossé aux traces applicatives . Voici à titre d’exemple un crash des rares crash survenus dans Dossardeur. On peut s’apercevoir que la pile Java est décrite dans la zone “Issues”.

En zoomant sur la pile d’erreur, on s’aperçoit que le problème est lié à l’absence de la balise <Text>.

On peut ainsi visualiser facilement le périphérique (Galaxy S10+), la version, l’OS et l’heure à laquelle le crash est survenu. L’onglet “Data” contient des informations plus détaillées.

Ce service est absolument indispensable pour comprendre les dessous d’une application mobile et anticiper la satisfaction de ses utilisateurs.

Les compteurs de performances

Rien n’est plus frustrant qu’une application qui de temps à autre se met à ralentir. Il peut y avoir une infinité de raisons à cela, un Wifi défaillant, une 4G instable, un backend aux abois. Comment déceler le maillon faible dans toute cette chaîne ?  La réponse se trouve dans les compteurs de performances.

Ces compteurs, lorsqu’ils sont placés dans le code en amont de la chaîne d’appel vont remonter toutes sortes d’informations à la console firebase. Pour éviter d’avoir à systématiquement copier/coller le code consistant à créer un point de performance, ce qui est fastidieux, il est important de mettre en place une stratégie de génération de SDK.

En utilisant un outil tel que Swagger côté backend, il suffit de générer le code permettant de réaliser les appels avec une bibliothèque du type Fetch ou Axios. Ainsi, en utilisant simplement un intercepteur global, l’ensemble des appels aux services du backend sont monitorés par Firebase.

export let defaultApiconfig: ConfigurationParameters = {
    fetchApi: fetch,
    basePath: Config.BASE_PATH,
    middleware: [{
        pre: async (context: RequestContext): Promise<void> => {
            fetchState.pending = true
            setTimeout(() => {
                fetchState.pending = false
                metric.stop();
            }, 10000);
            metric = firebase.perf().newHttpMetric(context.url, 'GET');
            await metric.start();
            logInfo('[API] REQUEST ' + context.url  + ' ' + context.init.method);
        },
        post: async (context: ResponseContext): Promise<void> => {
            fetchState.pending = false;
            metric.setHttpResponseCode(context.response.status);
            metric.setResponseContentType(context.response.headers.get('Content-Type'));
            await metric.stop();
            logInfo('[API] RESPONSE : ' + context.url + ' Http Status=' + context.response.status);
        }
    }]
};

const apiconfig: Configuration = new Configuration(defaultApiconfig);
const apiCompetitions: CompetitionAPIApi = new CompetitionAPIApi(apiconfig);

// Tout appel dans le code de la forme suivante génère un envoi de compteurs
await apiCompetitions.getCompetitionsByFilter(...);

Le code précédent montre la manière de centraliser les compteurs des performances mais aussi l’affichage des sabliers à chaque appel de service. Dossardeur utilise cette technique en écoutant FetchState.pending via mobX.

La documentation de RNFirebase propose également un exemple d’implémentation avec Axios. Remarquez dans l’exemple précédent l’utilisation de la variable contextuelle userId pour enrichir les compteurs avec des informations utilisateur. Cela permet non seulement de détecter la nature des lenteurs mais également d’identifier le mobile ou l’utilisateur impacté par ces lenteurs.

Voyons maintenant à quoi ressemble la console Firebase lorsqu’il s’agit de déceler les goulots d’étranglement. Dans l’onglet “Performances” de la console, il est possible là encore de filtrer par version, périphériques, OS, etc … Dans le cas de Dossardeur, on peut s’apercevoir que les temps d’appel sont plutôt corrects (en moyenne en dessous de la demi-seconde)

En plus des temps de réponse par version, la pile Firebase nous offre également des temps par pays, version d’OS, type de mobile et type de réseau. Le SDK Firebase étant intégré au système côté client, la remontée d’informations est telle qu’on peut même benchmarker les opérateurs télécom, les types de mobiles et les réseaux.

Celui qui dispose d’un Galaxy S10+ chez SFR en 4G sous Android 10 aura des performances optimales avec Dossardeur. Ce qui parait somme toute logique, on parle ici de matériels et logiciels récents.

A noter que ces données de performances client doivent toujours être mises en corrélation avec l’outil de télémétrie côté serveur. Dossardeur utilise la plateforme Open Dossard qui s’appuie sur Swagger Stats.

UNE ASSISTANCE TECHNIQUE ? NOUS SOMMES DISPONIBLES UNE ASSISTANCE TECHNIQUE ? NOUS SOMMES DISPONIBLES