Modèle MVC sur Android

Dans Android, vous n’avez pas de MVC, mais vous avez les éléments suivants:

• Vous définissez votre interface utilisateur dans différents fichiers XML par résolution, matériel, etc.
• Vous définissez vos ressources dans différents fichiers XML par parameters régionaux, etc.
• Vous étendez des classes comme ListActivity , TabActivity et utilisez le fichier XML par des inflaters .
• Vous pouvez créer autant de classes que vous le souhaitez pour votre logique métier.
• De nombreux Utils ont déjà été écrits pour vous – DatabaseUtils, Html.

Il n’y a pas de modèle MVC unique. MVC est un concept plutôt qu’un cadre de programmation solide. Vous pouvez implémenter votre propre MVC sur n’importe quelle plate-forme. Tant que vous vous en tenez à l’idée de base suivante, vous implémentez MVC:

• Modèle: Que rendre
• Voir: Comment rendre
• Contrôleur: Événements, entrée utilisateur

Pensez aussi à ceci: lorsque vous programmez votre modèle, le modèle ne doit pas avoir à vous soucier du rendu (ou du code spécifique à la plate-forme). Le modèle dirait à la vue, peu m’importe si votre rendu est Android ou iOS ou Windows Phone, c’est ce que j’ai besoin de vous pour rendre. La vue ne traiterait que le code de rendu spécifique à la plate-forme.

Ceci est particulièrement utile lorsque vous utilisez Mono pour partager le modèle afin de développer des applications multiplates-formes.

Les actions, les vues et les activités sur Android sont la manière la plus efficace de travailler avec l’interface utilisateur Android et sont une implémentation du modèle MVVM (model – view – viewmodel) , structurellement similaire (dans la même famille que). -manette.

À ma connaissance, il n’y a aucun moyen de sortir de ce modèle. Cela peut probablement être fait, mais vous perdrez probablement tous les avantages du modèle existant et vous devrez réécrire votre propre couche d’interface utilisateur pour la faire fonctionner.

Après quelques recherches, la réponse la plus raisonnable est la suivante:

MVC est déjà implémenté sous Android comme:

1. View = layout, ressources et classes intégrées comme Button dérivé de android.view.View .
2. Contrôleur = activité
3. Model = les classes qui implémentent la logique d’application

(Cela n’implique d’ailleurs aucune logique de domaine d’application dans l’activité.)

La chose la plus raisonnable pour un petit développeur est de suivre ce modèle et de ne pas essayer de faire ce que Google a décidé de ne pas faire.

PS Notez que l’activité est parfois redémarrée, il n’y a donc pas de place pour les données de modèle (la manière la plus simple de redémarrer consiste à omettre android:configChanges="keyboardHidden|orientation" partir de XML et à allumer votre appareil).

MODIFIER

On peut parler de MVC , mais ce sera pour ainsi dire, FMVC , Framework – Model – View – Controller . Le Framework (le système d’exploitation Android) impose son idée du cycle de vie des composants et des événements associés. En pratique, le Controller ( Activity / Service / BroadcastReceiver ) est chargé de gérer ces événements (tels que onCreate () ). . L’entrée de l’utilisateur doit-elle être traitée séparément? Même si cela devait être le cas, vous ne pouvez pas le séparer, les événements d’entrée utilisateur proviennent également d’Android.

Quoi qu’il en soit, le moins de code qui n’est pas spécifique à Android que vous placez dans votre Activity / Service / BroadcastReceiver , le meilleur.

Il n’y a pas de modèle MVC unique auquel vous pouvez obéir. MVC indique plus ou moins que vous ne devez pas mélanger les données et les vues, de sorte que les vues sont par exemple responsables de la conservation des données ou que les classes qui traitent les données affectent directement la vue.

Mais néanmoins, la manière dont Android gère les classes et les ressources, vous êtes parfois même obligé de suivre le modèle MVC. Selon moi, les activités qui sont parfois responsables de la vue, mais qui agissent en même temps comme contrôleurs, sont plus complexes.

