Structure du projet
Durée : 1 h 30
Environnement de travail : Avoir installé sur son ordinateur Android Studio.
Prérequis :
Avoir les connaissances de base du langage Kotlin et de ces innovations par rapport à Java,
Avoir les bases du langage SQL,
Avoir des bases en programmation orientée objets.
Contexte :
Ce cours aborde la création d'une application de quiz, les questions s'afficheront sous forme de liste, la réponse d'une question entraînant l'affichage de la suivante.
L'utilisateur pourra se connecter via un écran de connexion et pourra augmenter son score personnel à chaque bonne réponse.
Les points gagnés dépendent de la difficulté de la question et / ou de la rapidité de réponse.
Les questions ainsi que les utilisateurs de notre application seront stockés en local via la librairie Room.
Les notions abordées seront les suivantes : la gestion d'un projet en suivant les préceptes d'une « clean architecture », l'affichage d'un recycleView pour gérer la liste de questions, l'utilisation des coroutines de Kotlin pour récupérer nos données et la mise en pratique de la POO dans un cas concret.
Objectif
Comprendre la structure du projet
Comprendre la circulation des données du projet
Contexte :
Il est indispensable avant de se lancer dans le code de choisir une architecture globale de fichier et une structure à suivre pour votre projet.
Cela assure une navigation naturelle des informations au sein de votre projet et diminue les possibilités d'anti-pattern et de fuites mémoires.
Fondamental :
Pour ce projet nous adopterons une circulation de données qui suivra les codes de la clean architecture présenté par Robert C. Martin qui est majoritairement adopté par la communauté pour développer des projets de grande envergure sans finir avec un code qui s'entremêle et qui perd en fiabilité.
L'architecture tourne autour de 5 étapes par lesquelles les données transitent :
La Datasource : c'est l'endroit où sont stockées les données c'est le plus souvent une base de données qui peut être locale ou externe. Dans notre cas, ce sera la base de données local Room à laquelle il faudra accéder grâce à des Data Access Object (DAO).
Les Repositories : ce sont les classes qui sont souvent des classes companion unique, qui permettent d'offrir des fonctions pour accéder aux données, à travers une abstraction de la datasource qui peut être soit une locale soit externe.
Les UseCase : aussi appelés interactors, ils permettent de faire le pont entre la Vue et les repositories, c'est ici que s'effectue tout le code logique qui accompagne les requêtes.
Les ViewModels : ils accompagnent chaque fragment et contiennent toutes les fonctions dont le fragment a besoin pour fonctionner. Cela peut être des appels aux useCase pour nourrir le fragment d'information, cela peut aussi être du simple code logique sans requête.
Les Fragments : les fragments sont la base de la chaîne. Ils doivent rester le plus ignorant possible, leur rôle est seulement d'afficher ce qui doit être affiché, ils ne doivent pas contenir de code logique ou de requêtes.
Le circuit des informations au sein de l'application sera donc le suivant :
Dao → Repositories → UseCase → ViewModel → Fragment
Les données de la datasource sont envoyées au fragment et le chemin inverse est adopté pour les requêtes.
En ce qui concerne la séparation des fichiers, on adoptera la séparation « By layer », nous aurons ainsi trois dossiers qui contiennent nos types de classes présentés au-dessus :
Présentation : cette couche contiendra tous les fragments dont le but est uniquement d'afficher des informations à l'utilisateur. Cette couche contiendra nos vues (fragments et activités) et nos viewModels.
Domain : c'est la couche qui contiendra le modèle et les classes objet de l'application ainsi que toutes les UseCases.
Data : cette couche aura pour rôle de faire la liaison entre notre application et le monde extérieur (dans notre cas ce sera la base de données Room). Cette couche sera composée de nos repositories.
