Quels modèles de conception sont utilisés sur Android?

J’ai essayé à la fois d’utiliser les modèles MVC ( model – view – controller ) et de modélisation – vue – présentateur pour effectuer le développement Android. Mes conclusions sont modèle-vue-contrôleur fonctionne bien, mais il y a quelques “problèmes”. Tout se résume à votre perception de la classe d’ Activity Android. Est-ce un contrôleur ou est-ce une vue?

La classe Activity actuelle n’étend pas la classe View d’Android, mais gère toutefois l’affichage d’une fenêtre pour l’utilisateur et gère également les événements de cette fenêtre (onCreate, onPause, etc.).

Cela signifie que lorsque vous utilisez un modèle MVC, votre contrôleur sera en réalité un pseudo-contrôleur de vue. Comme il gère l’affichage d’une fenêtre pour l’utilisateur, avec les composants de vue supplémentaires que vous avez ajoutés avec setContentView, et également pour gérer les événements pour au moins les divers événements de cycle de vie d’activité.

Dans MVC, le contrôleur est censé être le point d’entrée principal. Ce qui est un peu discutable si tel est le cas lors de son application au développement Android, l’activité étant le point d’entrée naturel de la plupart des applications.

Pour cette raison, je trouve personnellement que le modèle modèle-vue-présentateur convient parfaitement au développement Android. Puisque le rôle de la vue dans ce modèle est:

• Servir de point d’entrée
• Composants de rendu
• Routage des événements utilisateur vers le présentateur

Cela vous permet de mettre en œuvre votre modèle comme suit:

View – cela contient vos composants d’interface utilisateur et gère les événements pour eux.

Presenter – cela permet de gérer la communication entre votre modèle et votre vue, de la considérer comme une passerelle vers votre modèle. Cela signifie que si vous avez un modèle de domaine complexe représentant, Dieu sait quoi et que votre vue ne nécessite qu’un très petit sous-ensemble de ce modèle, le travail des présentateurs consiste à interroger le modèle, puis à mettre à jour la vue. Par exemple, si vous avez un modèle contenant un paragraphe de texte, un titre et un compte de mots. Mais dans une vue donnée, il vous suffit d’afficher le titre dans la vue. Ensuite, le présentateur lit les données nécessaires à partir du modèle et met à jour la vue en conséquence.

Modèle – cela devrait essentiellement être votre modèle de domaine complet. J’espère que cela aidera à rendre votre modèle de domaine plus “serré”, puisque vous n’aurez pas besoin de méthodes spéciales pour traiter les cas mentionnés ci-dessus.

En dissociant le modèle de la vue tous ensemble (en utilisant le présentateur), il devient également beaucoup plus intuitif de tester votre modèle. Vous pouvez avoir des tests unitaires pour votre modèle de domaine et des tests unitaires pour vos présentateurs.

Essaye le. Personnellement, je trouve que cela convient parfaitement au développement Android.

Cette réponse a été mise à jour afin de restr pertinente en novembre 2016

Il semble que vous recherchiez des motifs architecturaux plutôt que des modèles de conception .

Les modèles de conception visent à décrire un “truc” général que le programmeur pourrait implémenter pour gérer un ensemble particulier de tâches logicielles récurrentes. Par exemple: Dans la POO, lorsqu’un object doit notifier un ensemble d’autres objects à propos de certains événements, le modèle de conception de l’ observateur peut être utilisé.

Puisque les applications Android (et la plupart des AOSP) sont écrites en Java, ce qui est orienté object, je pense que vous aurez du mal à rechercher un modèle de conception unique qui ne soit PAS utilisé sur Android.

Les modèles architecturaux , quant à eux, ne traitent pas de tâches logicielles particulières. Ils visent à fournir des modèles pour l’organisation du logiciel en fonction des cas d’utilisation du composant logiciel en question.

Cela semble un peu compliqué, mais j’espère qu’un exemple clarifiera: si certaines applications seront utilisées pour extraire des données d’un serveur distant et les présenter de manière structurée à l’utilisateur, MVC pourrait être un bon candidat. Notez que je n’ai rien dit sur les tâches logicielles et le déroulement du programme de l’application – je viens de le décrire du sharepoint vue de l’utilisateur, et un candidat à un modèle architectural a émergé.

Puisque vous avez mentionné MVC dans votre question, je suppose que les motifs architecturaux sont ce que vous recherchez.

Historiquement, il n’existait aucune directive officielle de Google concernant les architectures des applications, qui (entre autres raisons) entraînait un désordre total dans le code source des applications Android. En fait, même aujourd’hui, la plupart des applications que je vois ne suivent toujours pas les meilleures pratiques de la POO et ne montrent pas une organisation logique claire du code.

Mais la situation est différente aujourd’hui – Google a récemment publié la bibliothèque Data Binding , qui est entièrement intégrée à Android Studio, et a même déployé un ensemble de plans d’architecture pour les applications Android .

Il y a deux ans, il était très difficile de trouver des informations sur MVC ou MVP sur Android. Aujourd’hui, MVC, MVP et MVVM sont devenus des «mots à la mode» dans la communauté Android, et nous sums entourés d’innombrables experts qui tentent constamment de nous convaincre que MVx est meilleur que MVy. À mon avis, discuter de la question de savoir si MVx est meilleur que MVy est totalement inutile car les termes eux-mêmes sont très ambigus – il suffit de regarder les réponses à cette question et vous réaliserez que différentes personnes peuvent associer ces abréviations à des concepts complètement différents.

