Comprendre l’architecture MVVM sur Android 📱

Published in

AndroidMood

8 min readJun 30, 2021

En génie logiciel de nombreux patrons de conception existent dans le but de résoudre des problèmes bien précis, que ce soit pour remplir des exigences d’ordre architecturale, de cohérence, d’adaptabilité et de respect des bonnes pratiques. Cela dit, certains se sont démarqués au fil du temps au sein de la communauté de développement Android, il s’agit de MVVM, MVC, MVP et MVI; Chacun ayant ses particularités, ses avantages et ses inconvénients. Mais aujourd’hui nous nous focaliserons sur le design pattern le plus plébiscité par les développeurs Android selon de nombreux sondages: Model-View-ViewModel, communément abrégé MVVM. Qu’est-ce que MVVM? Comment est-ce qu’il fonctionne? Pourquoi Google le recommande comme le patron de conception idéal pour architecturer son application Android? Tant de questions s’offrent à nous, et c’est avec un grand plaisir que cet article nous apportera des réponses claires et précises.

I. MVVM c’est quoi concrètement ?

1. Généralités

D’après Wikipedia, Le modèle-vue-vue modèle (en abrégé MVVM, de l’anglais Model View ViewModel) est une architecture et une méthode de conception utilisée dans le génie logiciel.
Apparu en 2004, MVVM est originaire de Microsoft et adapté pour le développement des applications basées sur les technologies Windows Presentation Foundation (WPF) et Silverlight via l’outil MVVM Light par exemple.

MVVM nait du besoin de séparer la logique métier et l’accès aux données d’une application de son interface utilisateur, ceci dans le but d’accroitre la réutilisabilité du code, et ainsi favoriser sa maintenabilité par le principe de “Separation of concerns”.

Il sera plus tard adopté par Google qui y apportera des modifications structurelles dans le cadre du développement Android afin de répondre aux problématiques technologiques de plus en plus évoluantes de la plateforme. Le principe reste le même, 3 couches bien distinctes gardant les mêmes fonctions, mais l’approche Android apporte ses propres singularités technologiques comme LiveData, Lifecycles, bref, Android Architecture Components.

2. Structure

De manière générale, MVVM est structuré en 3 grandes parties:

Model

Le modèle représente l’ensemble des entités et des modèles de données dont aura besoin la vue pour présenter les informations à l’utilisateur.

View

La vue représente la partie visible de l’iceberg, ce sont les interfaces graphiques (activités, fragments), XML, les widgets, les animations, les textes et tous les composants en interaction directe avec l’utilisateur final. Elle constitue la partie visuelle de l’application, c’est la vitrine qui présente les informations fournies par le Model et traitées par le ViewModel

ViewModel

Le ViewModel représente la couche qui gère toute la logique métier de l’application, elle concerne les opérations de traitements qui s’opèrent entre la base de données et la vue, par exemple le formatage de données, l’envoi de paramètres vers les requêtes, la réception des données.

3. Les avantages et inconvénients

Comme avantages de MVVM nous pouvons citer:

La maintenabilité : Avec une séparation claire des différents modules du projet, il y’a une meilleure organisation structurelle, le code est plus lisible, mieux architecturé car respectant des standards bien définis et donc plus facile à maintenir. Les fonctionnalités étant regroupées dans dans le ViewModel, cela permet d’avoir des vues propres, dépourvues de code ‘spaghettis’.

La testabilité : Avec MVVM chaque bout de code est écrit de façon granulaire, les dépendances internes et externes sont séparées de la logique métier et l’ensemble des fonctionnalités à tester. Ce qui rend le code bien plus testable.

La réutilisabilité et l’extensibilité du code : MVVM facilite la possibilité d’ajout et de réutilisation du code par le principe de faible couplage de classes, cela a pour bénéfice de diminuer les risques de lourdes dettes techniques lors de maintenances évolutives.

Les inconvénients sont plus des contraintes d’ordre techniques, et dépendent donc fortement du développeur, par conséquent cela demeure un sujet très subjectif.

II. MVVM recommandé par Google pour les applications Android

1. Architecture

Voici comment se présente l’architecture MVVM pour le développement Android. Google a défini un ensemble de règles et de principes prenant en compte les différentes technologies de la plateforme afin de proposer une architecture cohérente et répondant aux besoins techniques de l’écosystème Android.

Le MVVM tel que recommandé par Google se repose sur Android Architecture Components, qui est un des 4 piliers de l’écosystème Jetpack.

Architecture Components est composé de:

Data Binding, Lifecycles, LiveData, Navigation et bien d’autres outils qui vous aident à concevoir des applications robustes, testables et maintenables.

Lifecycles et LiveData sont d’une importance capitale dans l’implémentation de MVVM, car ils permettent de prendre en considération les événements qui entrent en jeu au cours de l’existence de l’application, Lifecycle permet par exemple de ne pas refaire de requêtes réseau lorsque le smartphone subit une rotation, mais plutôt de conserver les données dans le cache et les recharger simplement sur la vue, évitant ainsi les fuites de mémoire ou Memory leaks.

Flow ou LiveData ?

Cependant, de nombreux développeurs font souvent une confusion entre l’utilisation de Flow et LiveData.

Astuce: Partez toujours du principe que le repository utilise Flow et le ViewModel, LiveData.

2. Implémentation

Afin de s’arrimer aux spécifications de Google, cet exemple est implémenté à partir des technologies suivantes:

Android Architecture Components (Lifecycle, LiveData, Room, ViewModel)
Hilt (Pour l’injection des dépendances)
Kotlin coroutines (Pour la gestion des flux de données de façon asynchrone)
Retrofit (Pour les appels HTTP)