Si vous définissez vos vues et mises en page dans les fichiers XML, chargez vos ressources à partir du dossier res, et si vous évitez plus ou moins de mélanger ces éléments dans votre code, vous suivez de toute façon un modèle MVC.

La meilleure ressource que j’ai trouvée pour implémenter MVC sur Android est ce post :

J’ai suivi le même design pour un de mes projets et cela a très bien fonctionné. Je suis un débutant sur Android, alors je ne peux pas dire que c’est la meilleure solution.

J’ai apporté une modification: j’ai instancié le modèle et le contrôleur pour chaque activité de la classe d’applications afin que celles-ci ne soient pas recréées lorsque le mode paysage-portrait change.

Vous pouvez implémenter MVC sous Android, mais il n’est pas “nativement pris en charge” et demande un certain effort.

Cela dit, j’ai personnellement tendance à considérer MVP comme un modèle architectural beaucoup plus propre pour le développement Android. Et en disant MVP, je veux dire ceci:

J’ai également posté une réponse plus détaillée ici .

Après avoir joué avec les différentes approches de l’implémentation MVC / MVP dans Android, j’ai trouvé un modèle d’architecture raisonnable, que j’ai décrit dans cet article: MVP et MVC Architectural Patterns sous Android .

Je suis d’accord avec JDPeckham et je crois que XML seul n’est pas suffisant pour mettre en œuvre la partie interface utilisateur d’une application.

Cependant, si vous considérez l’activité comme faisant partie de la vue, l’implémentation de MVC est assez simple. Vous pouvez remplacer l’ application (telle que retournée par getApplication () dans Activity) et c’est ici que vous pouvez créer un contrôleur qui survit pendant la durée de vie de votre application.

(Sinon, vous pouvez utiliser le modèle singleton comme suggéré par la documentation de l’application)

La création de l’interface utilisateur Android à l’aide de dispositions, de ressources, d’activités et d’intentions est une implémentation du modèle MVC. S’il vous plaît voir le lien suivant pour plus d’informations à ce sujet – http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

miroir pour le pdf

MVC-Architecture sur Android Il est préférable de suivre tout MVP à la place de MVC dans Android. Mais toujours selon la réponse à la question, cela peut être une solution

Description et directives

  Controller - Activity can play the role. Use an application class to write the global methods and define, and avoid static variables in the controller label Model - Entity like - user, Product, and Customer class. View - XML layout files. ViewModel - Class with like CartItem and owner models with multiple class properties Service - DataService- All the tables which have logic to get the data to bind the models - UserTable, CustomerTable NetworkService - Service logic binds the logic with network call - Login Service Helpers - SsortingngHelper, ValidationHelper static methods for helping format and validation code. SharedView - fragmets or shared views from the code can be separated here AppConstant - Use the Values folder XML files for constant app level 

NOTE 1:

Maintenant, voici le morceau de magie que vous pouvez faire. Une fois que vous avez classé le code, écrivez une classe d’interface de base comme IEntity et IService. Déclarez les méthodes courantes. Créez maintenant la classe abstraite BaseService et déclarez votre propre ensemble de méthodes et séparez le code.

NOTE 2: Si votre activité présente plusieurs modèles, plutôt que d’écrire le code / la logique en activité, il est préférable de diviser les vues en fragments. Alors c’est mieux. Donc, dans le futur, si un autre modèle est nécessaire pour apparaître dans la vue, ajoutez un fragment supplémentaire.

NOTE 3: La séparation du code est très importante. Chaque composant de l’architecture doit être indépendant et ne pas avoir de logique dépendante. Si par hasard, si vous avez une logique dépendant de quelque chose, écrivez une classe logique de mappage entre les deux. Cela vous aidera à l’avenir.

Bien que ce post semble être vieux, je voudrais append les deux suivants pour informer sur le développement récent dans ce domaine pour Android:

