Modèle MVC sur Android

Est-il possible d'implémenter le modèle de modèle-vue-contrôleur dans Java pour Android?

Ou est-il déjà mis en œuvre par le biais des activités? Ou existe-t-il une meilleure façon de mettre en œuvre le modèle MVC pour Android?

Dans Android, vous n'avez pas MVC, mais vous disposez des é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 divers fichiers XML par paramètres 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.
• Beaucoup d' Utils ont déjà été écrits pour vous - DatabaseUtils, Html.

Il n'y a pas de modèle MVC universel 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: quoi rendre
• Vue: comment rendre
• Contrôleur: événements, entrée utilisateur

Pensez-y également de cette façon: lorsque vous programmez votre modèle, le modèle ne devrait pas avoir à se soucier du rendu (ou du code spécifique à la plate-forme). Le modèle dirait à la vue, je me fiche que votre rendu soit Android ou iOS ou Windows Phone, c'est ce que j'ai besoin que vous rendiez. La vue ne gérerait que le code de rendu spécifique à la plate-forme.

Cela 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 sont la manière intégrée de travailler avec l'interface utilisateur Android et sont une implémentation du modèle modèle-vue-vue-modèle (MVVM) , qui est structurellement similaire (dans la même famille que) modèle-vue -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 devrez réécrire votre propre couche d'interface utilisateur pour le faire fonctionner.

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

MVC est déjà implémenté dans Android en tant que:

