• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Mis à jour le 15/04/2019

Découvrez l’Architecture Components

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Si vous lisez ce cours, c'est que normalement, votre niveau est déjà assez avancé dans le développement d'applications mobile sur Android... :)

A force de développer des mini-applications grâce aux différents cours de notre parcours Android, vous vous êtes peut-être posé la question suivante : existe-t-il une architecture logicielle optimale pour développer une application Android ?

Tout à fait ! Car il est vrai que parfois, mes contrôleurs (activités et/ou fragments) me semblent un peu trop gros... :'(

Exactement ! Ce phénomène, connu sur iOS sous l'appellation "Massive View Controller", se produit lorsqu'un de vos contrôleurs (activités et/ou fragments) contient beaucoup trop de code et qu'il en devient presque illisible voire instable, et quasiment intestable.

C'est vrai que j'ai tendance à écrire beaucoup de choses dans mes activités... Mais il faut dire que la moindre fonctionnalité sur Android demande beaucoup de lignes de code !

Nous sommes d'accord ! :D De plus, comme vous l'avez déjà probablement remarqué sur Android, vos contrôleurs ont un cycle de vie assez particulier. En effet, ces derniers peuvent être détruits à n'importe quel moment, emportant avec eux l'ensemble des données qu'ils contenaient. Cela peut être produit 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.

Mais que fait la police ? (Enfin Google hein !) >_<

Eh bien au début pas grand chose... et là était tout le problème ! Les développeurs Android étaient livrés à eux-mêmes, et tentaient plus ou moins d'appliquer une certaine architecture sur leur projet, respectant un maximum les bonnes pratiques de développement comme "la séparation des préoccupations" ou "separation of concerns (SoC)" en anglais : une classe = une responsabilité, une méthode = une action particulière, etc...

Certains ont même décidé de se passer de l'architecture MVC et de se lancer dans des architectures plus "propres" comme le MVP, le MVVM ou encore la Clean Architecture, avec plus ou moins d'adoptions de la part de la communauté Android... Vous trouverez des exemples à ce lien.

C'est dans ce contexte assez tendu que les équipes de Google ont décidé de sortir, à la fin de l'année 2017, un ensemble de librairies permettant de créer plus facilement des applications robustes, testables et maintenables dans le temps... qu'ils ont appelé : l'Android Architecture Components ! 

Quels sont les deux principes fondateurs de l'Architecture Components ?

Afin d'architecturer le mieux possible une application Android, l'Architecture Components se base sur deux principes fondateurs :

  1. Les contrôleurs (Activités ou Fragments) devraient servir UNIQUEMENT à manipuler l'interface graphique (création, mise à jour, etc...) et interagir avec le système d'exploitation (lancement d'une nouvelle activité par exemple). C'est tout ! Le reste du code métier doit absolument être déporté dans des classes à part.

  2. L'interface graphique devrait être généralement mise à jour à partir d'une classe modèle (POJO), de préférence persistable, et la refléter (modélisation) le plus fidèlement possible. L'objectif est de faire face plus facilement à une perte de connexion internet ou à la destruction de votre application, en récupérant le modèle persisté directement depuis le stockage de votre téléphone (à partir d'une base de données, par exemple... ;)).

Essayez d'avoir toujours ces deux principes en tête quand vous développez une application Android, cela vous permettra naturellement de vous poser les bonnes questions en termes d'architecture.

De quels éléments se compose l'Architecture Components ?

Android Architecture Components
Exemple de l'Android Architecture Components

Dans l'objectif d'alléger un maximum les contrôleurs (activités et fragments) de nos applications Android, il a fallu déporter certaines actions dans des classes dédiées. Ainsi, les équipes d'Android ont fait le choix de poser l'architecture suivante :

  1. Le contrôleur : Votre contrôleur (activité ou fragment) sera dédié à la manipulation de votre interface graphique, ni plus, ni moins.

  2. Le ViewModel : Le contrôleur implémentera toutefois une classe de type ViewModel, dont le rôle sera de fournir au contrôleur les données utilisées par l'interface graphique. Une des spécificités de la classe ViewModel est sa capacité à "survivre" aux changements de configuration comme la rotation de l'écran par exemple, sans perdre ses données... :magicien:

  3. Les LiveData : Les données présentes au sein du ViewModel seront principalement de type LiveData, type qui nous permettra "d'observer" plus facilement leurs changements tout en respectant le cycle de vie de notre application. Le type LiveData correspond en quelque sorte à la notion d'Observable sous RxJava que nous avons déjà étudiée ensemble dans un précédent cours, à ceci près que nous n'avons pas besoin de gérer nous-même le processus de désinscription et que LiveData a été pensé pour Android et son cycle de vie. Si en revanche, vous souhaitez continuer à utiliser RxJava plutôt que LiveData, sachez que cela est tout à fait possible ! :)

  4. Le Repository : A l'intérieur de chaque ViewModel, nous allons retrouver une ou plusieurs classes de type Repository, un design pattern assez connuSon rôle est un peu particulier car il nous servira de médiateur entre le ViewModel et les différentes sources de données.

  5. Les sources de données :  A l'intérieur de chaque Repository, nous aurons les différentes classes permettant d'accéder à nos données, que l'on appelle plus communément "les sources de données" (Data Sources). Par exemple, ces classes peuvent prendre la forme de DAOs, comme celles que nous avons créées dans les chapitres précédents, ou encore d'interfaces de communication avec des APIs, comme nous avons pu le faire dans ce cours

Bon je sais, tout ça est un peu théorique ! D'ailleurs, il est fort probable que vous vous demandiez pourquoi il y a un niveau de découpe aussi important... En fait, sachez que plus votre code sera découpé, plus il sera modulable, testable et lisible.

Sur des mini-applications, il est vrai que le résultat n'est peut-être pas flagrant et il sera difficile de s'en rendre compte. Cependant, quand votre projet commencera à grossir et peser quelques centaines de milliers de lignes de code, vous serez très heureux d'avoir une architecture propre et maintenable, croyez-moi... ;) 

Allez, passons aux choses sérieuses et implémentons tout cela dès le prochain chapitre, à travers notre mini-application SaveMyTrip !

Exemple de certificat de réussite
Exemple de certificat de réussite