android-binding – Fournit un framework qui atsortingbue la liaison des widgets d’affichage Android au modèle de données. Il aide à implémenter les patterns MVC ou MVVM dans les applications Android.

Roboguice – RoboGuice élimine les conjectures du développement. Injectez votre View, Resource, System Service ou tout autre object et laissez RoboGuice s’occuper des détails.

Le modèle MVC d’Android est (en quelque sorte) implémenté avec leurs classes Adapter . Ils remplacent un contrôleur par un “adaptateur”. La description de l’adaptateur indique:

Un object Adapter agit comme un pont entre un AdapterView et les données sous-jacentes pour cette vue.

Je suis en train de regarder cela pour une application Android qui lit à partir d’une firebase database, donc je ne sais pas comment cela fonctionne encore. Cependant, cela ressemble un peu à l’architecture Model-View-Delegate de Qt, qui, selon eux, constitue une avancée par rapport à un modèle MVC traditionnel. Au moins sur le PC, le modèle de Qt fonctionne assez bien.

Model View Controller (MVC)

La description:

• Lorsque nous devons mener de grands projets dans le développement de logiciels, MVC est généralement utilisé car il s’agit d’une manière universelle d’organiser les projets.
• Les nouveaux développeurs peuvent rapidement s’adapter au projet
• Aide au développement de grands projets et à la plate-forme croisée.

Le modèle MVC est essentiellement celui-ci:

• Modèle: quoi afficher Cela peut être la source de données (Ex: serveur, données brutes dans l’application)
• Voir: comment il est affiché. Cela peut être le xml. Il agit donc comme un filtre de présentation. Une vue est attachée à son modèle (ou à sa pièce modèle) et obtient les données nécessaires à la présentation.
• Contrôleur: gestion des événements comme la saisie utilisateur. Ce soit l’activité

Fonctionnalité importante de MVC: Nous pouvons modifier le modèle ou la vue ou le contrôleur n’affectant toujours pas les autres

• Disons que nous changeons la couleur dans la vue, la taille de la vue ou la position de la vue. Ce faisant, cela n’affectera pas le modèle ou le contrôleur
• Supposons que nous modifions le modèle (au lieu de récupérer les données extraites du serveur pour récupérer les données des actifs), cela n’affectera pas la vue et le contrôleur
• Disons que nous changeons de contrôleur (logique dans l’activité) cela n’affectera pas le modèle et la vue

Je pense que l’explication simplifiée la plus utile est la suivante: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

De tout ce que j’ai vu et lu ici, la mise en œuvre de toutes ces choses le rend plus difficile et ne correspond pas bien aux autres parties d’androïde.

Avoir une activité implémenter d’autres auditeurs est déjà la manière standard d’Android. La manière la plus inoffensive serait d’append Java Observer comme les diapositives décrivent et regroupent onClick et d’autres types d’actions dans des fonctions encore présentes dans l’activité.

La manière Android est que l’activité fait les deux. Le combat ne facilite pas vraiment l’extension ou le codage futur.

Je suis d’accord avec le 2ème post . C’est en quelque sorte déjà implémenté, mais pas comme les gens sont habitués. Que ce soit ou non dans le même fichier ou non, il y a déjà une séparation. Il n’est pas nécessaire de créer une séparation supplémentaire pour l’adapter à d’autres langages et systèmes d’exploitation.

Étant fatigué de la catastrophe de MVx sur Android, j’ai récemment créé une petite bibliothèque qui fournit un stream de données unidirectionnel et est similaire au concept de MVC: https://github.com/zserge/anvil

Fondamentalement, vous avez un composant (activité, fragment et groupe de vues). A l’intérieur, vous définissez la structure et le style de la couche de vue. Vous définissez également comment les données doivent être liées aux vues. Enfin, vous pouvez lier les auditeurs au même endroit.

Ensuite, une fois vos données modifiées, la méthode globale “render ()” sera appelée et vos vues seront intelligemment mises à jour avec les données les plus récentes.

