Utilisation de la base de données des salles | Android Jetpack

Ashish Rawat

Feb 23, 2019 – 6 min lu

Pour ceux d’entre vous qui ne savent pas ce qu’est Android Jetpack alors

Android Jetpack est une collection de composants logiciels Android pour rendre plus facile pour vous de développer de grandes applications Android.
Ils vous aideront à

Suivre les meilleures pratiques
Vous libérer de l’écriture de code boilerplate.
Simplifier les tâches complexes, afin que vous puissiez vous concentrer sur le code qui vous intéresse.

Voici la vidéo de la chaîne Android Developers Channel:

Parlons maintenant de Room

Room est une bibliothèque de persistance, faisant partie de l’Android Jetpack.

Voici la vidéo de Android Developers Channel:

Room fournit une couche d’abstraction sur SQLite pour permettre un accès fluide aux bases de données tout en exploitant toute la puissance de SQLite.

Room est maintenant considéré comme une meilleure approche pour la persistance des données que SQLiteDatabase. Il facilite le travail avec les objets SQLiteDatabase dans votre application, en diminuant la quantité de code passe-partout et en vérifiant les requêtes SQL au moment de la compilation.

Vérification des requêtes SQL au moment de la compilation. chaque @Query et @Entity est vérifié au moment de la compilation, cela préserve votre application des problèmes de crash au moment de l’exécution et non seulement il vérifie la seule syntaxe, mais aussi les tables manquantes.
Code boilerplate
Facilement intégré avec d’autres composants de l’Architecture (comme LiveData)

Les problèmes majeurs avec l’utilisation de SQLite sont

Il n’y a pas de vérification au moment de la compilation des requêtes SQL brutes. Par exemple, si vous écrivez une requête SQL avec un nom de colonne erroné qui n’existe pas dans la base de données réelle, alors il donnera une exception pendant l’exécution et vous ne pouvez pas capturer ce problème pendant la compilation.
Comme votre schéma change, vous devez mettre à jour les requêtes SQL affectées manuellement. Ce processus peut prendre du temps et être source d’erreurs.
Vous devez utiliser beaucoup de code boilerplate pour convertir entre les requêtes SQL et les objets de données Java (POJO).

Room vs SQLite

Room est une bibliothèque ORM, Object Relational Mapping. En d’autres termes, Room va mapper nos objets de base de données en objets Java. Room fournit une couche d’abstraction sur SQLite pour permettre un accès fluide aux bases de données tout en exploitant la pleine puissance de SQLite.

Différence entre SQLite et la bibliothèque de persistance Room:-

Dans le cas de SQLite, Il n’y a pas de vérification au moment de la compilation des requêtes SQLite brutes. Mais dans Room, il y a une validation SQL au moment de la compilation.
Vous devez utiliser beaucoup de code passe-partout pour convertir entre les requêtes SQL et les objets de données Java. Mais, Room mappe nos objets de base de données en objet Java sans code boilerplate.
Lorsque votre schéma change, vous devez mettre à jour manuellement les requêtes SQL affectées. Room résout ce problème.
Room est construit pour fonctionner avec LiveData et RxJava pour l’observation des données, alors que SQLite ne le fait pas.

Room est génial

Composants de Room DB

Room a trois composants principaux de Room DB :

Entity
Dao
Database

Entity

Représente une table au sein de la base de données. Room crée une table pour chaque classe qui a @Entity annotation, les champs de la classe correspondent aux colonnes de la table. Par conséquent, les classes d’entités ont tendance à être de petites classes de modèle qui ne contiennent pas de logique.

Annotations d’entités

Avant de commencer à modéliser nos entités, nous devons connaître certaines annotations utiles et leurs attributs.

@Entity – chaque classe de modèle avec cette annotation aura une table de correspondance dans la DB

foreignKeys – noms des clés étrangères
indices – liste d’indications sur la table
primaryKeys – noms des clés primaires des entités
tableName

@PrimaryKey – comme son nom l’indique, cette annotation pointe la clé primaire de l’entité. autoGenerate – si elle est définie à true, alors SQLite va générer un id unique pour la colonne

@PrimaryKey(autoGenerate = true)

@ColumnInfo – permet de spécifier des informations personnalisées sur la colonne

@ColumnInfo(name = "column_name")

@Ignore – le champ ne sera pas persistant par Room

@Embeded – les champs imbriqués peuvent être référencés directement dans les requêtes SQL.

Dao

Les DAO sont chargés de définir les méthodes qui accèdent à la base de données. Dans le SQLite initial, nous utilisons les objets Cursor. Avec Room, nous n’avons pas besoin de tout le code lié aux Cursor et pouvons simplement définir nos requêtes en utilisant les annotations de la classe Dao.

Database

Contenant le détenteur de la base de données et servant de point d’accès principal pour la connexion sous-jacente aux données relationnelles persistantes de votre app.

Pour créer une base de données, nous devons définir une classe abstraite qui étend RoomDatabase. Cette classe est annotée avec @Database, liste les entités contenues dans la base de données, et les DAO qui y accèdent.

La classe qui est annotée avec @Database doit satisfaire les conditions suivantes :

être une classe abstraite qui étend RoomDatabase.
Inclure la liste des entités associées à la base de données dans l’annotation.
Contenir une méthode abstraite qui a 0 argument et retourne la classe qui est annotée avec @Dao.

Au moment de l’exécution, vous pouvez acquérir une instance de Database en appelant Room.databaseBuilder() ouRoom.inMemoryDatabaseBuilder().

Étape 1 : Ajouter les dépendances Gradle

Pour l’ajouter à votre projet, ouvrez le fichier build.gradle au niveau du projet et ajoutez la ligne surlignée comme indiqué ci-dessous:

2. Ouvrez le fichier build.gradle de votre application ou module et ajoutez les dépendances:

Étape 2 : Créer une classe de modèle

Room crée une table pour chaque classe annotée avec @Entity ; les champs de la classe correspondent aux colonnes de la table. Par conséquent, les classes d’entités ont tendance à être de petites classes de modèle qui ne contiennent pas de logique. Notre classe Person représente le modèle pour les données de la base de données. Mettons-la donc à jour pour indiquer à Room qu’elle doit créer une table basée sur cette classe :

Annotez la classe avec @Entity et utilisez la propriété tableName pour définir le nom de la table.
Définissez la clé primaire en ajoutant l’annotation @PrimaryKey aux champs corrects – dans notre cas, il s’agit de l’ID de l’utilisateur.
Définissez le nom des colonnes pour les champs de la classe en utilisant l’annotation @ColumnInfo(name = "column_name"). N’hésitez pas à sauter cette étape si vos champs ont déjà le bon nom de colonne.
Si plusieurs constructeurs conviennent, ajoutez l’annotation @Ignore pour indiquer à Room ceux qui doivent être utilisés et ceux qui ne le sont pas.