#Le pattern Repository

Dans cette partie, nous allons mettre en place le pattern Repository pour gérer les informations de l’utilisateur connecté.

• Comme expliqué dans la fiche ressource “Architecture Google”, le pattern Repository permet de séparer la logique métier de la logique de stockage des données.
• Ça tombe bien, on commence à avoir des chemins complexes d’après notre diagramme de séquence :

Et encore je n’ai pas modélisé les chemins d’erreurs…

On va donc implémenter un Repository pour alléger le ViewModel et le rendre plus lisible.

#🧠 Notions

• Refactoring du code actuel pour mettre en place le design pattern Repository

Voilà ce que nous allons faire :

Comme vous le voyez, notre viewModel n’a plus qu’a s’occuper de son UIState et d’appeler le Repository pour les actions métiers.

#✅ Complétez les tâches suivantes

• Créez un AccountRepository, il doit n’avoir pour responsabilité que la gestion de l’authentification, de la déconnexion et de la sauvegarde de l’utilisateur connecté.
• Injectez le AccountRepository dans le AccountViewModel via le constructeur.

#🛟 Aide

• N’oubliez pas de bien séparer les responsabilités entre le ViewModel et le Repository.
• Un Repository ne contient pas de coroutineScope, c’est le viewModel qui appelera les fonctions du Repository dans son coroutineScope.
• Le Repository contiendra une instance de DataStore pour sauvegarder / récupérer les informations de l’utilisateur connecté.
• Votre viewModel ne saura qu’un utilisateur est connecté que si le DataStore le signale, via le Repository.