Cet article s'adresse aux débutants dans le développement Android et est conçu pour aider à créer la structure d'application minimale requise.
Il se trouve que j'ai relativement récemment commencé à programmer pour Android - après un mois sans projet dans l'entreprise où je travaille, j'ai été affecté à l'équipe de développement mobile du bureau uruguayen de Tata Consultancy Services. En discutant avec le chef d'équipe, j'ai entendu une pile avec laquelle je devais d'abord me familiariser, puis maîtriser. Entre autres choses, il y avait le cadre Dagger 2 pour DI et MVP comme modèle architectural. Et Kotlin. Mais à propos de lui une autre fois :)
J'ai donc commencé à étudier d'abord les bases du SDK Android, puis toute la pile qui l'accompagne. Il n'y a eu aucun problème avec le SDK lui-même - il y a plus qu'assez d'informations exhaustives à ce sujet sur le réseau, à partir de la documentation officielle et en terminant par les tutoriels (le projet startandroid a aidé en particulier avec cela), mais il y a eu quelques difficultés avec Dagger 2 et MVP concernant le développement Android en raison d'une assez courte documentation du premier et, à l'époque, compréhension insuffisante du second. Le fait est qu'avant le développement mobile, je faisais des microservices en Java en utilisant Spring Boot / MVC et j'avais déjà une bonne idée de ce qu'est l'injection de dépendances et de ce qu'est MVC. De plus, même le nom «Spring MVC» lui-même suggère que ce modèle est intégré dans l'architecture du projet et son utilisation est évidente. De Dagger 2, je m'attendais à la même «magie» qu'au printemps et à la même documentation élaborée et aux mêmes didacticiels. Et rompit: P
Néanmoins, avec une persévérance et une persévérance suffisantes, rien n'est impossible, et le résultat de la recherche a été la mise en œuvre de mon idée de longue date qui a surgi même à l'époque où je ne pensais même pas au développement Android. Vous pouvez évaluer l'idée en installant l'application depuis le Google StoreDans cet article, je voudrais présenter une compression à sec du résultat de mes recherches - un guide étape par étape sur la création du squelette d'une application Android en utilisant MVP et Dagger 2. Alors, commençons.
1.1 Résumés
Commencez par créer le package de résumés à la racine du projet, que ce soit com.caesar84mx.mymvcapp.abstracts. Nous allons y créer 2 interfaces: view.BaseView et presenter.BaseMvpPresenter. Comme suit:
Ce sont les éléments architecturaux de base qui seront ensuite utilisés dans l'application. Ensuite, ouvrez BaseView et déclarez-y les méthodes showView () getContext ():
interface BaseView { fun showView(view: View, isShown: Boolean) { view.visibility = if (isShown) View.VISIBLE else View.GONE } fun getContext(): Context }
Ouvrez maintenant BaseMvpPresenter et modifiez-le comme suit:
interface BaseMvpPresenter<V: BaseView> { var isAttached: Boolean fun attach(view: V) fun detach() }
Dans le package de vue, créez une classe BaseCompatActivity abstraite, héritez-la d'AppCompatActivity et implémentez l'interface BaseView nouvellement créée. À l'intérieur de la classe, nous déclarons la méthode init abstraite (savedInstanceState: Bundle?) Et implémentons la méthode getContext () de BaseView:
abstract class BaseCompatActivity: AppCompatActivity(), BaseView { override fun onCreate(savedInstanceState: Bundle?, persistentState: PersistableBundle?) { super.onCreate(savedInstanceState, persistentState) init(savedInstanceState) } protected abstract fun init(savedInstanceState: Bundle?) override fun getContext(): Context = this }
De cette classe à l'avenir, nous hériterons de toutes les activités.
Passons maintenant au présentateur - créez une classe BasePresenter qui implémente l'interface BaseMvpPresenter et implémentez les méthodes d'interface comme suit:
open class BasePresenter<V : BaseView> : BaseMvpPresenter<V> { protected var view: V? = null private set override var isAttached = view != null override fun attach(view: V) { this.view = view } override fun detach() { this.view = null } }
Eh bien, nous avons identifié les éléments architecturaux de base, passons maintenant aux composants à partir desquels notre application sera construite.
1.2. Composants
Tout d'abord, créez le package com.caesar84mx.mymvcapp.components, dans celui-ci le package mainscreen, dans lequel, à son tour, les packages ui et backstage, et transférez la classe MainScreen dans le package ui:
Nous allons maintenant supprimer de la classe MainScreen l'implémentation de la méthode onCreate () générée automatiquement lors de la création du projet, ainsi que l'héritage d'AppCompatActivity et l'hériter de BaseCompatActivity. Maintenant, nous implémentons la méthode init () précédemment déclarée dans la classe de base. Tout le code que nous mettrions plus tôt dans la méthode onCreate (), nous le mettons (comme nous nous en souvenons, la méthode init () est appelée dans la méthode onCreate () de la classe de base):
class MainScreen : BaseCompatActivity() { override fun init(savedInstanceState: Bundle?) { setContentView(R.layout.activity_main_screen) } }
Génial, l'élément de vue du modèle MVP est créé, passons maintenant au backstage de notre composant - le package backstage. Créons l'interface MainScreenContract - le soi-disant contrat à travers lequel nous allons implémenter notre modèle. Dans cette interface, créez 2 sous-interfaces - Presenter et View:
interface MainScreenContract { interface Presenter: BaseMvpPresenter<MainScreenContract.View> interface View: BaseView }
Passons maintenant au présentateur et créons la classe MainScreenPresenter:
class MainScreenPresenter : BasePresenter<MainScreenContract.View>(), MainScreenContract.Presenter { }
Le squelette d'application est presque prêt, il reste quelques touches. Dans la classe MainScreen, ajoutez l'implémentation de l'interface MainScreenContract.View, créez et initialisez la variable de présentateur: MainScreenPresenter, et dans la méthode init (), attachez la vue au présentateur comme suit:
class MainScreen : BaseCompatActivity(), MainScreenContract.View { val presenter: MainScreenPresenter? = MainScreenPresenter() override fun init(savedInstanceState: Bundle?) { setContentView(R.layout.activity_main_screen) presenter?.attach(this) } }
Ainsi, nous avons créé un présentateur et ajouté notre instance de vue (à ne pas confondre avec android.view.View), qui dans le présentateur sera utilisée pour manipuler la vue.
1.3. Conclusion de la première partie
Ainsi, nous avons créé les éléments abstraits de base du modèle MVP, qui, cependant, ne sont pas utilisés directement, sur le front, mais à travers ce qu'on appelle. contrat - l'élément de base de chaque composant de l'application, qui combine à la fois les actions de l'élément view et les actions de l'élément presenter. Un contrat est un élément assez flexible, dont la composition varie d'un composant à l'autre, reliant discrètement les composants au sein d'une même architecture.
Il faut se rappeler que, conformément au concept de MVP, l'élément de vue doit être aussi brutal que possible, en cela nous n'effectuons que des actions élémentaires, telles que, par exemple, afficher / masquer le texte, changer l'arrière-plan ou la couleur du texte, afficher / masquer l'icône de téléchargement, etc. d. Nous définissons les méthodes correspondant à cet élément dans la sous-interface du contrat View. Alors que nous traitons de la logique dans un présentateur - logique métier, manipulation de données (CRUD), lancement de tâches d'arrière-plan, etc. Dans ce document, nous décidons quand afficher certains éléments à l'écran. Ceci est différent du concept MVC mis en œuvre au printemps, où entre la logique métier et la vue, il y a un contrôleur stupide qui ne reçoit que les demandes de la vue et appelle un service qui renvoie des données ou effectue d'autres actions définies par la logique métier. Les méthodes correspondant au présentateur sont définies dans la sous-interface du contrat Presenter.
Lors de l'implémentation du présentateur, la vue sera manipulée via la variable de vue de la superclasse BasePresenter, tandis que les méthodes correspondant à la vue sont implémentées dans la classe d'activité.
Vous demandez, où est Dagger 2 ici et pourquoi nous a-t-il été rendu, l'implémentation DI dans Android attirera-t-elle un hibou sur le globe? La réponse à la deuxième question est non, elle ne le sera pas. Et pourquoi et pourquoi cela est nécessaire - dans la
deuxième partie de mon article;)