1. View = disposition, ressources et classes intégrées comme Buttondérivées de android.view.View.
2. Contrôleur = Activité
3. Modèle = 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 du modèle (le moyen le plus simple de provoquer un redémarrage est d'omettre android:configChanges="keyboardHidden|orientation"du XML et de tourner votre appareil).

ÉDITER

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, et dans la pratique, le Controller ( Activity/ Service/ BroadcastReceiver) est tout d'abord responsable de faire face à ces événements imposés par le Framework (comme onCreate () ). L'entrée utilisateur doit-elle être traitée séparément? Même si c'est 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, moins vous mettez de code non spécifique à Android dans votre Activity/ Service/ BroadcastReceiver, mieux c'est.

Il n'y a aucun modèle MVC auquel vous pourriez obéir. MVC indique simplement plus ou moins que vous ne devez 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 les données affectent directement la vue.

Mais néanmoins, la façon dont Android gère les classes et les ressources, vous êtes même parfois obligé de suivre le modèle MVC. Plus compliquées à mon avis sont les activités qui sont parfois responsables de la vue, mais qui agissent néanmoins en même temps comme contrôleur.

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 choses dans votre code, vous suivez de toute façon un modèle MVC.

Vous pouvez implémenter MVC dans Android, mais il n'est pas "pris en charge nativement" et demande un certain effort.

Cela dit, je tends personnellement vers 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 la mise en œuvre MVC / MVP dans Android, j'ai trouvé un modèle architectural raisonnable, que j'ai décrit dans un article: MVP et MVC Architectural Patterns dans Android .

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

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 fait une modification: j'ai instancié le modèle et le contrôleur pour chaque activité de la classe d'application afin qu'ils ne soient pas recréés lorsque le mode paysage-portrait change.

Je suis d'accord avec JDPeckham et je pense que XML seul n'est pas suffisant pour implémenter la partie UI 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 Application (comme retourné 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.

(Vous pouvez également utiliser le modèle singleton comme suggéré par la documentation de l'application)

MVC-Architecture sur Android Il vaut mieux suivre n'importe quel 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 -
        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é le morceau de 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.

REMARQUE 2: Si votre activité présente plusieurs modèles, 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. Donc, à l'avenir, si plus de modèle est nécessaire pour apparaître dans la vue, ajoutez un autre fragment.

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 quelque chose de logique dépendante, écrivez une classe logique de mappage entre les deux. Cela vous aidera à l'avenir.

La création d'interface utilisateur Android à l'aide de mises en page, 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

miroir pour le pdf

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

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

Je cherche juste une application Android qui lit à partir d'une base de données, donc je ne sais pas encore comment cela fonctionne. 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 modèle de Qt fonctionne assez bien.

Bien que cet article semble être ancien, 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 permet la liaison des widgets de vue android au modèle de données. Il aide à implémenter des modèles MVC ou MVVM dans les applications Android.

roboguice - RoboGuice élimine les conjectures du développement. Injectez votre vue, ressource, service système ou tout autre objet et laissez RoboGuice s'occuper des détails.

Contrôleur de vue du modèle (MVC)

La description:

• Lorsque nous devons gérer de grands projets dans le développement de logiciels, MVC est généralement utilisé parce que c'est une façon universelle d'organiser les projets.
• Les nouveaux développeurs peuvent s'adapter rapidement au projet
• Aide au développement de grands projets et multi-plateformes.

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 il est affiché. Cela peut être le xml. Il agit ainsi comme un filtre de présentation. Une vue est attachée à son modèle (ou pièce de modèle) et obtient les données nécessaires à la présentation.
• Contrôleur: gestion des événements tels que l'entrée utilisateur. Ce sera l'activité

Fonctionnalité importante de MVC: nous pouvons modifier soit le modèle, soit la vue, soit le contrôleur sans affecter les autres

• Disons que nous changeons la couleur de 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 que les données extraites du serveur récupèrent les données des actifs), cela n'affectera pas 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 ici: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

D'après tout le reste que j'ai vu et lu ici, la mise en œuvre de toutes ces choses le rend plus difficile et ne s'intègre pas bien avec d'autres parties d'Android.

Avoir une activité implémenter d'autres écouteurs est déjà la manière standard d'Android. Le moyen le plus inoffensif serait d'ajouter Java Observer comme les diapositives décrivent et regroupent le onClick et d'autres types d'actions dans des fonctions qui sont toujours dans l'activité.

La manière Android est que l'activité fait les deux. Le combattre 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, 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 langues et systèmes d'exploitation.

Il était surprenant de voir qu'aucun des articles ici n'a répondu à la question. Ils sont soit trop généraux, vagues, incorrects ou ne traitent pas de l'implémentation dans Android.

Dans MVC, la couche View ne sait que montrer l'interface utilisateur (UI). Si des données sont nécessaires pour cela, elles les obtiennent de la couche Modèle . Mais la vue ne demande PAS directement au modèle de trouver les données, elle le fait via le contrôleur . Le contrôleur  appelle donc le modèle pour fournir les données requises pour la vue . Une fois les données prêtes, le contrôleur informe la vue que les données sont prêtes à être acquises à partir du modèle . Maintenant, la vue peut obtenir les données du modèle .

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

Il convient de noter que la vue peut connaître la disponibilité des données dans le  modèle  via le contrôleur - également appelé  MVC passif - ou en observant les données dans le modèle en enregistrant des observables, qui est Active MVC .

En ce qui concerne l'implémentation, l'une des premières choses qui me 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 être en mesure de présenter l'interface utilisateur (UI) sur l'appareil et de répondre à l'interaction de l'utilisateur avec l'interface utilisateur. Les deux Activity  et Fragment  fournissent les méthodes requises 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 d'application complet se trouve 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 à travers un exemple ici .

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

Étant fatigué du désastre MVx sur Android, j'ai récemment créé une petite bibliothèque qui fournit un flux 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). À 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 du composant ayant tout à l'intérieur pour la compacité du code (bien sûr, le modèle et le 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 sur le 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, à chaque clic sur le 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 . En outre, il existe une syntaxe alternative pour Java sans lambdas.

La bibliothèque elle-même est très légère, n'a aucune dépendance, n'utilise aucune réflexion, etc.

(Avertissement: je suis l'auteur de cette bibliothèque)

Selon l'explication que l'équipe Xamarin a expliquée (sur le MVC iOS "je sais que ça semble bizarre, mais attendez une seconde"):

• Le modèle (données ou logique 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'objet parcellable. La vue est la disposition XML et le contrôleur est le (activité + son fragment).

* Ceci est juste mon opinion, pas d'une ressource ou d'un livre.

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).

Veuillez 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 je ne sais pas, Google imposera jamais avec force les restrictions d'une implémentation MVC comme l'iPhone, mais c'est aux développeurs quels patteren ou technique ils veulent dans leur projet, dans de petites ou simples applications, l'utilisation de MVC n'est pas requise, mais comme application grandit et se complique et nécessite des modifications de son code dans les années suivantes, puis il y a un besoin du modèle MVC dans Android.

Il fournit un moyen simple de modifier le code et aide également à réduire les problèmes. Si vous souhaitez implémenter MVC sur Android, suivez ce lien ci-dessous et profitez de l'implémentation 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 devraient utiliser pour des applications Android propres et robustes.

Lorsque nous appliquons MVC, MVVM ou un modèle de présentation à une application Android, ce que nous voulons vraiment, c'est avoir un projet structuré clair et, plus important encore, plus facile pour les tests unitaires.

Pour le moment, sans infrastructure tierce, vous avez généralement beaucoup de code (comme addXXListener (), findViewById (), etc.), qui n'ajoute aucune valeur commerciale.

De plus, vous devez exécuter des tests unitaires Android au lieu des tests JUnit normaux, qui prennent un certain temps à 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 cadre 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 à maintenir. RoboBinding supprime le besoin de code inutile comme addXXListener ou ainsi , et déplace la logique de l'interface utilisateur vers le modèle de présentation, 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 garantir sa qualité.

À ma connaissance, la façon dont Android gère le modèle MVC est comme:

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.

Quand 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 a aussi une partie programme avec ses constructeurs, méthodes et etc, définis dans la classe java.