Android Firebase Kotlin java Mvp Mvc Mvvm chat

Quel est ce référentiel pour ❓

Application simple avec une connectivité une à une à l'aide de la base de données en temps réel Firebase écrit en architecture MVC, MVP et MVVM pour mieux comprendre les modèles de codage Android. Objectif de la même fonctionnalité d'application avec 3 modèles différents est de montrer comment une application unique peut être développée en utilisant 3 modèles différents (MVC, MVP, MVVM) ?.

MVC (Contrôleur de vue du modèle) 〽️ ✔️ C

MVC est une approche propre dans Android éloignant les vues du contrôleur. Le contrôleur est uniquement responsable de la mise à jour des modèles, une fois le modèle mis à jour, il peut aviser les vues, puis la vue peut être mise à jour à l'aide de rappels appropriés. Le MVC traditionnel est l'endroit où il y a un

Modèle : agit comme le modèle de données
Voir : traite de la vue de l'utilisateur qui peut être l'interface utilisateur
Contrôleur : contrôle l'interaction entre le modèle et la vue, où View appelle le contrôleur pour mettre à jour le modèle. Une vue peut appeler plusieurs contrôleurs si nécessaire.

MVP (présentateur de vue du modèle) 〽️ ✔️ ? ️

Certains inconvénients de MVC peuvent être surmontés en utilisant l'approche MVP. Le présentateur dans MVP contient toute la logique métier et cette classe est loin du contexte Android ou des dépendances liées à Android qui offrent une flexibilité à la logique métier de texte en utilisant simplement la classe de présentateur dans les modules de test. Les dépendances liées à Android créent une complexité dans les tests. Le présentateur n'a pas de dépendance Android comme le contexte, la vue, etc. et toutes les mises à jour du modèle et les demandes de réseau sont effectuées via le présentateur. Une fois le modèle mis à jour ou une demande de réseau terminée, la vue est mise à jour via le présentateur à l'aide de rappels pour afficher à partir du présentateur. Aucune demande de modèle et de réseau ne peut aborder directement les vues.

MVVM (modèle de vue de vue du modèle) 〽️ ✔️ ✔️ 〽️

MVVM implique une approche de liaison de données pour rendre le code court et réduire le code de gestion de la vue à partir des classes Java. Les modèles de vue sont responsables de mettre à jour la vue et une fois qu'un modèle de vue est lié à une vue, Affichez, faites notifier leurs événements de mise à jour. Si un modèle est mis à jour par un utilisateur, cliquez, le modèle envoie des rappels pour afficher le modèle qui met à jour la vue automatiquement lorsqu'elle est liée aux vues. MVVM réduit la taille du code, mais la mise en œuvre de MVVM est assez difficile et il est difficile de déboguer de grands projets en fonction de MVVM.

Choix de l'architecte correct

?
Le choix d'une architecture correcte pour le projet implique la compréhension des modules qui doivent être développés. Certaines fonctionnalités fonctionnent très bien sur MVC, certaines avec MVP et certaines avec MVVM. Il est assez difficile de déboguer les projets réalisés sur MVVM spécialement ceux qui n'ont pas le flux de données unilatéral en raison de la liaison des données et des données en direct. Si une application reçoit un flux de données continu à partir d'une source, a besoin d'une communication UI régulière et a une communication unilatérale principalement (80 à 90%) (par exemple: des appareils électroniques envoyant des journaux à une application Android) comme les applications de cellules solaires, les applications d'Inverters ou tout autre appareil de l'état de l'appareil peuvent bien fonctionner avec MVVM en raison de la mise à jour des données en direct . Le débogage de ces applications MVVM peut être facile car le flux majeur de données est unilatéral .

MVP est une bonne approche pour rédiger des projets Android lorsque nous sommes soucieux de tester les tests unitaires WRT WRT WRT via des frameworks de test Java (pas Android). Étant donné que Java Test Framework ne résoudra que les dépendances Java et une couche de présentateur propre est exempte de dépendances liées à Android comme le contexte, les reprises partagées ou tout autre com.android. * emballer. L'inconvénient de MVP est qu'il finit par écrire un code supplémentaire de 20 à 25% avec les mêmes fonctionnalités écrites en MVC ou MVVM. MVP est bon si vous êtes vraiment intéressé par les cas de test et les tests unitaires des modules. Pour MVP à l'aide de kits de test Java, faites simplement une instance de présentateur et exécutez les fonctions de test.

EG: nouveau présentateur (). TestSomeFunction () .

MVC est une technique largement utilisée dans Android. Google lui-même a écrit ses référentiels dans MVC depuis de nombreuses années. Désormais, Google adopte MVVM pour ses référentiels GitHub car ces référentiels sont de petits et principalement des échantillons. L'application MVC peut être testée via des cadres de test Android qui ne sont pas avec des outils de test spécifiques à Java en raison du manque de dépendances de com.android. * Packages en outil spécifique Java.

Exemple :

1. Une application de chat peut être écrite dans MVC, MVP, MVVM en fonction des exigences de test et du flux de données.
2. Une application de surveillance de l'onduleur lumineux peut mieux fonctionner avec MVVM en raison du flux de données unilatéral majeur.
3. L'application de commerce électronique peut être construite en MVC, MVP mais MVVM peut rendre certains modules très complexes.

Remarque : il n'y a pas d'architecture unique qui est le mieux. S'il y en avait un, il n'y aurait pas besoin d'apprendre d'autres architectures. Le choix de l'architecture correcte dépend de plusieurs facteurs tels que les exigences initiales, le flux de données, l'évolutivité, la maintenance, les mises à jour (CR), les exigences de test.

À l'exception de ces trois architectures Android, il y a une autre architecture nommée "MVI - Modèle d'intention de vue". Ce n'est pas très populaire parmi les développeurs Android. Veuillez vérifier ce lien si vous êtes intéressé par MVI .
https://github.com/saksham24/android-simple-mvi-pattern-with-mvp-mvvm-collaboration

FIN ️