Android, la navigation simplifiée avec Navigation Architecture Component

Introduction

Lors de la dernière Google I/O, Google a annoncé l’arrivée du Navigation Architecture Component au sein de la collection d’outils Android Jetpack (Anciennement Android Support Libraries).

Cette librairie met à disposition du code et des outils pour simplifier l’implémentation de la navigation dans une application Android.

C’est la réponse de Google aux problèmes rencontrés par les développeurs dans la mise en place de la navigation entre les écrans d’une application Android :

  • Gestion des transactions entre fragments.
  • Passage et récupération d’arguments entre fragments.
  • Comportement des boutons Up et Back : gestion du stack.
  • Implémentation d’un Deep linking cohérent.
  • Tester un Fragment en isolation.

La navigation dans une application Android AVANT cet outil

La navigation dans une application Android AVANT l’arrivée d’Android 3.0 : c’était le passage d’un objet Activity à un autre.

Le passage d’informations entre deux entités pouvait s’effectuer par l’ajout de paramètres dans le bundle de l’objet Intent et à un écran de l’application correspondait une classe Activity : La navigation était plutôt simple à gérer !

Avec l’apparition des tablettes et leurs écrans plus larges, de nouveaux besoins sont apparus. A partir d’Android 3.0 (API 11), la notion de fragments apporte davantage de possibilités de navigation au sein d’une application. Une activité pouvant être composée de plusieurs fragments : composants encapsulés et réutilisables qui possèdent leur propre cycle de vie et leur propre interface graphique.

De nouvelles possibilités, mais plus de complexité dans la gestion de la navigation :
passage d’informations entre les différents éléments (Activity et Fragment), gestion des transactions d’un fragment à l’autre, gestion de la pile des appels et du bouton retour etc…

La navigation dans une application Android AVEC cet outil

Avec cette nouvelle collection d’outil, Google propose une prise en charge rapide et plus aisée de la navigation, le Navigation Architecture Component se compose de 3 parties :

Le Navigation graph : un fichier resource XML de type Navigation qui contient les éléments du graphe de navigation de l’application.

Le Composant NavHost : un conteneur qui délègue la navigation du graphe à son NavController. Par défaut, ce fragment hérite de la classe NavHostFragment et servira de conteneur où les fragments seront placés.

Le composant NavController : un objet qui gère et orchestre la navigation. Chaque NavHost détient un NavController, dont le rôle est de gérer la navigation dans le le NavHost.

Avec une version d’Android Studio supérieure ou égale à 3.3, le graphe de navigation peut facilement être édité avec l’outil qui lui est associé : le Navigation Editor. Ce dernier, permet de  créer simplement des destinations reliées par des actions et même paramétrer les données qui seront transmises et les animations jouées lors des transitions.
Cet éditeur est également en lien avec les assistants qui permettront de créer le code rapidement de l’application.

Les Destinations

Les destinations sont toutes les parties de l’application que l’utilisateur peut atteindre via un événement de navigation : dans le graphe de navigation, elles sont reliées entre elles par des actions.

Un fragment, une activité, une action ou un placeholder peuvent faire office de destination.

Les Actions

Lorsqu’on relie les destinations entre elles, des éléments de type Action sont créés dans le graphe de navigation et dans le fichier XML du graphe.

Une Action peut porter plusieurs informations comme les animations des transitions entrantes et sortantes, mais aussi les arguments qui seront passés à l’Activity/Fragment de destination.

Les animations

Le choix des animations de transitions entrantes et sortantes depuis l’éditeur de graphe de navigation se fait de manière très simple puisque pour chaque transition possible, on aura le choix entre les animations prédéfinies et les personnalisées que l’on aurait ajouté dans le projet.

Implémentation

Pour permettre la navigation dans l’application et que celle-ci prenne en charge les événements systèmes (bouton de retour, icône de navigation, titre de la Toolbar… ), il est nécessaire de compléter le code de l’activité principale par quelques lignes qui viendront finaliser l’intégration au projet.

Après une ligne pour l’initialisation du composant NavController, un paramétrage des composants visuels du projet comme la Toolbar avec la classe NavigationUI et une surcharge de la fonction onSupportNavigateUp() : la navigation dans le projet de l’application mobile est complètement opérationnelle !

Il suffira alors d’utiliser navigate() pour déclencher la navigation vers la destination cible.

La librairie Navigation permet également de lier des destinations à un événement View.onClickListener de manière simple en générant un listener prêt à l’emploi (pour un bouton par exemple).

Conclusion

Avec cette librairie, Google propose un outil qui ressemble beaucoup à ce qui se fait sur iOS avec les storyboards et son composant UINavigationController.

Les storyboards permettent, toutefois, une édition plus poussée que l’éditeur de graphe de navigation puisque l’on peut créer une action directement depuis les vues d’un écran vers un autre du storyboard. La possibilité d’avoir des graphes imbriqués et plusieurs graphe de navigation est présente dans les deux outils.

Les actions du graphe de navigation sont plus facilement paramétrable que les segues qui sont leur équivalent dans les storyboards.

Cette solution de Google offrira donc une facilité de gestion de la navigation à tous les niveaux : gestion de la pile d’appels, gestion des transactions, passage des paramètres rendu plus sûr avec l’éditeur de graphe de navigation comme point central de toute la configuration.

La contrepartie de cette facilité et de cette richesse de paramétrage est le poids que la librairie ajoute au projet et la complexité induite par tant de possibilités de personnalisation.

L’apport de cette solution est indéniable sur des applications ayant une navigation simple, toutefois elle est encore trop jeune pour qu’il existe des retours sur son utilisation dans des applications avec une navigation plus complexe.

Quentin Klein

Tech Leader de l'agence de Paris
25 avril 2019

Quentin est CTO de La Mobilery. Accro au développement mobile, il est particulièrement intéressé par Android et Flutter.