Voici un exemple du composant ayant tout à l’intérieur pour la compacité du code (bien sûr, Model et Controller peuvent être facilement séparés). Ici, “count” est un modèle, la méthode view () est une vue et “v -> count ++” est un contrôleur qui écoute le clic et met à jour le modèle.

 public MyView extends RenderableView { public MyView(Context c) { super(c); } private int count = 0; public void view() { frameLayout(() -> { // Define your view hierarchy size(FILL, WRAP); button(() -> { textColor(Color.RED); // Define view style text("Clicked " + count); // Bind data onClick(v -> count++); // Bind listeners }); }); } 

Avec le modèle et le contrôleur séparés, cela ressemblerait à ceci:

 button(() -> { textColor(Color.RED); text("Clicked " + mModel.getClickCount()); onClick(mController::onButtonClicked); }); 

Ici, sur chaque clic de bouton, le nombre sera augmenté, puis “render ()” sera appelé et le texte du bouton sera mis à jour.

La syntaxe devient plus agréable si vous utilisez Kotlin: http://zserge.com/blog/anvil-kotlin.html . De plus, il existe une syntaxe alternative pour Java sans lambdas.

La bibliothèque elle-même est très légère, n’a pas de dépendances, n’utilise pas de reflection, etc.

(Disclaimer: je suis l’auteur de cette bibliothèque)

Il n’y a pas d’architecture MVC implémentée, mais un ensemble de bibliothèques / exemples existe pour implémenter une architecture MVP (modèle-vue-présentateur).

Merci de vérifier ces liens:

• https://github.com/sockeqwe/mosby

• https://github.com/android10/Android-CleanArchitecture

• https://github.com/antoniolg/androidmvp

Google a ajouté un exemple de MVP d’architecture Android:

• https://github.com/googlesamples/android-architecture

J’ai vu que beaucoup de gens disent que MVC est déjà implémenté dans Android, mais ce n’est pas vrai. Android ne suit aucun MVC par défaut.

Parce que Google n’aime pas imposer avec force les ressortingctions d’une implémentation MVC comme l’iPhone, mais a laissé cette décision à l’utilisateur d’utiliser la technique MVC, car dans les applications petites ou simples, nous n’avons pas besoin d’utiliser MVC, mais l’application se complique et aura besoin de modifier son code une fois le développement terminé, alors il y a un besoin du modèle MVC dans Android.

Il fournit un moyen facile de modifier le code et aide également dans les problèmes indésirables. Ceux-ci viennent dans des modèles de conception Android simples. Si vous souhaitez implémenter MVC sur Android, suivez ce lien ci-dessous et profitez des techniques d’implémentation de MVC dans votre projet.

http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/

Selon l’explication que l’équipe de Xamarin a expliquée (sur iOS MVC “je sais que cela semble étrange, mais attendez une seconde”):

• Le modèle (logique de données ou d’application),
• La vue (interface utilisateur) et
• Le contrôleur (code derrière).

Je peux dire ceci:

Le modèle sur Android est simplement l’object parcelable. La vue est la mise en page XML et le contrôleur est la (activité + son fragment).

* Ceci est juste mon opinion, pas de toute ressource ou un livre.

Lorsque nous appliquons MVC, MVVM ou Presentation Model à une application Android, ce que nous voulons vraiment, c’est un projet clairement structuré et, plus important encore, plus facile pour les tests unitaires.

Pour le moment, sans structure tierce, vous avez généralement beaucoup de code (comme addXXListener (), findViewById (), etc.), qui n’ajoute aucune valeur métier.

De plus, vous devez exécuter des tests unitaires Android au lieu des tests JUnit normaux, qui prennent des années à s’exécuter et rendent les tests unitaires peu pratiques. Pour ces raisons, il y a quelques années, nous avons lancé un projet open source, RoboBinding – un modèle de modèle de présentation de liaison de données pour la plate-forme Android.

RoboBinding vous aide à écrire du code d’interface utilisateur plus facile à lire, à tester et à gérer. RoboBinding supprime le besoin de code inutile, par exemple addXXListener , et déplace la logique de l’interface utilisateur vers Presentation Model, qui est un POJO et peut être testé via des tests JUnit normaux . RoboBinding lui-même est livré avec plus de 300 tests JUnit pour assurer sa qualité.

C’était étonnant de voir qu’aucun des messages ici ne répondait à la question. Ils sont soit trop généraux, vagues, incorrects ou ne concernent pas l’implémentation dans Android.

Dans MVC, la couche Afficher ne sait que montrer l’interface utilisateur. Si des données sont nécessaires pour cela, elles proviennent de la couche Modèle . Mais la vue ne demande PAS directement au modèle de trouver les données, il le fait via le contrôleur . Le contrôleur appelle donc le modèle pour fournir les données requirejses pour la vue . Une fois que les données sont prêtes, le contrôleur informe la vue que les données sont prêtes à être acquises à partir du modèle . La vue peut maintenant obtenir les données du modèle .

Ce stream peut être résumé comme suit:

Il est important de noter que View peut connaître la disponibilité des données dans le modèle via Controller – également appelé MVC passif – ou en observant les données du modèle en y enregistrant des observables, à savoir Active MVC .

En ce qui concerne l’implémentation, une des premières choses qui vient à l’esprit est que quel composant Android doit être utilisé pour la vue ? Activity ou Fragment ?

La réponse est que cela n’a pas d’importance et que les deux peuvent être utilisés. La vue doit pouvoir présenter l’interface utilisateur sur le périphérique et répondre à l’interaction de l’utilisateur avec l’interface utilisateur. Activity et Fragment fournissent les méthodes requirejses pour cela.

Dans l’exemple d’application utilisé dans cet article, j’ai utilisé Activity pour la couche View , mais Fragment peut également être utilisé.

L’exemple complet d’application peut être trouvé dans la twig “mvc” de mon repo GitHub ici .

J’ai aussi traité les avantages et les inconvénients de l’architecture MVC dans Android grâce à un exemple ici .

Pour les intéressés, j’ai commencé une série d’articles sur l’architecture des applications Android dans laquelle je compare les différentes architectures, à savoir MVC, MVP, MVVM, pour le développement d’applications Android via une application complète.

Model-View-Controller in Android Vers 2011, lorsque Android commença à devenir de plus en plus populaire, les questions d’architecture apparurent naturellement. MVC étant l’un des modèles d’interface utilisateur les plus populaires à cette époque, les développeurs ont également essayé de l’appliquer à Android.

Modèle Le modèle représente un ensemble de classes décrivant la logique métier, à savoir le modèle métier ainsi que les opérations d’access aux données, à savoir le modèle de données. Il définit également les règles métier pour les données, ce qui signifie que les données peuvent être modifiées et manipulées.

Afficher La vue représente les composants de l’interface utilisateur. Il est uniquement responsable de l’affichage des données reçues du contrôleur en conséquence. Cela transforme également le (s) modèle (s) en interface utilisateur.

Contrôleur Le contrôleur est responsable du traitement des demandes entrantes. Il reçoit les entrées des utilisateurs via la vue, puis traite les données de l’utilisateur à l’aide du modèle et transmet les résultats à la vue. En général, il agit comme coordinateur entre la vue et le modèle.

En d’autres termes

Modèles: fournisseurs de contenu. Les gestionnaires de données sont la forme recommandée de partage de données inter-applications.

Vues: Activités. C’est le composant d’interface utilisateur principal de l’application. Chaque écran individuel d’une application Android est dérivé de la classe Java Activity (android.app.Activity). Ce sont des conteneurs pour les vues (android.view.View).

Contrôleurs: Services. Ce sont des composants d’arrière-plan qui se comportent comme des démons UNIX et des services Windows. Ils s’exécutent de manière invisible et effectuent un traitement continu sans surveillance.