Motif MVC sur Android
Est-il possible d'implémenter le modèle modèle – vue – contrôleur dans Java pour Android?
Ou est-ce déjà mis en œuvre par le biais d'activités? Ou existe-t-il un meilleur moyen d'implémenter le modèle MVC pour Android?
Dans Android vous n'avez pas MVC, mais vous avez les éléments suivants:
- Vous définissez votre interface utilisateur dans divers fichiers XML par résolution, matériel, etc.
- Vous définissez votre ressources dans divers fichiers XML par paramètres régionaux, etc.
- Vous étendez des classes telles que ListActivity , TabActivity et utilisez le fichier XML par inflaters .
- Vous pouvez créer autant de classes que vous le souhaitez pour votre logique métier.
- Beaucoup de tils ont déjà été écrits pour vous - DatabaseUtils, Html.
Il n'y a pas de modèle MVC universellement 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
- Vue: Comment rendre
- Contrôleur: Événements, entrées utilisateur
Réfléchissez également à cela: lorsque vous programmez votre modèle, celui-ci ne doit pas avoir à se soucier du rendu (ou du code spécifique à la plate-forme). Le modèle dirait à la vue, peu importe si votre rendu est Android ou iOS ou Windows Phone, voici ce dont j'ai besoin pour vous. 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, vues et activités sur Android constituent la manière la plus simple de travailler avec l'interface utilisateur Android et constituent une implémentation de l'interface modèle – view – viewmodel (MVVM)). pattern, qui est structurellement similaire (dans la même famille que) model – view – controller.
À ma connaissance, il n’existe aucun moyen de sortir de ce modèle. Cela peut probablement être fait, mais vous perdriez probablement tous les avantages du modèle existant et devez réécrire votre propre couche d'interface utilisateur pour que cela fonctionne.
Après quelques recherches, la réponse la plus raisonnable est la suivante:
MVC est déjà implémenté dans Android en tant que:
- View = mise en page, ressources et classes intégrées telles que
Buttondérivée deAndroid.view.View. - Contrôleur = Activité
- 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 Activity est parfois redémarré, il n’ya donc pas de place pour les données de modèle (le moyen le plus simple de provoquer un redémarrage est d’omettre Android:configChanges="keyboardHidden|orientation" du fichier XML et de transformer votre périphérique).
MODIFIER
Nous pouvons parler de MVC, mais ce sera pour ainsi dire FMVC, Framework - Model - View - Controller =. Le Framework (le Android OS) impose sa conception du cycle de vie des composants et des événements connexes. En pratique, le Controller (Activity/Service/BroadcastReceiver) est d'abord responsable de la gestion de ces événements Framework - imposés (tels que onCreate ()). Les entrées de l'utilisateur doivent-elles être traitées séparément? Même s'il le devrait, vous ne pouvez pas le séparer, les événements d'entrée d'utilisateur proviennent également d'Android.
Quoi qu'il en soit, moins vous insérerez dans votre code Activity/Service/BroadcastReceiver, mieux ce sera.
Vous ne pouvez obéir à aucun modèle MVC. MVC indique simplement plus ou moins qu'il ne faut pas mélanger les données et les vues, de sorte que, par exemple, les vues sont responsables de la conservation des données ou des classes qui traitent des données affectent directement la vue.
Néanmoins, malgré la façon dont Android traite les classes et les ressources, vous êtes parfois même obligé de suivre le modèle MVC. À mon avis, les activités qui sont parfois responsables de la vue mais qui agissent néanmoins comme un contrôleur dans le même temps sont plus compliquées.
Si vous définissez vos vues et vos dispositions 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 quand même un modèle MVC.
Vous pouvez implémenter MVC dans Android, mais cela n’est pas "pris en charge de manière native" et demande quelques efforts.
Cela dit, j’ai tendance personnellement à utiliser MVP comme modèle architectural beaucoup plus net pour le développement de 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 la mise en œuvre de MVC/MVP dans Android, je suis arrivé à un modèle architectural raisonnable, que j'ai décrit dans cet article: MVP et MVC Architectural Patterns dans Android .
La meilleure ressource que j'ai trouvée pour implémenter MVC sur Android est cet article :
J'ai suivi la même conception pour l'un de mes projets et cela a très bien fonctionné. Je suis un débutant sur Android, donc 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'application afin que celles-ci ne soient pas recréées lorsque le mode portrait en paysage change.
Je suis d'accord avec JDPeckham et je pense que XML seul n'est pas suffisant pour implémenter la partie interface utilisateur d'une application.
Toutefois, si vous considérez l'activité comme faisant partie de la vue, l'implémentation de MVC est relativement simple. Vous pouvez remplacer Application (comme renvoyé par getApplication () dans Activity) et c’est ici que vous pouvez créer un contrôleur qui survit pendant toute la durée de vie de votre application.
(Vous pouvez également utiliser le modèle singleton suggéré par la documentation de l'application.)
La création d'interface utilisateur Android à l'aide de dispositions, de ressources, d'activités et d'intentions est une implémentation du modèle MVC. Veuillez consulter le lien suivant pour plus d'informations à ce sujet - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf
Architecture MVC sur Android Il est préférable de suivre n'importe quel MVP à la place de MVC sous 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 -
StringHelper, 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é l'élément de code, écrivez une classe d'interface de base telle que IEntity et IService. Déclarez des méthodes communes. Créez maintenant la classe abstraite BaseService, déclarez votre propre ensemble de méthodes et séparez le code.
NOTE 2: Si votre activité présente plusieurs modèles, alors, plutôt que d'écrire le code/la logique dans l'activité, il est préférable de diviser les vues en fragments. Alors c'est mieux. Ainsi, à l'avenir, si un modèle supplémentaire est nécessaire pour s'afficher 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épendante, écrivez une classe de logique de mappage entre les deux. Cela vous aidera dans le futur.
Bien que ce message semble être vieux, j'aimerais ajouter les deux suivants pour informer sur le développement récent dans ce domaine pour Android:
Android-binding - Fournit un cadre qui facilite la liaison de Android widgets de vue au modèle de données. Il est utile d’implémenter des modèles MVC ou MVVM dans les applications Android.
roboguice - RoboGuice élimine les devinettes dans le développement. Injectez votre vue, votre ressource, votre service système ou tout autre objet, 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 objet Adapter sert de pont entre un AdapterView et les données sous-jacentes de cette vue.
Je cherche simplement une application Android qui lit une base de données, donc je ne sais pas encore si cela fonctionne bien. Cependant, cela ressemble un peu à l'architecture Model-View-Delegate de Qt, qui, selon eux, est une avancée par rapport à un modèle MVC traditionnel. Au moins sur le PC, le motif de Qt fonctionne assez bien.
Contrôleur de vue modèle (MVC)
Description:
- MVC est généralement utilisé pour organiser des projets de grande envergure dans le développement de logiciels.
- Les nouveaux développeurs peuvent rapidement s'adapter au projet
- Aide au développement de grands projets et de la multiplateforme.
Le modèle MVC est essentiellement le suivant:
- Modèle: Quoi afficher. Cela peut être la source de données (Ex: Serveur, données brutes dans l'application)
- Voir: Comment cela s’affiche. Cela peut être le XML. Il agit donc comme un filtre de présentation. Une vue est attachée à son modèle (ou à une partie de modèle) et obtient les données nécessaires à la présentation.
- Contrôleur: Gestion des événements tels que la saisie utilisateur. Ce soit l'activité
Caractéristique importante de MVC: Nous pouvons modifier le modèle, la vue ou le contrôleur, sans affecter les autres
- Supposons que nous changions la couleur de la vue, la taille de la vue ou la position de la vue. Cela n'affectera ni le modèle ni le contrôleur
- Supposons que nous modifions le modèle (au lieu des données extraites du serveur, extraites des ressources), sans que cela affecte la vue et le contrôleur.
- Disons que nous changeons le 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 rend la tâche plus difficile et ne cadre pas bien avec d'autres parties d'Android.
Avoir une activité implémenter d'autres écouteurs est déjà la méthode standard Android. Le moyen le plus inoffensif serait d’ajouter Java Observer comme le décrivent les diapositives et de regrouper onClick et d’autres types d’actions dans des fonctions toujours présentes dans l’Activité.
La méthode Android consiste à utiliser l’Activité pour les deux. Le combattre ne facilite pas vraiment l'extension ou la programmation future.
Je suis d'accord avec le 2e post . C'est en quelque sorte déjà mis en œuvre, mais ce n'est pas la façon dont les gens sont habitués. Que ce soit ou non dans le même fichier, il y a déjà séparation. Il n'est pas nécessaire de créer une séparation supplémentaire pour l'adapter à d'autres langues et systèmes d'exploitation.
Fatigué du désastre MVx sur Android, j’ai récemment créé une petite bibliothèque fournissant un flux de données unidirectionnel, similaire au concept de MVC: https://github.com/zserge/ enclume
En gros, vous avez un composant (activité, fragment et groupe de vues). À l'intérieur, vous définissez la structure et le style du calque de vue. Vous définissez également comment les données doivent être liées aux vues. Enfin, vous pouvez lier des 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 de composant contenant tout pour la compacité du code (bien sûr, Modèle et Contrôleur 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 les clics de bouton 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 à:
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 autre syntaxe 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 réflexion, etc.
(Avertissement: je suis l'auteur de cette bibliothèque)
C'était surprenant de voir qu'aucun des messages ici n'a répondu à la question. Ils sont soit trop généraux, vagues, incorrects ou ne traitent pas de la mise en œuvre dans Android.
Dans MVC, la couche View ne sait montrer que l'interface utilisateur. Si des données sont nécessaires pour cela, il les obtient à partir de la couche Model. Mais la vue NE demande PAS directement au modèle de trouver les données, elle le fait par le biais du Controller. Ainsi, le Controller appelle le Modèle pour fournir les données requises pour le View. Une fois que les données sont prêtes, le Controller informe le View que les données sont prêtes à être acquises à partir du Model. Maintenant, le View peut obtenir les données du Model.
Ce flux peut être résumé comme suit:
Il est à noter que le View peut connaître la disponibilité des données dans le Modèle soit via Controller - également appelé MVC passif - ou en observant les données du Modèle en y enregistrant des éléments observables, ce qui est MVC actif .
En ce qui concerne l’implémentation, l’une des premières choses qui me viennent à l’esprit est que le composant Android devrait être utilisé pour le View? Activity ou Fragment?
La réponse est que cela n’a aucune importance et que les deux peuvent être utilisés. Le View doit pouvoir présenter l'interface utilisateur du périphérique et répondre à l'interaction de l'utilisateur avec l'interface utilisateur. Activity et Fragment fournissent les méthodes nécessaires à cet effet.
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 branche 'mvc' de mon dépôt GitHub ici .
J'ai également traité des avantages et des inconvénients de l'architecture MVC dans Android au moyen d'un exemple ici .
Pour ceux que cela intéresse, j'ai commencé une série d'articles sur Android architecture d'application ici dans laquelle je compare les différentes architectures, à savoir MVC, MVP, MVVM, pour Android développement d'applications via une application de travail complète.
Il n'y a pas d'architecture MVC implémentée, mais un ensemble de bibliothèques/exemples existent pour implémenter une architecture MVP (modèle – vue – présentateur).
S'il vous plaît, vérifiez ces liens:
Google a ajouté un exemple de MVP Android d'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 pas MVC par défaut.
Parce que je n'imposerai jamais de force à Google les restrictions d'une implémentation MVC telle que l'iPhone, mais également aux développeurs quelle technique ou technique ils souhaitent utiliser dans leur projet. Dans les applications petites ou simples, l'utilisation de MVC n'est pas obligatoire, mais comme application se développe et se complique et nécessite des modifications de son code dans les années à venir, puis vient le besoin du modèle MVC dans Android.
Il fournit un moyen facile de modifier le code et aide également à réduire les problèmes. Si vous souhaitez implémenter MVC sur Android, suivez le lien ci-dessous et appréciez l'implémentation de MVC dans votre projet.
http://www.therealjoshua.com/2011/11/Android-architecture-part-1-intro/
Mais de nos jours, je pense que MVP avec Android Architectural Pattern est l’une des meilleures options que les développeurs doivent utiliser pour des applications Androidpropres et robustes.
Selon l'explication , a expliqué l'équipe de Xamarin (sur iOS MVC, "Je sais que cela semble bizarre, mais attendez une seconde"):
- Le modèle (données ou logique applicative),
- La vue (interface utilisateur), et
- Le contrôleur (code derrière).
Je peux dire ceci:
Le modèle sur Android est simplement l'objet pouvant être parcellisé. La vue est la disposition XML et le contrôleur est le (activité + son fragment).
* Ceci est juste mon avis, pas de toute ressource ou un livre.
Lorsque nous appliquons MVC MVVM , ou Modèle de présentation à une application Android, nous souhaitons réellement avoir un projet structuré clair, etc. surtout plus facile pour les tests unitaires.
À l'heure actuelle, sans framework tiers, vous avez généralement beaucoup de code (comme addXXListener (), findViewById (), etc.), qui n'ajoute aucune valeur commerciale.
De plus, vous devez exécuter Android tests unitaires au lieu des tests JUnit normaux, qui prennent un certain temps à s'exécuter et rendent les tests unitaires quelque peu impraticables. Pour ces raisons, nous avons lancé il y a quelques années un projet open source, RoboBinding - Un cadre de modèle de présentation de liaison de données pour la plate-forme Android.
RoboBinding vous aide à rédiger un code d'interface utilisateur plus facile à lire, à tester et à gérer. RoboBinding supprime le besoin de code inutile tel que addXXListener ou plus , et décale la logique de l'interface utilisateur vers le modèle de présentation, qui est un POJO et peut être testé via test normal de JUnit . RoboBinding est livré avec plus de 300 tests JUnit pour assurer sa qualité.
D'après ma compréhension, la manière dont Android traite le motif MVC est la suivante:
Vous avez une activité qui sert de contrôleur. Vous avez une classe dont la responsabilité est d'obtenir les données - le modèle, puis vous avez la classe View qui est la vue.
Lorsqu'on parle de la vue, la plupart des gens ne pensent qu'à sa partie visuelle définie dans le xml. N'oublions pas que la vue comporte également une partie de programme avec ses constructeurs, méthodes, etc., définie dans la classe Java.