React Native : un seul code pour iOS et Android

React-Native (RN) est un framework Javascript d’applications mobiles créé par Facebook en 2015. Il s’appuie sans surprise sur les fonctionnalités de React, qui est en pleine expansion.
React-Native corrige la réputation parfois malheureuse des applications cross-platform, telles que Ionic ou Xamarin qui n’utilisent pas de code natif.

Le code dit « natif » est un langage utilisé pour un OS spécifique. Entendons par là Objective-C ou Swift pour iOS et Java ou Kotlin pour Android.
Un des gros avantages de RN, c’est que le code Javascript qui sera élaboré va communiquer, grâce au concept de bridge, avec les composants natifs de chaque OS.

Création d’un projet

Pour initier un projet React-Native, il existe deux possibilités : 

• React-Native CLI 
• Expo CLI. 

Par ailleurs, si vous connaissiez create-react-native-app, ou CRNA pour “les intimes”, sachez que cette solution est désormais portée par Expo.
Les deux CLIs sont installables via npm ou yarn mais ce dernier est connu pour mieux gérer les dépendances que npm.

Aussi, Expo prend en charge et automatise un certain nombre de choses mais, si vous souhaitez bénéficier d’un contrôle plus fin, React Native CLI répondra parfaitement à vos besoins.
Pour les pro Typescript, il est possible de démarrer un projet avec un template TS en utilisant un simple paramètre à la création du projet.

Ensuite lors de vos développements, vous aurez sans doute recours à des librairies externes comme pour la navigation ou les notifications et vous les installerez via npm ou yarn. Si votre librairie ne requiert aucune configuration supplémentaire, vous pourrez continuer à coder sans encombre.

D’ailleurs, il y a encore peu de temps, avec les versions de React-Native antérieures à la 0.60, une autre étape était nécessaire au bon fonctionnement natif de votre application mobile : react-native link. Depuis les versions 0.60+, le link se fait automatiquement, donc nul besoin de s’en préoccuper désormais.
Enfin, l’étape « link » consiste à télécharger les dépendances natives de vos librairies et nous expliquerons pourquoi dans la partie suivante.
 

Dom React-Native

Comme c’est le cas pour React, React-Native utilise un DOM spécifique.

Pour rappel, React est basé sur un DOM virtuel qui lui permet, grâce à une API, de mettre à jour uniquement les nœuds qui ont été modifiés ainsi que leurs nœuds enfants, ce qui le rend très rapide.

Le workflow de React-Native va donc fonctionner de la même manière que React, à quelques exceptions près.

Prenons un exemple : lorsque vous créez une page web il vous est possible d’écrire du texte dans une simple balise <div>. Si on essaie de faire l’équivalent sur React-Native en utilisant une balise <View>, une erreur va se déclencher et la raison est simple.

Si on se réfère au code natif, sur Android par exemple, on ne peut afficher du texte que dans un élément TextView : 

React-Native se doit donc d’appliquer le même concept puisqu’il utilise les composants mobiles natifs, grâce au concept de bridge que nous avons évoqué plus haut.
 

Lorsque deux applications back et front doivent communiquer à travers un protocole comme HTTP, dans la majeure partie des cas, elles s’échangent les données sous le format JSON. React-Native va alors appliquer le même principe en envoyant ses données au compilateur natif de chaque OS.
C’est pourquoi, lorsqu’on ajoute des librairies externes, il est nécessaire de « linker » pour que le Javascript puisse communiquer avec les composants natifs, téléchargés par l’étape « link », des différents OS.

En reprenant l’exemple de l’élément TextView sur iOS, le code interprété ressemblera donc à cela :

“UIManager.createView([1,‘‘RCTRawText’’,1,{‘‘text’’:‘‘Text view for capfi’’}])”

Une subtilité subsiste dans cet exemple. Sachant que chaque compilateur va travailler la donnée à sa manière, il faut bien se douter que tous les systèmes auront leur propre rendu.

C’est pourquoi en utilisant un même composant React-Native, on aura parfois des petites différences entre les versions iOS, Android et autres.

Navigation

A la différence d'une application Web, les applications mobiles n’ont pas besoin d’avoir une URL vers laquelle naviguer (non vous n’avez jamais tapé d’URL sur une véritable application mobile).
En revanche, la navigation vers une vue doit pourtant bien se faire et c’est pour cela que les vues sont simplement nommées.

