Alors que j’avais décidé de franchir le pas et de prendre la formule en janvier prochain, le mail de Maxime d’il y a quelques jours annonçant une (substantielle) prochaine augmentation (50% quand même), m’a décidé et j’ai pris cette fameuse formule qui me tentait tant. Bien m’en a pris car j’ai du coup eu accès à toutes les vidéos. Et entre autres, celle qui parlait du singleton. J’avais déjà entendu parlé de ce truc mais sans comprendre vraiment ce que c’était et à quoi ça servait. Et du coup, maintenant je pense avoir bien compris.
Et en découvrant ce concept, je me suis dit : mais pourquoi ne pas l’avoir utilisé dans le cours sur SwiftUI et iOS14 pour résoudre le pb du AppManager que la vue veut passer à son viewModel, au lieu de se trainer cet optionnel qu’il faut gérer en permanence?
Je l’ai testé sur mon appli et ça a l’air de fonctionner très bien avec un code bien plus clair.
Y a-t-il une contre-indication a utiliser ce singleton dans ce cas?
Et d’ailleurs je n’ai pas vu, dans iOS15, d’information sur une éventuelle solution au problème du StateObject qui n’accepte pas de paramètre. Mais je n’ai pas tout regardé.
Salut Pascal, il faut être prudent avec le singleton : c’est tellement pratique qu’on a tendance à s’en servir partout, mais du coup on crée des dépendances entre toutes les classes.
Tu devrais regarder le cours sur les tests unitaires (surtout maintenant que tu as accès à tous les cours via la formule ).
Quand tu vas vouloir tester chacun de tes modules en isolation, tu risques d’être embêté par les singletons qui apparaissent de nulle part et qui sont difficiles à Mocker.
Salut Maxime,
Merci pour ta réponse. Je n’avais pas eu beaucoup de succès avec ma question Heureusement que tu es là.
C’est vrai que je l’ai trouvé très pratique. Trop pratique même pour être honnête. Mais bon, faute d’information, j’ai continué à l’expérimenter.
En fait je ne suis pas encore très à l’aise avec la POO. Je comprends bien les principes et comment ça marche, mais j’ai tendance à faire des classes trop grosses.
Mais le plus gros pb que j’ai c’est avec SwiftUI et surtout l’architecture logicielle sous jacente.
Je suis à la lettre ce que tu as préconisé dans les cours iOS14 (je n’ai pas encore eu le temps de voir comment tu les avais adapté à iOS15), et donc j’ai une succession de vues accompagnées de leur ViewModel, et un AppManager qui héberge toute la logique de l’appli.
Mais cet AppManager est constitué d’une seule classe et fait presque 600 lignes. Et je suis convaincu que c’est (beaucoup) trop.
Et c’est pour passer cet AppManager aux différents ViewModels que j’ai utilisé le singleton pour éviter la gestion des optionnels dans les ViewModels.Mais je vais revoir tout ça…
J’ai commencé à regarder les cours sur les tests unitaires, très intéressant, mais pour ne pas me disperser je voulais d’abord avoir un état propre et stable de l’appli avant de me pencher là dessus.
Bonne soirée.
Si tu le peux tu devrais assister au meetup de demain. @Quentin va parler de Clean Architecture et ça devrait t’inspirer. Même si sa présentation est prévue pour l’univers de Flutter, le principe sera probablement très similaire sur SwiftUI.
Bonsoir à toutes et tous,
Merci de l’info. Je ne connaissais pas le concept de clean architecture, du coup j’ai regardé un site qui en parlait et qui représentait ça sous forme de couches concentriques. Ça m’a fait pensé aux couches du modèle ISO pour les réseaux. Très intéressant.
Je ne suis pas sûr de pouvoir être libre pour le meetup, mais au pire je le regarderai en replay. C’est vrai que c’est le concept qu’il faut comprendre, après on peut l’adapter à presque tous les langages.
Bonne soirée
Pascal
).
