Relecture hhk

[HHK1]

Overall c'est 👍

• Très didactique et clair, le seul endroit vraiment complexe étant celui sur la création de tes Fakes, je te conseille de rajouter un schéma à cet endroit
• J'attends avec hâte ton cours sur les protocols, mais la définition que tu as donné en attendant n'est pas complètement exacte.
• Attention à signaler ou à refactorer les patterns qui ne scale pas
• ça aurait été sympa un petit wrap up des calls réseaux avec la gestion d'erreur à la fin.

[HHK1]

I would not say that JSON is popular because it's small, it's popular because it's simple. And you have options smaller than JSON, such as MessagePack

[HHK1]

Just wanted to introduce the notion of concrete subclass

[HHK1]

Something like declaring a baseURL, and also a version that you can always override if need be.

[AmbroiseCollon]

Yes tu as raison mais j'en demande déjà beaucoup dans ce chapitre.

[AmbroiseCollon]

Je vois ce que tu veux dire. J'imaginais que les autres calls seraient dans d'autres classes donc ça ne pose pas de soucis. Comment tu fais les choses toi ?

[HHK1]

Personnellement j'utilise Alamofire, mais simplement le fait d'avoir un effet de bord quand tu fais ton appel réseau est étrange. Par défaut je ne me soucie pas d'executer mon call plusieurs fois, et lorsque le call est lié à une interface utilisateur, je bloque l'interface quand c'est nécessaire.

[AmbroiseCollon]

J'en parle déjà dans d'autres cours.

[AmbroiseCollon]

Je ne connais pas, je vais regarder.

[HHK1]

Comme dit, ça reste une notion très objective-c. Après réflexion, c'est probablement assez avancé, et même si le parallèle est intéressant, ça risque d'apporter beaucoup de confusion

[AmbroiseCollon]

Je ne comprends pas bien de quel schéma tu parles.

[HHK1]

un truc comme ça

[HHK1]

Peut-être avec des petites flèches par ci par là pour indiquer quand on override, quand on fait une injection, mais tu as l'idée

[AmbroiseCollon]

Je suis d'accord. D'autant plus que ça fait redite avec des cours précédents. Je vais partir sur les callbacks.

[AmbroiseCollon]

OK je vais voir merci

[HHK1]

Si le JSONSerialization n'est pas une option, j'ai découvert ça en cherchant: https://stackoverflow.com/questions/27723912/swift-get-request-with-parameters?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
(comme quoi on en apprend tous les jours)

URLComponents te permet de créer un peu plus proprement tes requêtes GET, si tu veux revisiter cette partie tu peux utiliser ça

[AmbroiseCollon]

Tu as raison, je n'ai jamais utiliser cette fonctionnalité de Swift, c'est pour ça. Comment tu définirais un protocole du coup ?

[HHK1]

"Nous n'avons pas encore parlé en détail des protocoles. On les a seulement survolés. Un protocol définit un ensemble de méthodes et de fonctions qui vont pouvoir être adoptés par un type. En swift le protocol est un concept très puissant, et peut être adopté par une class, un struct ou même un enum. Il permet ensuite de manipuler des types sans avoir à se soucier de ce qu'il y'a derrière. Je peux créer un protocol Weapon avec une méthode shoot() et une variable ammunition, et je pourrais manipuler différents objets sans savoir si j'utilise un lance-pierre ou une mitraillette."

Voilà une proposition. J'ai fait des drafts en essayant d'expliquer l'histoire de l'implémentation, mais ça devient long, et ça n'est pas vraiment le sujet. Du coup c'est passé sous silence, à expliquer au moment voulu

[AmbroiseCollon]

C'est top, je le prends tel quel merci !

[HHK1]

@AmbroiseCollon J'ai rajouté les différents éléments dont on a discuté. Tu me diras si tu besoin d'autre chose.

Est-ce que tu veux que je clean ma PR en enlevant ce que j'avais mis comme commentaires pour que tu puisse merger les petites modifs, ou est-ce que tu laisses la PR telle quelle et tu intègres les modifs à la main ?

[AmbroiseCollon]

Merci pour ton aide ! J'ai déjà intégré tes motifs à la main donc pas de problème. Je vais rajouter les derniers éléments merci.