Le schéma MVP (Model-View-Presenter) est-il utile pour Android?

Comment séparer View et Presenter dans Android, tandis que les réactions sur les actions de l'utilisateur (partie Presenter de MVP) sont définies dans les mêmes activités que celles qui montrent les éléments d'interface graphique (partie View de MVP).

"Dans le présentateur de vue modèle, comme le disent Martin Fowler ou Michael Feathers [2], la logique de l'interface utilisateur est divisée en une classe appelée présentateur, qui gère toutes les entrées de l'utilisateur et qui indique à la vue" muette "quoi et quand display "(cité d' ici ).

Jusqu'à présent, je pensais que l'une des principales caractéristiques d'Android est l' activité intelligente qui prend des mesures, y réagit et affiche les résultats. Le schéma MVP est-il en contradiction avec la philosophie Android? At-il le sens d'essayer de le réaliser sur Android? Si oui, comment cela pourrait-il être fait?

Les applications Android reposent fondamentalement sur le modèle-vue-contrôleur (MVC) - MVP ressemble à la même chose, bien que je n’aie jamais entendu le terme auparavant. Les activités remplissent le rôle de contrôleur, les vues XML ne sont que cela (bien que vous puissiez les construire par programme dans l'activité - il est simplement plus facile de le faire en XML) et le modèle que vous écrivez vous-même. Alors oui, ce modèle est assez pratique.

Une raison possible pour laquelle vous n’avez peut-être pas beaucoup entendu parler de ce modèle de conception est que la structure Android vous oblige à séparer la vue. Étant donné que les applications sur les appareils mobiles ont tendance à être petites, les utilisateurs n'utilisent généralement pas la technologie MVC complète. ils tendent vers les calques de vue et d'action où le calque d'action effectue l'essentiel du travail (petit) du modèle.

Si vous écrivez une application multiplate-forme, vous pouvez envisager une approche à quatre couches: Affichage, Action, Logique métier et Modèle. Les couches Vue et Action seraient spécifiques à la plate-forme, tandis que la logique et le modèle métier ne seraient pas modifiés. Fondamentalement, vous répartissez les interactions entre le présentateur et l'utilisateur en couche Action, qui appelle la couche Business Logic pour exécuter l'action souhaitée par l'utilisateur.

Je n'ai aucune expérience de la programmation Android, mais après un bref aperçu de quelques tutoriels d'introduction à la programmation pour Android, je ne vois pas pourquoi MVP serait moins utile que dans tout autre cadre basé sur des événements. La Activityclasse n'est pas très différente de la Dialogou Formde celles d'autres frameworks, il devrait donc être facile de créer une classe "Activitity Presenter" pour toute sous-classe d'activité de votre application et d'y insérer la logique principale.

Les événements envoyés à votre "Activité" doivent être délégués à votre présentateur. Si votre présentateur va envoyer des événements par lui-même ou appeler d'autres fonctions dépendant du système, votre Activité doit fournir des fonctions connexes via l'interface qu'il partage avec le présentateur. Mais c’est fondamentalement le même que dans tout autre framework d’interface graphique que je connaisse.

MVP est certainement utile pour Android. Cela aide à organiser et à tester votre code. Et la meilleure partie est que les nouvelles personnes qui liront votre code seront en mesure de comprendre le code et commenceront à contribuer dès qu'elles sauront ce qui devrait aller où. Voici un lien très utile pour comprendre MVP avec des exemples .

Voici une brève explication des trois composants de MVP.

Vue

Dans Android MVP, une vue contient deux éléments Activité - ressource Android Vue - interface java Activité Implémente la vue et s’injecte (interface de visualisation) dans le présentateur afin que celui-ci puisse parler de l’activité à l’aide de l’interface de visualisation. Les trois premiers blocs du diagramme montrent la communication entre View et The Presenter.

Présentateur

Presenter agit en tant que couche intermédiaire entre View et Data / Model. View (Activité) commande au présentateur de présenter quelque chose. Le présentateur prend ensuite les données de la base de données / Modèle et redonne la forme présentable des données à la vue. View se charge ensuite d’afficher ces données à l’écran. Et rappelez-vous que Presenter est une classe Java simple, il ne devrait inclure aucun des composants Android, sinon les tests unitaires du présentateur seront compliqués.

Si vous souhaitez utiliser la base de données dans le présentateur, assurez-vous que activité crée une instance de base de données et l'injectez dans le présentateur. Cela vous aidera à simuler la base de données lors des tests unitaires et à tester la logique métier.

Modèle

Le modèle dans MVP n'est rien d'autre que votre source de données. View ne communique pas directement avec les données. Il demande à Presenter de gérer ces données et de restituer les informations qui peuvent être affichées sans aucune modification supplémentaire.