Gérez vos données localement pour une application Android 100 % hors-ligne

Tout est en place pour finaliser l’utilisation de la base de données ! Il est donc temps de créer une instance de la base de données en y appliquant les éléments de configuration décidés précédemment.

Créez une instance de la base de données

Pour créer une instance de la base de données tout en y appliquant la configuration souhaitée, Room utilise le patron de conception Builder.

Pour démarrer l’utilisation du patron de conception Builder,

1. utilisez la méthode statiqueRoom.databaseBuilder()qui accepte trois paramètres :

   • unContext;

   • la classe conteneur de la base de données ;

   • le nom du fichier db dans lequel persister la base de données.

2.  Puisqu’il s’agit du patron de conception Builder, appelez la méthodebuild()pour obtenir l’instance de la base de données.

final PETiSoinDatabase database =  Room.databaseBuilder(appContext, PETiSoinDatabase.class, "PETiSoinDatabase").build();

val database = Room.databaseBuilder(appContext, PETiSoinDatabase::class.java, "PETiSoinDatabase").build()

Appliquez la configuration

C’est bon, nous avons une instance de la base de données. Cependant, la configuration définie plus tôt n’a été appliquée qu’en partie. En effet, uniquement la partie liée au stockage a été considérée. Les prochaines lignes seront donc consacrées à l’application du reste de la configuration.

Gérez le threading

Pour la gestion du threading, bonne nouvelle nous n’avons rien à faire. En effet, comme expliqué précédemment, par défaut, Room garantit que l’accès à la base de données ne se fasse jamais à partir du thread principal. Ça permet d’utiliser un thread adapté pour les opérations I/O (in/out).

Gérez la migration du schéma de la base de données

Puisqu’il s’agit de la toute première version de la base de données, il n’est pas nécessaire de gérer des migrations. Cependant, Room offre plusieurs solutions pour gérer les migrations du schéma de votre base de données.

Par défaut, Room va tenter de gérer lui-même la migration du schéma de votre base de données. Si les modifications sont simples, Room devrait s’en sortir. Dans le cas contraire, une exception sera levée. Deux stratégies peuvent alors être mises en place.

1. La première stratégie, et peut-être la plus radicale, est de demander à Room de purement et simplement supprimer la base de données pour la recréer. Pour cela, vous pouvez utiliser la méthodefallbackToDestructiveMigration()qui détruira la base de données pour la reconstruire.

2. La seconde stratégie est d’aider Room à gérer les migrations entre deux versions du schéma de votre base de données et ainsi éviter de perdre l’ensemble des données qui y seraient stockées. Pour ce faire, vous pouvez utiliser la méthodeaddMigrations(). Pour chacune des migrations proposées à Room, il est nécessaire de préciser une version de départ et une version d'arrivée. Room exécute ces migrations pour mettre à jour la base de données vers la version la plus récente. Chaque migration vous permet de manipuler un objetSupportSQLiteDatabase vous permettant de manipuler directement la base de données SQLite à travers des requêtes SQL.

Gérez le pré-embarquement des données

Pour pré-embarquer des données, Room offre également plusieurs possibilités.

1. La première est d’utiliser la méthodeaddCallback(). Cette méthode accepte en paramètre une instance de la classeRoomDatabase.Callback dont la méthodeonCreateest automatiquement appelée lors de la création de la base de données. Cette méthode permet de manipuler un objetSupportSQLiteDatabaseoffrant alors la possibilité d’écrire des requêtes SQL pour insérer des données par exemple.

2. La seconde option est de créer la base de données sur les bases d’un fichier db. Il est alors possible d’utiliser les méthodescreateFromAsset(),createFromFile()ou  createFromInputStream().

Limitez le nombre de connexion

Quand on manipule des bases de données, on limite généralement à une seule le nombre de connexions à la base de données. En effet, cela ne sert pas à grand-chose de réinitialiser la connexion à la base de données à chaque fois que l’on souhaite l’utiliser.

