Share
Lorsque nous développons une application complexe, nous rencontrons généralement des problèmes qui avaient probablement déjà été abordés et qui offrent déjà de très bonnes solutions. Ces solutions sont souvent appelées modèles. Nous parlons généralement de modèles de conception et de modèles architecturaux. Ils simplifient le développement et nous devrions les utiliser chaque fois qu'il convient de les utiliser.
Ce tutoriel devrait vous aider à comprendre l'importance d'un projet bien conçu et à comprendre pourquoi l'architecture standard d'Android n'est pas toujours suffisante. Nous discutons de quelques problèmes potentiels que vous pouvez rencontrer lors du développement d'applications Android et je vous montrerai comment résoudre ces problèmes en améliorant la testabilité et la fiabilité de l'application via le Présentateur de modèle Modèle (MVP).
Dans ce tutoriel, nous explorons:
Dans la première partie de ce didacticiel, nous nous intéresserons à la théorie du modèle MVP. La deuxième partie de ce tutoriel est plus pratique.
La conception d'un projet devrait être une préoccupation dès le début. L’une des premières choses à considérer est l’architecture que nous prévoyons d’adopter, car elle définira les relations entre les différents éléments de notre application. Il établira également des règles de base pour nous guider pendant le développement.
En général, un framework ou un SDK s'attend à ce que les choses soient faites d'une certaine manière, mais ce n'est pas toujours le bon pour un projet. Parfois, il n’existe pas de manière prédéfinie ou correcte de procéder, laissant les décisions de conception aux développeurs. Le SDK Android s’attend à ce que les choses se fassent d’une certaine manière, mais cela n’est pas toujours suffisant ni le meilleur choix..
Bien qu'Android offre un excellent SDK, ses schémas architecturaux sont assez inhabituels et peuvent facilement vous gêner pendant le développement, en particulier lors de la création d'applications complexes qui doivent être testées et maintenues longtemps. Heureusement, nous pouvons choisir parmi plusieurs solutions architecturales pour résoudre ce problème..
C'est une question délicate. Certains pourraient dire qu’il n’ya aucun problème avec l’architecture proposée par Android. Certes, cela fait le travail. Mais pouvons-nous faire mieux? Je crois fermement que nous pouvons.
Les outils proposés par Android, avec les dispositions, les activités et les structures de données, semblent nous orienter vers le modèle MVC (Model View Controller). MVC est un modèle solide et bien établi qui vise à isoler les différents rôles d’une application. Ceci est connu comme séparation des préoccupations.
Cette architecture crée trois couches:
Chaque couche est responsable d'un aspect de l'application. Modèle répond à la logique métier, Vue est l'interface utilisateur, et Manette médiateur Vue accès à Modèle.
Mais si nous analysons de près l'architecture de Android, en particulier la relation entre Vue (Activités, Fragments, etc.) et Model (structures de données), nous pouvons en conclure que cela ne peut pas être considéré comme MVC. Il est assez différent de MVC et suit ses propres règles. Cela peut certainement vous gêner lorsque votre objectif est de créer la meilleure application possible..
Pour être plus précis, si nous pensons à la connexion symbiotique entre les chargeurs et Activités ou Fragments, vous comprendrez pourquoi nous devrions prêter une attention particulière à l'architecture d'Android. Une activité ou un fragment est chargé d'appeler le chargeur, qui doit récupérer les données et les restituer à son parent. Son existence est complètement liée à son parent et il n'y a pas de séparation entre le rôle View (Activité / Fragment) et la logique métier effectuée par le chargeur..
Comment utiliser les tests unitaires dans une application dans laquelle les données (Loader) sont si étroitement associées à la vue (activité ou fragment) si l'essentiel du test unitaire consiste à tester le plus petit morceau de code possible? Si vous travaillez en équipe et que vous devez modifier quelque chose dans le code de quelqu'un d'autre, comment résoudre le problème si le projet ne respecte pas un modèle architectural connu et que tout peut être littéralement n'importe où?
Nous pouvons résoudre ce problème en mettant en œuvre un modèle architectural différent et, heureusement, le SDK Android nous permet de choisir entre plusieurs solutions. Nous pouvons limiter nos options aux solutions les mieux adaptées à Android. Le modèle MVC (Model View Controller) est un bon choix, mais un modèle encore meilleur est le modèle MVP (Model View Presenter) étroitement lié. MVP a été développé en utilisant les mêmes prémisses que MVC, mais avec un paradigme plus moderne qui crée une séparation encore meilleure des préoccupations et optimise la testabilité de l'application..
En pensant à l'architecture d'Android (ou à son absence), nous pouvons conclure que:
Comme je l'ai mentionné précédemment, la séparation des préoccupations n'est pas le point fort d'Android. Heureusement, le modèle Model View Presenter améliore cela de manière significative. MVP sépare l'application en trois couches:
Chacun a ses responsabilités et la communication entre ces couches est gérée par le présentateur. Le présentateur joue le rôle de médiateur entre les différentes parties.
Le modèle Présentateur de vue modèle est basé sur le modèle Contrôleur de vue Modèle. Puisqu'ils partagent plusieurs concepts, il peut être difficile de les différencier. Le présentateur et le contrôleur ont un rôle similaire. Ils sont responsables de la communication entre Model et View. Cela dit, le contrôleur ne gère pas les modèles et la vue aussi strictement que le présentateur..
Dans le modèle MVC, la couche View est quelque peu intelligente et peut extraire des données directement à partir du modèle. Dans le modèle MVP, la vue est complètement passive et les données sont toujours transmises à la vue par le présentateur. Les contrôleurs dans MVC peuvent également être partagés entre plusieurs vues. Dans MVP, la vue et le présentateur ont une relation un à un. Par conséquent, le présentateur est lié à une vue..
Ces différences conceptuelles font que le modèle MVP garantit une meilleure séparation des problèmes et augmente considérablement la testabilité de l'application en favorisant une plus grande séparation des trois couches centrales..
Il existe plusieurs interprétations de la manière dont MVP peut être implémenté sur Android. En général, cependant, les activités et les fragments se voient attribuer le rôle de View et sont responsables de la création du présentateur et du modèle. La vue est également responsable de la maintenance du modèle et du présentateur entre les modifications de configuration, les informant de la destruction éventuelle de la vue..
D'autres objets View, tels que RecyclerView, peuvent également être considérés comme faisant partie de la couche View dans MVP. Il existe une relation univoque entre la vue et le présentateur et des situations parfois complexes peuvent demander plusieurs présentateurs..
Dans le prochain tutoriel, nous implémentons le modèle Model View Presenter sur Android. Nous avons mis à l’essai les concepts que nous avons appris dans ce tutoriel et explorons plus avant les complexités du modèle et ce que cela signifie pour Android..
À la fin de cette série, vous pouvez implémenter MVP dans vos propres projets, créer votre propre framework ou adopter d'autres solutions connues. J'espère te voir dans le prochain tutoriel.
Accentsconagua