Sprint 2 : 12/10 - 10/01
Démo :
Création d'un ou plusieurs paris sous iOS et Android (Pas le même) puis mutuellement participer aux paris de l'autre. Ensuite, consulter les informations des paris puis vérifier qu'ils sont bien dans la page des bets en cours.
Arthur
-
Développement de l'écran de status d'un bet (4h): J'ai commencé l'implémentation graphique de l'écran de status d'un bet. Il s'agit d'une BottomSheet particulière qui s'affiche lorsque l'on appuie sur le bouton "Participer" d'un Bet sur l'écran d'accueil.
Pour gérer le fait que différents types de bets peuvent avoir différents types d'affichages, j'ai mis en place un patron Visiteur qui me permet de rajouter une logique d'affichage dans à mon objet. Cependant, l'un des problèmes que j'ai rencontré est le fait que le Visiteur devait être dans le module "App" et la classe Bet dans le module "Data", ainsi le Bet ne pouvais pas connaître le Visiteur et donc pas implémenter la méthode "Accept". Pour remédier à cela j'ai créé dans "App" une class "BetVO" qui viens wrapper la classe Bet et qui lui pourra implémenter "Accept". Cependant un autre problème s'est posé à moi, comment créé une instance concrète de BetVO à partir d'un Bet. Pour cela j'ai créé une Factory qui me permet de créer mes BetVO. Cependant j'ai dû avoir recours à du mapping (Je choisie la Factory en fonction de la classe de mon Bet), ce qui ne me plaît pas. Mais je n'ai pas pû trouver d'autre solution.
Malgré tout, cette implémentation me permet d'être flexible et créant divers visiteurs concrets en fonction des pages qui nécessite d'afficher des Bets de manières différentes selon la classe concrète, et donc de ne pas surcharger, ni ma classe Bet, ni ma classe BetVO de responsabilités.
Pour finir, j'ai rapidement mis en place des Tests UI, qui vérifient le bon fonctionnement de mon visiteur, et qu'un Bet concret sera bien affiché de la bonne manière via le visiteur.
-
Corrections des problèmes vus durant le rendez-vous (2h): J'ai corrigé les problèmes vus pendant la réunion. Ainsi le client Android effectue à présent une vérification des données dans l'écran de création de compte. J'ai aussi corrigé quelques soucis que j'avais avec mon client retrofit, notamment par rapport à la gestion des erreurs.
-
Migration vers kotlin gradle (2h): J'ai migré le projet de gradle à kotlin gradle (kotlin scripts au lieu de groovy). J'en ai profité pour mettre à jour les versions de mes dépendances.
-
Écrans d'historiques et des paris en cours (2h): J'ai créé la coquille vide des écrans d'historique des paris et des paris en cours, deux écrans très similaires. Pour ces écrans sont peuplés avec des fausses données.
-
Connexion avec JWT et déconnexion de l'application (2h): Lors de la connexion d'un utilisateur, je stocke un token renvoyé de l'API dans un EncryptedSharedPreferences. Lorsque l'utilisateur ouvrira l'application, si un token y est stocké, je fait la demande de connexion à l'API avec le token automatiquement. Cela permet de connecter l'utilisateur directement dans l'application. J'ai également implémenté la fonction de déconnexion, qui supprime le token en local et remet l'utilisateur sur l'écran d'accueil.
-
Création d'un pari (1h): Appel à l'API afin de créer un pari dans l'application depuis l'écran de création d'un pari. Gestion des erreurs dans l'écran du formulaire, et affichage d'une snackbar lors de la création.
Emre
-
Développement de la page de création d'un bet (4h): J'ai continué à travailler sur la page de création de pari en améliorant les détails visuels. De plus, j'ai développé mon propre composant pour créer un menu déroulant que j'ai personnalisé et intégré à la page. J'ai réussi à adapter la page en fonction de l'élément sélectionné.
-
Injection de dépendance (4h): J'ai créé ma propre classe d'injection de dépendance en Swift, car Swift ne propose pas cette fonctionnalité par défaut. J'ai réussi à le faire en utilisant un propertyWrapper que j'ai nommé @Inject, qui permet de fournir une instance unique de certaines classes à travers toute l'application sans passer par le constructeur. J'ai également effectué des tests fonctionnels pour m'assurer que tout fonctionne correctement.
Exemples d'utilisation :
Dans le main :
DependencyInjection.shared
.addSingleton(IA.self, A())
.addSingleton(IB.self, B())
.addSingleton(C.self, C())
Dans une classe ou une vue :
@Inject private var b: IB
L'instance de la classe B sera alors donnée !
💡 Petit plus !
La classe DI a été intégrée dans un projet framework en Swift, situé en dehors de l'application SwiftUI. Cette approche permet son utilisation dans n'importe quel projet facilement, il suffit simplement d'ajouter l'instruction : import DependencyInjection. Utilité : Réutilisable n'importe où, une meilleure modularité, réutilisation du code par d'autres développeurs, indépendance vis-à-vis des autres projets et une meilleure encapsulation.
- Réalisation du modèle et des ViewModel (4h): Afin de garantir une architecture maintenable et l'évolution de l'application, nous avons opté pour le patron d'architecture MVVM. J'ai donc commencé à réaliser en grande partie tout ce qui est côté modèle, avec les classes métier et d'un Stub qui pourra être remplacé via l'injection de dépendances par la suite. J'ai également commencé à réaliser la partie ViewModel en créant les VM applicatifs qui sont attachés aux vues, ainsi que les VM Wrappers attachés aux modèles et qui encapsulent les classes métiers. Cette approche vise à faciliter le changement de l'interface utilisateur rapidement sans avoir à refaire les wrappers, et inversement.
Lien vers l'architecture : MVVM
- Création d'un Bet (2h): J'ai réalisé la création d'un Bet via l'API et la gestion des erreurs liées aux informations d'entrée du BET.
Lucas D
-
Développement et amélioration de la pop up de gain et implementation des vues(4h): J'ai continué à travailler sur la pop up en ajoutant un effet pour rendre la pop up plus intéressante car elle apparaitrait pour notifier de gain de pieces aux utilisateurs. J'ai également continué l'implementation des vue sen rajoutant des elements au menu dans la page principales et en commençant a produire des premiers tests d'animation pour l'ouverture de la page de pari. J'ai également commencé l'implementation de la page historique avec ses composants associés
-
Aide a la réalisation des ViewModel (3h): J'ai assisté Emre pour reflechir a la conception du MVVM. Nous pensons que nous pouvons réutiliser ce que nous avons appris en cours lors du premier semestre pour simplifier la réactivité des données entre notre model et les vues.
-
Finalisation et validation des maquettes (2h): J'ai terminé les visuels manquant sur Figma. Nous avons maintenant toutes les maquettes pour mener a bien l'intégration des vues. Nous pensons cependant que certaisn composants difficiles comme la barre de chargement qui represente les % de participations aux bets va etre compliqué a implémenté en SwiftUI. En effet, SwiftUI étant jeune, nous pensons que cela va etre dur car la documentation ne précise pas des détails aussi précis et que très peu d'exemple sont a notre disposition. Peut etre il sera nécessaire de changer légèrement ce visuel et d'autres a cas par cas.
Lucas E
- Mise en place de la gestion des Users sur l'API(6h): J'ai défini les informations à utiliser pour pouvoir se connecter sur l'application. Afin de garantir une certaine sécurité sur les actions ainsi que pour maintenir les utilisateurs connectés même après la fermeture de l'application, j'ai ajouté la gestion des token JWT. Les mots de passe sont chiffrés, et plus tard les informations sensibles le seront aussi. Il reste cependant à stocker indéfiniment les comptes dans une base de donnée.
