Que trouverez-vous dans cet article?
En 2016, j'ai commencé à apprendre Java, et début 2017, Android. Dès le début, je savais déjà qu'il y avait un concept d'architecture d'application, mais je ne savais pas comment l'appliquer dans mon code. J'ai trouvé de nombreux guides différents, mais cela n'a pas été plus clair.
Cet article est exactement celui que je voudrais lire au début de mon voyage.
L'importance de l'architecture d'application
De nombreuses entreprises effectuent des tests techniques pour les candidats sélectionnés. Les tests peuvent varier, mais il y a une chose qui les unit. Tous nécessitent de la compréhension et la capacité d'utiliser une bonne architecture logicielle.
Une bonne architecture logicielle facilite la compréhension, le développement, la maintenance et la mise en œuvre du système [Livre "Clean Architecture", chapitre 15]
Le but de cet article est d'enseigner à quelqu'un qui n'a jamais utilisé l'architecture pour développer des applications Android. Pour ce faire, nous considérerons un exemple pratique d'application, lors de la création duquel nous mettons en œuvre la solution la moins flexible et une solution plus optimale utilisant l'architecture.
Exemple
Éléments dans une RecyclerView:
- Nous recevrons des données de l'API et montrerons les résultats à l'utilisateur.
- Le résultat sera une liste de bières avec un nom, une description, une image et une teneur en alcool pour chacune.
- La bière doit être commandée par degré de forteresse.
Pour résoudre ce problème:
- Nous devons obtenir des données de l'API.
- Trier les éléments du plus bas au plus haut degré de la forteresse.
- Si la teneur en alcool est inférieure à 5%, un cercle vert sera dessiné, s'il est compris entre 5% et 8% - le cercle sera orange et au-dessus de 8% - un cercle rouge.
- Enfin, nous devons montrer une liste d'articles.
Quelle est la solution la moins flexible?
La solution la moins flexible consiste à créer une classe qui satisfera aux quatre points précédents. C'est la décision que n'importe lequel d'entre nous prendrait si nous ne savions pas quelle est l'architecture des applications.
Le résultat pour l'utilisateur sera acceptable: il verra une liste ordonnée à l'écran. Mais si nous devons faire évoluer ce système, nous comprendrons que la structure n'est pas facile à comprendre, à développer, à maintenir et à mettre en œuvre.
Comment comprendre l'architecture des applications sous Android?
Je vais donner un exemple très simple. Imaginez une usine automobile avec cinq zones:
- La première zone crée le châssis.
- La deuxième zone relie les pièces mécaniques.
- La troisième zone recueille un circuit électronique.
- Le quatrième domaine est la peinture.
- Et la dernière zone ajoute des détails esthétiques.
Cela signifie que chaque zone a sa propre responsabilité, et elles travaillent en chaîne de la première à la cinquième pour obtenir un résultat.
Un tel système présente un avantage certain. Si la voiture donne une erreur après qu'elle soit terminée, alors en fonction de son comportement, nous saurons quel service devrait la réparer sans déranger les autres.
Si nous voulons ajouter plus de détails esthétiques, nous passerons directement à la cinquième section. Et si nous voulons changer la couleur, nous passons au quatrième. Et si nous changeons le châssis, cela ne changera pas le fonctionnement de la zone de peinture. Autrement dit, nous pouvons modifier notre machine point par point sans déranger toute l'usine.
De plus, si au fil du temps nous voulons ouvrir une deuxième usine pour créer un nouveau modèle de voiture, il sera plus facile de diviser les zones de travail.
Architecture d'application Android
Nous allons nous assurer qu'il n'y a pas de classe qui ferait tout le travail seul: demander des données à l'API, les trier et les afficher. Tout cela sera réparti sur plusieurs zones appelées couches.
Quelles sont ces couches?
Pour cet exemple, nous allons créer une architecture propre, qui se compose de trois niveaux, qui à leur tour seront divisés en cinq:
- Niveau de présentation.
- Le niveau de la logique métier.
- Et le niveau de données.
1. Niveau de présentation
Le niveau de présentation est le niveau utilisateur, une interface graphique qui capture les événements de l'utilisateur et lui montre les résultats. Il vérifie également qu'il n'y a pas d'erreurs de formatage dans les données saisies par l'utilisateur et que les données affichées s'affichent correctement.
Dans notre exemple, ces opérations sont réparties entre la couche d'interface utilisateur et le niveau ViewModel:
- La couche d'interface utilisateur contient des activités et des fragments qui capturent les événements utilisateur et affichent les données.
- La couche ViewModel formate les données de sorte que l'interface utilisateur les affiche d'une manière spécifique.
Au lieu d'utiliser ViewModel, nous pouvons utiliser une autre couche qui remplit cette fonction, il est simplement important de comprendre les responsabilités de chaque couche.
Dans notre exemple, la couche d'interface utilisateur affiche une liste de bières et la couche ViewModel indique une couleur que vous devez utiliser en fonction de la gamme d'alcool.
2. Le niveau de la logique métier
À ce niveau se trouvent toutes les exigences commerciales auxquelles l'application doit répondre. Pour cela, les opérations nécessaires sont effectuées ici. Dans notre exemple, il s'agit du tri des bières de la plus faible à la plus forte.
3. Couche de données
À ce niveau sont les données et la manière d'y accéder.
Ces opérations sont réparties entre le niveau du référentiel et le niveau de la source de données:
- La couche référentiel implémente une logique d'accès aux données. Sa responsabilité est d'obtenir des données. Il est nécessaire de vérifier où les chercher à un certain moment. Par exemple, vous pouvez d'abord vérifier la base de données locale et, s'il n'y a pas de données, faire une demande à l'API et enregistrer les données dans la base de données. Autrement dit, il détermine la façon d'accéder aux données. Dans notre exemple, il demande des données sur la bière directement au niveau qui interagit avec l'API.
- La couche source de données est directement responsable de la réception des données. Dans notre exemple, il implémente la logique d'accès API pour obtenir des données sur la bière.
Comment les couches interagissent-elles?
Regardons les approches théoriques et pratiques de l'interaction.
En théorie:
Chaque couche ne doit communiquer qu'avec ses voisins immédiats. Dans ce cas, si nous regardons le diagramme d'architecture logicielle:
- L'interface utilisateur ne peut communiquer qu'avec ViewModel.
- ViewModel ne peut communiquer qu'avec le niveau de la logique métier.
- Le niveau de logique métier ne peut communiquer qu'avec le niveau du référentiel.
- Et le référentiel ne peut communiquer qu'avec la source de données.
En pratique:
Structure du package dans l'IDE Android Studio avec une architecture propre:
Nous avons une structure de package dans laquelle des classes sont créées, chacune ayant son propre domaine de responsabilité.
Remarques finales sur l'architecture d'application
Nous avons vu que chaque niveau d'architecture logicielle a son propre domaine de responsabilité et ils sont tous interconnectés.
Il est important de souligner que nous n'avons jamais parlé des bibliothèques ou langages de programmation utilisés, car l'architecture est axée sur la bonne structuration du code afin qu'il soit évolutif. Les bibliothèques changent avec le temps, mais les principes de l'architecture demeurent.
De plus, il est recommandé de lire sur l' injection de dépendances afin d'éviter de créer des instances d'objets directement dans les classes d'architecture et, ainsi, de pouvoir effectuer des tests unitaires à l'aide de Mockito et JUnit.
Je partage un référentiel où vous pouvez voir:
- Un exemple d'architecture Android propre avec Kotlin.
- Utilisez LiveData pour connecter l'interface utilisateur au ViewModel.
- L'utilisation de la corutine.
- Kodein pour l'injection de dépendance.
- JUnit et Mockito pour tester la logique métier.