Structure du projet

Le projet sera subdivisé en 7 parties, chacune ayant un rôle bien précis:

database : La base de données et ses objets(DAO, entités, mappers)

di : Les injections de dependances.

model : Les entités de notre modèle de données.

network : Les objets réponses pour appels réseaux, les mappers et les API.

repository : Le Repository.

ui : La vue et son viewModel

util : Les classes utilitaires.

Il est à noter que la hiérarchisation des packages dépend parfois des préférences et donc peut varier légèrement d’un développeur à l’autre, cependant le MVVM respecte toujours un certain formalisme de structure et de cohérence.

1. Créer l’objet State pour la gestion des états du réseau

Nous allons tout d’abord créer une classe utilitaire qui nous permettra de transmettre l’état de nos requêtes réseau à la vue.

DataState.kt (Pour récupérer le statut de la requête)

2. Créer le Model

On rappelle que le modèle englobe ici le repository, la source de données distante, la base de données locale, ainsi que les préférences partagées.

Network

BlogObjectResponse

On crée l’objet qui sera chargé de récupérer les réponses de notre API REST telles que formatées par le JSON.

L’objet de réponse de l’API

BlogApi

L’interface qui aura pour rôle d’exposer nos requêtes HTTP vers la source de données distante (service web).

Interface d’API

Mappers

Un mapper est une classe qui permet de formater correctement les données reçues à travers l’API afin de les utiliser de façon convenable, cela permet de récupérer uniquement les données utiles, encoder ou décoder les attributs, les convertir en liste ou en tableaux en fonction de nos exigences.

BlogMapper.kt (Classe de mappage de données pour l’entité Blog)

Repository

MainRepository

Le repository c’est le répertoire où proviennent toutes les données de l’application.

Notre MainRepository aura donc pour objectif de faire appel aux méthodes de l’API distante, de la base de données locale ou des préférences partagées, afin de nous retourner les données dont notre application aura besoin. Par ailleurs elle nous fera transmettre un message d’erreur ou de succès grâce à notre classe State.kt en fonction du résultat de nos requêtes.

Database

BlogDatabase

Création de la base de données avec la librairie Room. C’est un ORM développé par Google, qui fournit une couche d’abstraction entre la base de données SQLite et nos données sous forme d’objets. Elle a pour particularité sa facilité de prise en main et de déboggage.

BlogDAO

DAO ou Data Access Object, il s’agit d’interfaces propres à chacun de nos objets chargées de regrouper les opérations de persistances de données (CRUD) liées à nos différentes entités. Elles sont essentielles pour interagir avec la base de données. Chaque objet de la base de données possède son interface DAO.

3. Créer le ViewModel

MainViewModel

Le ViewModel contient tous les traitements qui s’effectuent dans le but de servir la vue, il est important de noter que chaque Activité/Fragment possède un et un seul ViewModel. Dans ce cas de figure, nous n’avons qu’une seule fonctionnalité, et donc MainViewModel qui est tout simple, permet de collecter les données (les articles du blog) à partir du repository en écoutant l’état de la requête afin de notifier le résultat à MainActivity.

Vous remarquerez l’utilisation de LiveData. En effet, MVVM repose sur la programmation réactive d’où la notion de LiveData qui sont des objets observables et lifecycle-aware, c’est à dire qu’ils permettent d’écouter les changements de comportements du ViewModel afin de traiter et communiquer les données à la vue de manière cohérente , tout en prenant en compte le cycle de vie des composants de la vue (lifecycle-aware).

4. Créer les vues

Notre partie vue sera composé de l’activité, de l’adapter pour la liste d’articles du blog, de l’UI pour l’activité en XML, de l’UI pour l’article en XML. Rien de bien compliqué ! Nous nous attarderons cependant sur l’activité et l’adapter.

BlogAdapter

MainActivity

C’est ici qu’on constate la grande force de MVVM, le code est épuré et simplifié, car toute la logique métier se trouve désormais relayée au ViewModel. La vue n’a plus qu’à écouter son ViewModel à travers LiveData et sa méthode observe pour adopter des comportements en fonction de l’état des données reçu. Dans ce cas de figure précis, il est question de peupler le RecyclerView avec les articles du blog en cas de succès ou alors afficher un toast en cas d’échec de l’opération.

Et le tour est joué ! 😍🔥

En utilisant Architecture Components, Kotlin Coroutines et Hilt, j’ai crée une application qui démontre comme implémenter simplement MVVM avec Hilt et Open API.

Pour plus de détails, je vous invite à cloner le repo Github du projet afin d’appréhender avec plus de profondeur les différentes notions de MVVM. Vous pourrez l’améliorer si vous le souhaitez et y ajouter des fonctionnalités pour vous exercer.

gabriel-TheCode/Dagger-Hilt-MVVM

Sample app that demonstrates the usage of Dagger Hilt with Kotlin & MVVM architecture by loading informations from Open…

github.com

Les technologies et les concepts de développement évoluent de façon exponentielle, il nous revient donc de préserver une veille technologique constante afin de rester à jour et produire des travaux de qualité, cependant, gardez toujours en tête qu’un patron de conception est choisi en fonction du problème rencontré et donc je vous recommande non pas d’en adopter un par défaut, ou parce que c’est le favori du moment, mais d’en étudiez plusieurs afin de décider lequel utiliser selon les problématiques que vous rencontrerez au quotidien dans les projets de développement logiciel.

MERCI à vous d’avoir pris la peine de lire cet article, n’hésitez pas à laisser quelques applaudissements si vous avez appris de nouveaux concepts et surtout pour encourager l’auteur. 😁👏👏👏

Suivez Android Mood pour plus de nouveautés !

A la prochaine !