Développez votre première application pour iOS

C’est la dernière journée avant la fin du sprint, Samira a le temps de vous montrer une autre optimisation de code afin de finir en beauté !

Cette fois-ci vous n’allez pas juste améliorer vos structures et vos vues, mais l’organisation de votre projet et ses fichiers.

Après cela, vos 2 projets de POC seront terminés !

Découvrez les patterns d’architecture

Pas de panique, vous allez voir, ce n’est pas si difficile à comprendre.

Déjà, un pattern c’est quoi ? C’est tout simplement un modèle ou on peut dire aussi un patron, que vous allez pouvoir réutiliser et adapter à votre projet.

Certaines problématiques de code sont assez communes aux projets d’un même langage, voire de tous les projets. C’est le cas de l’architecture des fichiers.

Peu importe le langage sur lequel vous travaillez, pour que n’importe qui de votre équipe et vous-même puissiez vous retrouver facilement dans l’arborescence de fichiers, c’est important que celle-ci soit organisée. Il en va de même si quelqu’un doit relire ou travailler sur votre code. Il sera plus facilement maintenable et debuggable.

Pour faciliter les choses, les développeurs et développeuses ont donc créé des patrons d’architecture qui peuvent s’appliquer sur plein de projets différents. Vous vous en doutez, il en existe beaucoup et nous n’allons pas tous les voir.

Pour iOS regardons les 3 qui sont les plus utilisés. Ils se découpent tous en 3 grandes parties :

C’est le pattern d’architecture le plus connu et le plus utilisé dans tous les langages. C'était celui qui était recommandé par Apple il y a encore quelques années.

• Le M c’est pour Model et donc en français, on pourrait traduire par modèle de données. C’est dans cette partie qu’on va déclarer les objets que l’on va créer pour représenter les données que l’on va utiliser dans le projet. C’est ici aussi que l’on pourra retrouver les appels réseaux pour récupérer des informations depuis des serveurs.

• Le V c’est pour View. Vous avez peut-être déjà réussi à traduire mais c’est bien la vue. Dans cette partie on veut s’occuper uniquement de l’interface utilisateur, ce que voit celui-ci.

• Et enfin le C c’est pour Controller, car c’est dans cette partie que l’on va chercher à contrôler l’application. Dans cette portion du projet, on va retrouver toute la logique, les calculs, tout le travail de fond qui ne sont pas de l’affichage ou du modèle de données. C’est aussi ici que l’on va récupérer les actions de l’utilisateur, par exemple s’il clique sur un bouton, on va traiter l’information ici. Vous pouvez avoir un controller pour une vue ou un controller pour plusieurs vues.

Le controller va donc donner des ordres à la vue et au modèle, en fonction de ce que l’utilisateur aura demandé.

Avec le framework de conception d’interface UIKit (pas de SwiftUI par conséquent), les fichiers pour représenter un écran s’appellent des ViewControllers. C’est donc à la fois des V et des C. Ils regroupent alors les 2 fonctions et cela semble être plus pratique. Mais le souci, c’est que les fichiers peuvent devenir très (très) gros !

Les développeurs et développeurs iOS ont donc cherché d’autres solutions, d’autres patterns.

Une des solutions trouvées pour remédier au Massive View Controller en iOS avec UIKit est d’utiliser le MVP.

Le M, c’est toujours le modèle, rien ne change.

Le V pareil, c’est toujours la vue.

En revanche, le P, c’est pour Presenter. En soi, si le M et le V sont pareils, le P devrait ressembler au Controller du MVC. C’est sûr que le découpage est semblable. En revanche il y a 3 différences majeures avec le MVC :

1. Un presenter ne peut avoir qu’une vue associée.

2. La vue ne peut discuter avec le modèle et inversement que par l'intermédiaire du presenter. Le P est donc en discussion avec le M et le V.

3. Les actions de l’utilisateur sont traitées par la vue et non par le presenter.

Ça ne paraît pas être grand-chose, mais sur des gros projets, cela peut avoir un très gros impact et simplifier grandement les responsabilités de chacun des fichiers.

Pour ce qui est des ViewController de UIKit, il suffit de les utiliser uniquement comme vue pour afficher et créer un autre fichier presenter associé a la vue, qui s’occupe de gérer les calculs et les interactions avec l’utilisateur.

Ce n’est pas la seule solution possible pour éviter les Massives View Controller mais elle peut être assez simple à mettre en place, surtout si le projet existe déjà et qu’il faut le faire évoluer.

Le MVVM est aussi une solution très utilisée en entreprise pour UIKit mais c’est surtout le pattern d’architecture recommandé pour SwiftUI !

On retrouve toujours notre Model et notre View, vous commencez à connaître.

Et non ! C’est pour ViewModel. Et oui, Model, View et ViewModel. Vous admettrez qu’ils auraient pu trouver plus pratique comme nom, mais bon tant pis !

