Sprint 4 : 25/01 - 08/02
Durée de sprint
8h * 4 personnes => 32h
User Stories concernées :
- Écran des bets en cours (iOS)
- Consulter l'historique de ses paris
- Fin d'un pari
- Écrans de liste d'amis et ranking (Android)
Démo :
Création d'un pari sur Android et iOS avec deux comptes séparés. Sur chacune des apps, changer de compte et participer aux deux paris avec des réponses différentes. Les paris se termines (On a au préalable rentré une Date de fin très courte). Se connecter en tant que créateur du pari et vérifier la réponse. Se reconnecter sur le compte : Le gagnant reçoit des points et le perdant rien du tout.
Le pari doit apparaitre d'abord dans la liste des paris en cours puis dans l'historique des paris.
Arthur
-
Écran de confirmation de la réponse d'un bet (2h): J'ai fait l'implémentation graphique de la maquette de la page permettant au créateur d'un pari de valider sa réponse finale lors de la fin de ce dernier.
-
Source de données abstraite dans l'API (2h) : J'ai modifié le code de l'api afin de rendre la source des données abstraite. Deux implémentations existes : données mockées ou base de données postgres. Le choix se fait avec une variable d'environnement DATA_SOURCE.
-
Status des Bets dans l'API (1h) : J'ai rajouté le type et le status des bets dans l'API. J'ai également fait en sorte que le status des Bets soit mis à jours toutes les 5 minutes.
-
Résultat d'un Bet et historique (3h) : J'ai rajouté les tables, les entités et les routes permettant de stocker le résultat d'un pari. J'ai également fait les routes d'historique et de paris en cours d'un joueur.
-
MLD (30 min) : J'ai fait le modèle logique de la base de donnée, disponible ici.
Emre
-
Correction des erreurs (45 min): À la suite de la réunion à la fin du sprint 3, j'ai corrigé les erreurs qui ont été identifiées. Cela inclut la mise à jour de l'affichage des paris une fois qu'un utilisateur crée un pari, ainsi que la mise à jour en temps réel du nombre de coins de l'utilisateur lorsqu'il participe à un pari, mais aussi une visualisation immédiate de sa participation. J'ai également implémenté une gestion des erreurs pour la mise, afin que si l'utilisateur ne saisit pas des nombres ou si la mise qu'il entre dépasse son nombre de coins disponibles, le bouton permettant d'ajouter la participation soit désactivé.
-
Ajout de la route des paris en cours (1h30 min): J'ai repris le code de l'API actuelle en essayant de le prendre en main, en configurant localement toutes les variables d'environnement et la liaison avec pgAdmin4. Ensuite, j'ai refait la route des paris en cours sur laquelle les utilisateurs ont participé.
-
Réalisation de la page des paris en cours (2h): Une fois la route de l'API créée, j'ai réalisé du côté iOS les vues concernant la page des paris en cours et la récupération de ces paris via la route de l'API.
-
Page cadeau du jour (2h): Étant donné que l'API n'était pas encore accessible pour les paris à confirmer, j'ai provisoirement réalisé la page du cadeau quotidien que l'utilisateur va recevoir et qui utilise une route de l'API. J'ai passé pas mal de temps à réfléchir à son mécanisme, tel que le fait que lorsqu'un utilisateur est connecté (que ce soit via l'enregistrement, la connexion ou l'authentification via token), une requête est envoyée, et la page actuelle de l'utilisateur est superposée par les nouvelles informations provenant de cette requête. Mais aussi géré le flux de clics de l'utilisateur pour passer les étapes, avant de revenir à la page initiale
-
Confirmation d'un pari côté iOS (2h): En récupérant la page réalisée par Lucas D, j'ai effectué le binding avec l'API afin de récupérer les paris terminés et en attente d'une réponse, que j'affiche un par un dans la modal. Si la modal se ferme alors qu'il reste des paris à confirmer, le suivant s'affiche, et ainsi de suite. J'ai également bindé la réponse que l'utilisateur a saisie, qui est envoyée à l'API. De plus, j'ai dû revoir considérablement le code côté iOS, car de nombreuses modifications ont été apportées à l'API, telles que le statut du pari à récupérer et le type de pari à envoyer et à récupérer.
Lucas D
-
Correction et avancement de la page des détails d'un bet (1h 30min): J'ai modifié la page pour afficher correctement les elements en respectant les maquettes. J'ai aussi revu certains composant pour les rendres réutilisables dans d'autres bouts de code.
-
Nouvelle page de fin de bet (2h): J'ai intégré la page de fin d'un bet pour que le créateur sélectionne la réponse gagnante. cette page m'a permis également de corrigé l'effet "marquee" qui était codé avec beaucoup d'image mais en écoutant les conseils d'arthur j'ai repris l'image original de la maquette et j'ai réalisé quelque chose de plus propre.
-
Correction de certains composant(1h): En écoutant Emre j'ai compris que certains composants lui faisait perdre du temps car je ne les avait pas codé pour qu'ils puissent etre utilisés dans différents endroit de l'application. j'ai donc repris certains composant en ajoutant des parametres pour les rendres plus dynamiques et répondre a certaines exigences des vues de l'application.
-
Rédaction du rapport de gestion de projet(2h): J'ai commencé la rédaction du rapport que madame GOI nous a demandé lors de notre derniere réunion. J'ai commencé par rédiger les parties sur notre gestion agile en utilisant la méthode SCRUM ainsi que toutes ses modalités. J'ai également rédigé une partie sur la qualité de code attendu dans notre projet en citant sonarQube et nos esperance en terme de qualité.
-
Nous avons presque terminé les vues ( il manque la page de déconnexion/ profil) suite a ca nous allons nous concentré sur l'API car elle nous ralenti parfois car il manque certaines routes qui peuvent prendre du temps pour Lucas car il travaille tout seule sur celle ci.
Lucas E
-
Mise en place de la route pour les daily gift (2h): Une feature est d'offrir un nombre de jeton (entre 15 et 150) quotidiennement aux utilisateurs. Une fois la mise en place de la requête SQL, je me suis aperçu que la fonction d'extension pour exécuter une requête SQL ne peut pas retourner de valeur. J'ai du trouvé un autre moyen et cela m'a pris un peu de temps car il y a peu de documentation dessus.
-
Mise à jour de l'API Kotlin et de certaines dépendance (10 min): L'API de Kotlin (1.4.11) était obsolète, de plus j'avais besoin d'une version plus récente afin d'utiliser les Kotlin modules pour mettre en place le Swagger du projet coté API.
-
Mise en place du Swagger (4h): Afin d'augmenter la lisibilité du code et la documentation du projet API, j'ai du rechercher un moyen d'intégrer Swagger et de générer le Swagger file. J'ai trouvé suite à des recherches un repos Git qui permet de le faire (https://github.com/SMILEY4/ktor-swagger-ui). Actuellement, je met en place les commentaires, en même temps de trouver une solution pour le conteneur docker qui casse l'url, https://codefirst.iut.uca.fr/containers/AllDev-api/swagger-ui ramène vers https://codefirst.iut.uca.fr/swagger-ui/index.html