En raison du fait que la recherche d’un meilleur modèle architectural pour Android a été officiellement lancée, je pense que nous sums sur le sharepoint voir plusieurs autres idées émerger. À ce stade, il est vraiment impossible de prédire quel (s) modèle (s) deviendra (nt) les normes de l’indussortinge à l’avenir – nous devrons attendre et voir (je suppose que c’est une question d’un an ou deux).

Cependant, il y a une prédiction que je peux faire avec un degré de confiance élevé: l’utilisation de la bibliothèque de liaison de données ne deviendra pas une norme de l’indussortinge. Je suis confiant de le dire, car la bibliothèque Data Binding (dans son implémentation actuelle) fournit des gains de productivité à court terme et une sorte de directive architecturale, mais rendra le code non maintenable à long terme. Une fois que les effets à long terme de cette bibliothèque apparaîtront, ils seront abandonnés.

Aujourd’hui, bien que nous ayons des directives et des outils officiels, je ne pense pas personnellement que ces directives et ces outils constituent les meilleures options disponibles (et ce ne sont certainement pas les seules). Dans mes applications, j’utilise ma propre implémentation d’une architecture MVC. Il est simple, propre, lisible et testable et ne nécessite aucune bibliothèque supplémentaire.

Ce MVC n’est pas seulement différent cosmétiquement des autres – il est basé sur une théorie selon laquelle les activités dans Android ne sont pas des éléments d’interface utilisateur , ce qui a des implications énormes sur l’organisation du code.

Ainsi, si vous recherchez un modèle architectural adapté aux applications Android qui respecte les principes SOLID , vous pouvez en trouver une dans mon article sur les modèles architecturaux MVC et MVP sous Android .

Il existe divers modèles utilisés dans le framework Android, tels que:

• Le récepteur de diffusion utilise le motif observateur
• L’appel de service distant utilise le modèle de proxy
• Afficher et afficher les groupes utilisés Modèle composite
• Cadre de support utilise le motif de façade

Quand j’arrive à cet article, cela m’aide vraiment à comprendre les schémas avec l’exemple, donc j’ai fait le tableau ci-dessous pour voir clairement les modèles de conception et leur exemple dans Android Framework

J’espère que vous trouverez cela utile.

• Quelques liens utiles pour référence:

https://www.raywenderlich.com/109843/common-design-patterns-for-android

code.tutsplus.com/articles/introduction-to-android-design-patterns–cms-20808

https://en.wikipedia.org/wiki/Design_Patterns

Voici un excellent article sur les modèles de conception communs pour Android :

Motifs de création:

• Builder (par exemple, AlertDialog.Builder )
• Injection de dépendance (par exemple, Dagger 2 )
• Singleton

Modèles structurels:

• Adaptateur (par exemple RecyclerView.Adapter )
• Façade (par exemple, rénovation )

Motifs comportementaux:

• Commande (par exemple EventBus )
• Observateur (par exemple RxAndroid )
• Modèle Vue Contrôleur
• Modèle View ViewModel ( similaire au modèle MVC ci-dessus )

Les classes Android suivantes utilisent des modèles de conception

1) Voir le titulaire utilise Singleton Design Pattern

2) Intention utilise le motif de conception d’usine

3) L’adaptateur utilise un modèle de conception d’adaptateur

4) Le récepteur de diffusion utilise le modèle de conception d’observateur

5) Affichage utilise un modèle de conception composite

6) Media FrameWork utilise le modèle de conception de façade

Dans le cas des notifications , le NotificationCompat.Builder utilise le modèle de générateur

comme,

 mBuilder = new NotificationCompat.Builder(this) .setSmallIcon(R.drawable.ic_stat_notification) .setContentTitle(getSsortingng(R.ssortingng.notification)) .setContentText(getSsortingng(R.ssortingng.ping)) .setDefaults(Notification.DEFAULT_ALL); 

Android utilise également le modèle de conception de ViewHolder.

Il est utilisé pour améliorer les performances d’un ListView tout en le faisant défiler.

Le modèle de conception ViewHolder vous permet d’accéder à chaque vue d’élément de liste sans avoir besoin de la consulter, économisant ainsi des cycles de processeur précieux. Plus précisément, cela évite les appels fréquents de findViewById () lors du défilement de ListView, et cela le rendra plus fluide.

Tous ces modèles, MVC, MVVM , MVP et Presentation Model , peuvent être appliqués aux applications Android, mais sans une infrastructure tierce, il n’est pas facile d’obtenir une structure bien organisée et un code propre.

MVVM provient de PresentationModel. Lorsque nous appliquons MVC, MVVM et 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 infrastructure 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 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 assurer sa qualité.

Je voudrais append un modèle de conception qui a été appliqué dans Android Framework. Il s’agit du modèle Half Sync Half Async utilisé dans l’implémentation Asynctask. Voir ma discussion à

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

Dans Android, le modèle “work queue processor” est couramment utilisé pour décharger les tâches du thread principal d’une application.

Exemple: Conception de la classe IntentService.

IntentService reçoit les Intents, lance un thread de travail et arrête le service en conséquence. Toutes les requêtes sont gérées sur un seul thread de travail.

Binder utilise “Observer Pattern” pour les notifications de destinataires de décès.