Encore une fois le découpage reste grossièrement le même, alors qu’est ce qui change cette fois-ci ?

1. L’interaction avec l’utilisateur se fait par la vue, comme pour le MVP.

2. Un ViewModel peut avoir plusieurs vues, comme pour le MVC.

3. Le modèle et le VM peuvent discuter sans souci. En revanche, le M ne peut pas interagir avec la vue et celle-ci ne fait qu’observer le view model. Concrètement, cela signifie que la vue ne fait qu’afficher les informations stockées dans le VM. Si une information change, elle adapte son affichage en conséquence.

Très souvent en SwiftUI, pour les petits projets, vous n’aurez qu’un seul VM pour toute l’application. Pour nos 2 POC, un seul VM pour chaque projet sera suffisant.

Tout cela peut sembler très abstrait et c’est normal. C’est en pratiquant que cela viendra !

Samira vous propose donc de vous attaquer au projet POC 1 et de commencer à mettre en place une architecture plus claire.

Organisez votre projet

Comme dit précédemment, pour SwiftUI, la solution la plus adaptée c’est le Model View ViewModel (MVVM)

1. Commencez par organiser le projet avec des dossiers. Il suffit de faire un clic droit sur le nom du projet à gauche dans l’arborescence et de sélectionner “New Group”. Il est possible de le faire également en utilisant la barre d’outils en haut en cliquant sur File > New > Group.

2. Créez 3 dossiers :

• Un dossier appelé Model

• Un dossier nommé View

• Un dossier pour les ViewModels

Qu’il y ait 1 ou plusieurs fichiers à y mettre, vous pouvez utiliser cette structure de dossiers sur n’importe quel projet dès la création de celui-ci. Cela est très courant et vous vous y retrouverez plus facilement.

1. Dans le dossier Model, vous allez déplacer le fichier Model dedans. Pour cela vous pouvez faire un drag and drop directement depuis l’arborescence à gauche. Cela modifie également votre projet dans l’explorateur de fichier Finder.

2. Déplacez vos fichiers de type View dans le dossier View. Vous devriez en avoir 3 (ContentView, BubbleView et ListingView).

À cette étape, votre arborescence de fichiers devrait ressembler à ceci :

Passons au ViewModel.

Implémentez votre ViewModel

Comment concrètement vous allez pouvoir ajouter et utiliser un ViewModel dans votre projet. C’est ce que nous allons voir ensemble dans cette vidéo :

Voici les étapes en résumé :

1. Créez un nouveau fichier nommé ViewModel de type Swift dans le dossier ViewModel.

2. Créez la classe ViewModel.

3. Déplacez la variable listeFemmes de ListingView dans votre classe ViewModel.

4. Retirez le private devant cette variable pour y accéder en dehors de la classe.

5. Créez une instance de ViewModel dans ListingView appelée viewModel.

6. Initialisez-la en utilisant le constructeur de la classe, directement dans la déclaration.

7. Pour accéder à la liste des femmes, il faudra passer par votre nouvelle instance comme ceci : viewModel.listeFemmes.

Pas si compliqué vous voyez. Et pourtant regardez à quel point la vue de listing est bien plus lisible !

En respectant la même architecture sur vos projets, vous gagnerez en efficacité et en qualité.

Beau travail ! Vous avez fini l’application du POC 1 ! 👏

À vous de jouer

Contexte

Samira veut vérifier que vous avez bien compris le pattern d’architecture MVVM.

Je te propose de reproduire ce que nous avons fait ensemble sur le POC 1, sur le POC 2.

Cela te permettra de valider tes acquis.

J’ai un point à régler avec Amad et je reviens vérifier que tu as bien compris.

Consignes

Reproduisez ce qui a été fait pour mettre en place le pattern d’architecture MVVM dans ce chapitre sur votre projet POC 2.

Voici les étapes pour y arriver :

1. Créez les 3 dossiers :

   • Model

   • View

   • ViewModel

2. Déplacez le fichier Model dans le dossier Model et les vues dans le dossier View.

3. Créez un nouveau fichier ViewModel pour y déclarer une nouvelle classe ViewModel à l'intérieur.

4. Déplacez la variable listFemmes dans cette classe.

5. Créez une instance viewModel dans la structure ListingView pour pouvoir utiliser la liste de femmes.

En résumé

• Un pattern est un modèle utilisé dans le code pour répondre à une problématique courante.

• Un pattern d’architecture permet d’organiser l’arborescence d’un projet afin qu’il soit mieux découpé et plus compréhensible.

• 3 des patterns d’architecture les plus courants pour iOS sont : MVC, MVP et MVVM.

• MVVM est le pattern recommandé pour les projets en SwiftUI.

Hop hop hop ! Fini, vous avez dit ?

On ne part pas sans avoir testé une dernière fois l’application afin de garantir que tout marche correctement ! On voit ça dans le dernier chapitre de ce cours.