Pour organiser ces pages, la librairie React Navigation est extrêmement utile et permet de gérer efficacement les trois principaux types de navigation :

1. StackNavigator : comme son nom l’indique il va gérer avec efficacité les différentes vues qui ont été affichées, en alimentant une pile. Cette pile va augmenter au fur et à mesure que les vues sont visitées, mais ce n’est pas tout.

Lorsque vous allez utiliser le bouton retour, généralement en haut à gauche, qui est automatiquement géré et personnalisable, les éléments supérieurs de la pile sont automatiquement supprimés.

Idem lorsque vous utiliserez le Hardware Back Button sur Android, les vues seront retirées de la pile au fur et à mesure que vous ferez marche arrière.
 

Toutes les vues de votre contexte doivent être définies dans votre StackNavigator pour pouvoir y accéder.

Une autre utilité de ce type de navigation est de pouvoir créer plusieurs stacks. Par exemple, si vous souhaitez séparer les vues utilisées pour l’authentification de celles qui composent le cœur de votre application, vous pouvez créer deux stacks qui seront entièrement distincts.

Ainsi vous ne pourrez pas afficher une vue qui ne soit pas définie au préalable dans la stack voulue.

2. TabNavigator : le TabNavigator représente la navigation par onglets.

Comme le StackNavigator, il prendra en éléments enfants les différentes vues qui seront accessibles via ses onglets à travers plusieurs paramètres, comme le titre de l’onglet, son icône ou sa couleur.

3. DrawerNavigator : le DrawerNavigator est plus connu sous le nom de side menu.

Il est très souvent accessible via un « burger button » ou avec un « Swipe right » partant depuis l’extrémité gauche de votre mobile. Dans la pratique il prendra en paramètre une simple vue qui sera partiellement superposée, selon vos réglages, à vos vues.

Déploiement d’une application

Lorsque votre application est prête à être déployée ou testée plusieurs choix s’offrent à vous en fonction de l’OS, mais un certain nombre d’étapes sont communes aux différents systèmes :

1. Nom de l’application
2. Logo de l’application
3. Description succincte et détaillée
4. Captures d’écran dans différents formats

Android

Du côté Android, quatre types de build sont souvent utilisés à l’aide de Grad le : 

1. InstallDebug : ce premier build est celui qui est utilisé lorsque vous lancez votre application en debug avec un AVD (Android Virtual Device) lancé ou qu’un smartphone Android est connecté, dans mode adéquat, à votre ordinateur.

2. AssembleDebug : ce build génère un apk de debug que vous pouvez transmettre et installer pour des tests, sur un smartphone physique ou un AVD.

3. AssembleRelease : comme le précédent, ce build génère aussi un apk, mais celui est configuré en release. La configuration en release est valide si l’apk est signé avec une keystore de release.

4. BundleRelease : ce quatrième build, au format aab (Android App Bundle) et sans doute le plus important, a plusieurs utilités. C’est le seul build accepté par Google Play lorsqu’on veut publier une application. Google Play utilise ce bundle pour optimiser les apks en fonction de l’appareil sur lequel l’application est installée.
Une autre possibilité intéressante de ce bundle pour les applications volumineuses, est de pouvoir envoyer sur le store un apk de taille réduite et de rendre optionnel le téléchargement de contenu additionnel pour l’application.

Ainsi, lorsque tout est prêt pour une publication sur le store, la première validation est longue et des corrections sont parfois nécessaires.
Ensuite, pour la mise à jour d’une application existante, seules quelques heures seront suffisantes pour une validation ainsi qu’une mise à disposition.

iOS

Chez Apple, le système de publication est assez différent.
Xcode, environnement de développement pour iOS, ainsi qu’un compte Apple Developer sont indispensables pour le déploiement d’une application sur l’AppStore.
 

Un simple Product -> Archive vous suffit à générer le bundle utilisé pour une release, le tout suivi d’un Distribute App pour envoyer votre application sur l’AppleStore Connect.

Cependant, il ne faut pas oublier d’alimenter votre Info.plist avec les différents messages liés aux possibles demandes d’autorisations de votre application sans lesquelles elle sera rejetée.

Contrairement au Play Store, la validation de votre application ou d’une nouvelle version de celle-ci est réalisée par une véritable personne et c’est pourquoi il faut compter 48h à 72h pour une mise en ligne.