Votre application à l’heure actuelle n'est pas très riche puisqu’elle affiche uniquement des écrans statiques. Dans cette partie, nous allons nous charger de la rendre dynamique, et en particulier l’écran qui affiche les questions du quiz. Nous allons par la même occasion apprendre à organiser notre code dans les règles de l’art, pour vous donner toutes les billes par la suite pour construire des applications de qualité.
Découvrez l’architecture MVVM
Dans ce chapitre, nous allons introduire une notion d'architecture logicielle, afin de l'appliquer à notre application SuperQuiz.
Lorsque vous développez une application Android, vous êtes libre d'organiser votre code comme vous le souhaitez. Toutefois, pour faciliter la collaboration avec vos collègues, structurer votre code et surtout vous assurer de sa maintenabilité, il est préférable d’utiliser un patron d’architecture.
La raison d’être d’un patron d’architecture
Mais pourquoi vouloir structurer le code d’une application avec un patron d’architecture ? Ne peut-on pas tout simplement écrire tout le code dans l'activité ou le fragment ?
Nous avons vu dans la partie 2 de ce cours que les activités et les fragments ont un cycle de vie assez particulier. En effet, ils peuvent entre autres être détruits à n'importe quel moment, emportant avec eux l'ensemble des données qu'ils contenaient. Cela peut se produire lors de rotations, ou lorsqu'un appel téléphonique arrive, ou tout simplement lorsque le téléphone n'a plus de batterie... Et ces cas de figure sont très compliqués à gérer pour nous, développeurs et développeuses.
De plus, si nous écrivons tout le code de notre application dans la classe d’une activité ou d’un fragment, c’est-à-dire la déclaration des éléments d’interface, les interactions avec ces éléments, la récupération des données et leur stockage, nous créons ce que l’on appelle du code spaghetti. C’est du code avec des interconnexions dans tous les sens, qui est difficile à comprendre et à maintenir. Alors autant dans une assiette, les spaghettis c’est sympa, autant dans le code d’une application, ça donne surtout des nœuds au cerveau.
C’est pour éviter ces situations qu’il existe différents patrons d’architecture, comme MVC, MVI, MVP ou encore MVVM. En 2017, pour aider davantage les développeurs et développeuses à structurer leur code, à faire un choix entre tous ces patrons, et pour homogénéiser les pratiques utilisées au sein de l’écosystème Android, Google a décidé de préconiser officiellement l’architecture MVVM.
Penchons-nous donc sur le patron d’architecture qui a gagné la bataille des patrons d’architecture.
L’architecture MVVM
MVVM signifie Model-View-ViewModel. Le principe de conception fondamental appliqué par tout bon patron d’architecture, et en particulier par l’architecture MVVM, est la séparation des responsabilités, séparant comme son abréviation l’indique les données (Model) de la vue (View), et mettant à disposition une classe de type ViewModel pour communiquer entre les données et la vue. C’est en appliquant ce principe que nous sortons du patron “Code spaghetti”.
Les couches Vue et Données
MVVM isole donc dans le code deux parties distinctes. D’un côté les éléments correspondant à la vue, de l’autre côté les éléments représentant les données de l’application. On appelle ces différentes parties des couches d’architecture.
Ainsi, comme le montre le schéma ci-dessous :
Dans la couche Vue, nous retrouvons la déclaration des éléments d’interface et la logique UI, c'est-à-dire le code relatif uniquement à la manipulation de ces éléments d’interface. Concrètement, la déclaration des éléments d’interface correspond au code XML d’une activité ou d’un fragment. La logique UI correspond au code Java responsable par exemple de la gestion du clic sur un bouton, de la gestion de la visibilité d’un élément d’interface, du changement de couleur d’un élément, etc.
Au sein de la couche Données, on retrouve bien entendu les données qui peuvent provenir de sources diverses (base de données locale, API externe, etc), mais également toute la logique métier permettant de récupérer ses données, de les modifier et de les sauvegarder.
D’accord, mais comment les couches Vue et Données font-elles pour communiquer entre elles ? En d’autres termes, à quoi correspond la flèche qui relie les deux couches sur le schéma précédent ?
La réponse à cette question se trouve dans l’abréviation MVVM. Nous avons vu que le premier “M” pour Model correspond à la couche Données. Le “V” correspond à la couche Vue. Il nous reste donc “VM” pour ViewModel. Ce sigle désigne une classe de type ViewModel qui est chargée de faire le lien entre la couche Vue et la couche Données. ViewModel est en fait un pattern de développement qui n’est d’ailleurs pas spécifique à Android.
Le pattern ViewModel
Le pattern ViewModel a pour rôle de préparer les données dont un écran de l’application aura besoin (la couche Vue).
Il a deux objectifs sous-jacents :
Exposer à la Vue les données finales que l’interface doit représenter ; on appelle ces données des états.
Mettre à disposition de la Vue des fonctions correspondant à des événements chargés de modifier les données suite aux interactions ayant lieu sur l’interface.
Mais qu’est-ce qu’un état ?
Un état désigne toute valeur susceptible de changer au fil du temps. Que ce soit une variable dans une classe, une valeur stockée en base de données, ou encore une valeur fournie par une API tierce. Les écrans de nos applications Android sont, en fait, une représentation à un instant t des différents états qui la composent.
Et qu’est-ce qu’un événement ?
Un événement désigne toute modification pouvant avoir lieu dans une application et ayant un impact sur l’état de l’interface : une interaction de l’utilisateur comme un clic sur un bouton, une saisie, un scroll, mais également toute mise à jour d’un paramètre intrinsèque à l’application ayant un impact sur celle-ci, par exemple un décompte qui se termine au sein d’une application de type “Minuteur”.
Dans les faits, le pattern ViewModel se matérialise tout simplement par une classe, qui a accès à la couche Données, et qui est chargée de gérer les événements et de personnaliser les données dont a besoin l’interface.
Si nous mettons à jour le schéma précédent avec ce nouveau concept, cela donne :
En résumé
Appliquer un patron d’architecture permet de structurer le code d’une application dans le but de le rendre plus lisible, maintenable et testable.
Il existe différents patrons d’architecture, mais Google préconise aujourd’hui l’architecture MVVM.
MVVM signifie Model-View-ViewModel.
MVVM applique le principe de conception de séparation des préoccupations en structurant le code d’une application en deux couches : Vue et Données, avec une classe de type ViewModel pour faire la liaison entre ces deux couches et personnaliser les données en fonction des besoins de la vue.
Une classe de type ViewModel expose à la vue les données à afficher, appelé états, et expose des fonctions permettant de manipuler l’état en réponses aux événements qui ont lieu sur l’interface.
Cela fait beaucoup de théorie ; passons maintenant à la pratique en mettant en place l’architecture MVVM pour gérer les données du quiz et dynamiser notre application. Pour cela, nous allons d’abord partir des données pour les faire redescendre étape par étape jusqu’au ViewModel qui sera par la suite utilisé pour dynamiser l’écran de quiz de notre application.