Pour limiter le nombre de connexions, il est possible d’utiliser le patron de conception Singleton. Le but de ce patron de conception est de limiter l’instanciation d’une classe à un seul objet. Lorsque le programme a besoin d’instancier une classe qui implémente le patron de conception Singleton, une vérification est faite. Si aucune instance de la classe existe alors elle est créée puis renvoyée pour être utilisée. Cependant, si une instance existe déjà, elle est directement renvoyée pour être utilisée.

L’instance est stockée dans la mémoire vive et vie donc pendant toute la durée de vie de l’application mobile. Elle ne survit cependant pas à son arrêt.

L'implémentation du patron de conception donne cela.

@Database(entities = {Animal.class, Note.class}, version = 1, exportSchema = true)
@TypeConverters({Converters.class})
public abstract class PETiSoinDatabase extends RoomDatabase
{
  private static volatile PETiSoinDatabase INSTANCE;
  public abstract AnimalDao animalDao();
  public abstract NoteDao noteDao();
  public static PETiSoinDatabase getDatabase(Context context) 
  {
    if (INSTANCE == null) 
    {
      synchronized (PETiSoinDatabase.class) 
      {
        if (INSTANCE == null) 
        {
          INSTANCE = Room.databaseBuilder(context.getApplicationContext(), PETiSoinDatabase.class, "PETiSoinDatabase").build();
        }
      }
   }
    return INSTANCE;
  }
}

@Database(entities = [Animal::class, Note::class], version = 1, exportSchema = true)
@TypeConverters(Converters::class)
abstract class PETiSoinDatabase : RoomDatabase() 
{
  companion object 
  {
    @Volatile
    private var Instance: PETiSoinDatabase? = null
    fun getDatabase(context: Context): PETiSoinDatabase 
    {
      // if the Instance is not null, return it, otherwise create a new database instance.
      return Instance ?: synchronized(this) {
        Room.databaseBuilder(context, PETiSoinDatabase::class.java, "PETiSoinDatabase")
          .build()
          .also { Instance = it }
      }
    }
  }
  abstract fun animalDao(): AnimalDao
  abstract fun noteDao(): NoteDao
}

Pour utiliser la base de données, il convient simplement d’utiliser ce Singleton.

final Animal animal = PETiSoinDatabase.getDatabase(appContext).animalDao().getAnimalById(1);

val animal = PETiSoinDatabase.getDatabase(appContext).animalDao().getAnimalById(1)

Voici une vidéo qui récapitule les principales étapes pour finaliser et utiliser correctement votre base de données.

À vous de jouer !

Contexte

C’est l’étape finale de l’implémentation technique de la rubrique “Santé” de l’application PETiSoin !

Dans le projet, disponible sur GitHub (Java ou Kotlin), l'entité Vaccine, le DAO VaccineDaoet le convertisseur de type Converters ont été référencés. 

Consignes

Créez une instance de la base de données et limitez le nombre de connexions à une seule. Pour ce faire, mettez en place le patron de conception Singleton pour limiter le nombre d'instances de la base de données à une seule.

Livrables

Vous pouvez dupliquer le projet GitHub pour modifier le code source du projet et fournir un projet qui compile.

En résumé

• Il est possible de configurer Room pour indiquer si les opérations sur la base de données peuvent s’effectuer sur le thread principal ou pas.

• Room offre la possibilité de pré-peupler la base de données au moment de sa création.

• En cas de changement majeur dans le schéma de la base de données entre deux versions, il est de préciser de configurer la politique de migration.

• Les bonnes pratiques de développement logiciel recommandent d’implémenter le patron de conception Singleton pour limiter la connexion à la base de données à une unique instance.

Vous avez maintenant une base de données fonctionnelle pour l’application PETiSoin. Nous pouvons à présent rendre son utilisation encore plus robuste en testant la base de données et en utilisant une architecture logicielle moderne et maintenable au sein de l’application.