Aller au contenu

Introduction

Le système d'exploitation Android fournit une base solide pour la création d'applications qui fonctionnent bien sur un large éventail d'appareils et de facteurs de forme. Cependant, des problèmes tels que des cycles de vie complexes et l'absence d'une architecture d'application recommandée rendent difficile l'écriture d'applications robustes. Les composants d'architecture Android fournissent des bibliothèques pour des tâches courantes telles que la gestion du cycle de vie et la persistance des données, afin de faciliter la mise en œuvre de l'architecture recommandée.

Les composants d'architecture vous aident à structurer votre application d'une manière robuste, testable et maintenable avec moins de code boilerplate.

Quels sont les composants d'architecture recommandés ?

Lorsqu'il s'agit d'architecture, il est utile de voir d'abord la vue d'ensemble. Pour introduire la terminologie, voici un bref aperçu des composants d'architecture et de la manière dont ils fonctionnent ensemble. Chaque composant est expliqué plus en détail lorsque vous l'utilisez dans ce cours pratique.

Le diagramme ci-dessous montre une forme de base de l'architecture recommandée pour les applications qui utilisent les composants d'architecture. L'architecture se compose d'un contrôleur d'interface utilisateur, d'un ViewModel qui fournit LiveData, d'un référentiel et d'une base de données Room. La base de données Room est basée sur une base de données SQLite et accessible via un objet d'accès aux données (DAO). Chaque composant est décrit brièvement ci-dessous. Vous implémentez les composants dans cette pratique.

Architecture diagram

Parce que tous les composants interagissent, vous rencontrerez des références à ces composants tout au long de ce guide pratique, voici donc une brève explication de chacun d'eux.

Entity (Entité) : Dans le contexte des composants d'architecture, l'entité est une classe annotée qui décrit une table de base de données.

Base de données

SQLite : Sur l'appareil, les données sont stockées dans une base de données SQLite. La bibliothèque de persistance Room crée et maintient cette base de données pour vous.

Base de données Room : Simplifie le travail de base de données et sert de point d'accès à la base de données SQLite sous-jacente (cache SQLiteOpenHelper). La base de données Room utilise le DAO pour émettre des requêtes vers les données SQLite.

DAO : Acronyme de Data Access Object, qui signifie objet d'accès aux données. Il s'agit d'un mappage de requêtes SQL en fonction. Auparavant, vous deviez définir ces requêtes dans une classe d'assistance. Lorsque vous utilisez un DAO, votre code appelle les fonctions, et les composants s'occupent du reste.

Repository : Une classe que vous créez pour gérer plusieurs sources de données. En plus d'une base de données Room, le Repository peut gérer des sources de données distantes telles qu'un serveur Web.

ViewModel: Fournit des données à l'interface utilisateur (UI) et agit comme un centre de communication entre le référentiel (Repository) et l'UI. Masque l'arrière-plan à l'UI. Les instances de ViewModel survivent aux changements de configuration de l'appareil.

LiveData: Une classe de conteneur de données qui suit le modèle d'observateur, ce qui signifie qu'elle peut être observée. Contient et met toujours en cache la dernière version des données. Notifie ses observateurs lorsque les données ont changé. En général, les composants de l'interface utilisateur observent les données pertinentes. LiveData est sensible au cycle de vie, elle gère donc automatiquement l'arrêt et la reprise de l'observation en fonction de l'état de l'activité ou du fragment qui l'observe.