Sprint 3 : 10/01 - 24/01
User Stories concernées :
- Écran de status d'un Bet (Android)
- Écran de status d'un Bet (iOS)
- Consulter les informations d'un pari
- Participer a un pari
- Écran historique des Bets (Android)
- Écran historique des Bets (iOS)
- Écran des bets en cours (Android)
- Écran des bets en cours (iOS)
- Écran de victoire (Android)
- Écran de victoire (iOS)
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
-
Modification des fonts (30m): J'ai modifié la manière dont les polices d'écritures sont fournies dans l'application en utilisant GoogleFont.provider, ce qui évite de télécharger les polices directement dans les ressources et est globalement une manière plus élégante de gérer les fonts.
-
Écran de victoire (3h): Implémentation graphique de l'écran de victoire sous Android.
-
Correctif release (1h): La release ne buildais pas, c'étais dû notamment à la librairie android.security.crypto, utilisée pour stocker le token de connexion, qui ne passais pas l'étape de minify. Ajout de règles proguard et mise à jours de versions.
-
Participation et refactoring côté API (2h): J'ai commencé la participation à un pari côté API et j'ai également fait du refactoring du code pour rendre le tout plus ✨ Kotlin Spirit ✨
-
Mock API côté Android (30m): J'ai fait une classe MockAPI qui me permet de tester et de développer même lorsque l'API web est inactive. Je l'ai fait car, pendant que Lucas E intégrais la base de données, je ne pouvais plus faire les requêtes que je voulais. La classe API est injectée via Hilt dans le module correspondant. Il suffit de changer un booléen "mock" pour choisir d'injecter l'API retrofit ou bien l'API mock.
-
Vue de participation (2h): J'ai continué la vue de participation à un pari en faisant notamment la Bottom sheet de participation. L'utilisateur y rentre sa réponse au pari et sa mise puis peux cliquer sur le bouton participer. J'ai également rajouté la liste des participants.
-
Créations de diagrammes (2h30): J'ai fait des diagrammes avec PlantUML afin de mettre à jour notre documentation sur le diagramme de classes du domaine. J'ai également rajouté 2 diagrammes pour représenter les deux modules du client Android. Finalement, j'ai fait un diagramme de séquence décrivant le processus de participation à un Bet.
-
Participation et détail d'un bet (2h): Suite à l'implémentation des routes dans l'API Web, j'ai corrigé et finalisé l'affichage du détail d'un pari ainsi que la participation à celui-ci.
Emre
-
Affichage des bets(3h): J'ai réalisé les fonctions permettant de récupérer les bets via l'API, de les afficher dans la page Home, en liant les informations pour chaque Card. J'ai donc dû découvrir comment récupérer de manière asynchrone les Bets.
-
Utilisation du patron factory(1h): J'ai réalisé une classe abstraite "FactoryBet" ainsi que la classe concrète pour l'API, afin de convertir en JSON les Bet et inversement, de créer selon le type la bonne instance d'un Bet (Binary, Match ou Response).
-
Amélioration de l'API (2h): Avec Arthur, nous avons réalisé de nouvelles routes pour les participations (ajout, suppression), mais aussi pour obtenir l'historique des paris et les paris en cours d'un utilisateur. on a également apporté des correctifs tels que la réduction du nombre de lignes, la définition du nombre de AllCoins par défaut côté serveur plutôt que côté client, l'utilisation d'ID pour l'utilisateur, la conversion des ID en UUID au lieu d'entiers, et l'amélioration globale de la qualité du code. Ces changements visent à ce que l'API réponde pleinement aux besoins des interfaces clients Android et IOS.
-
Correction des dates (30 min) : J'ai dû mettre en œuvre plusieurs façons possibles en Swift pour récupérer les dates de l'API au bon format. Cela a entraîné plusieurs erreurs de compatibilité. Arthur a donc proposé le format "yyyy-MM-dd HH:mm:ss Z" afin de faciliter la récupération pour les applications iOS et Android. De mon côté, j'ai donc dû réadapter la factory pour l'envoi en JSON et la récupération dans le modèle.
-
Binding des composants (4h30min) : Afin d'obtenir un aperçu détaillé, j'ai utilisé la route
/bets/get/{id}pour obtenir les détails précis d'un Bet. Cela a entraîné des modifications dans le diagramme de classe et le modèle du côté iOS et Android. J'ai dû supprimer les classes qui n'étaient plus utilisées, ajouter les classes "BetDetails" et "BetAnswer" ainsi que leurs relations. En collaboration avec Lucas Delanier, qui s'occupait de l'aspect visuel, j'ai ajouté les méthodes et les attributs nécessaires dans le Manager et dans le ViewModel de la page de détail. Puis, j'ai commencé le processus de liaison (binding) que j'ai ensuite donner le relais. L'API n'ayant pas été initialement adaptée pour les BetDetails, j'ai récupéré mon ancien Stub, ajouté plus de données et l'ai mis en conformité avec le nouveau modèle afin de permettre temporairement la liaison. J'ai ensuite créé la factory pour lesBetDetails, utilisé la route une fois celle-ci terminée, et effectué le changement via l'injection pour passer de l'utilisation du Stub à l'utilisation de l'API. -
Réaliser une participation (1 h) : En utilisant l'API, j'ai bind le composant de la modale de participation, afin de pouvoir parier sur un pari.
Lucas D
-
Affichage des details d'un bet(5h): J'ai bien avancé l'affichage des détails d'un bet grace a une modal. Cette page est complexe car son affichage est dynamique en fonction du type de bet ( reponse bool, ou réponse custom). j'ai également trouvé un point de reflexion sur comment afficher cette modal car pour le moment il s'affiche d'un bool sur la page qui contient le bet Or on a besoin de cette logique sur plusieurs pages. Nous allons donc reflechir pour faire un composant parent dont toutes les dérives des bets hériterons pour simplifier cette fonctionnalité.
-
Affichage modal participation(2h): J'ai intégrer cette vue pour permettre a l'utilisateur de participer. Nous avons fini a 90% les vues de l'application ce qui va nous permettre de nous concentrer sur d'autres aspects du code tel que l'API et le model internes aux clients
-
Reflexion et création d'un schéma explicatif des calculs des gains d'un pari(1h): J'ai réfléchi et réalisé la documentation des calculs des gains des users. Nous avons choisi de ne pas générer des coins lors de la répartition des gains mais de redistribuer les coins misé par la totalité des joueurs. Le schéma est disponible dans le wiki.
-
Maquettage de la page de gain quotidien(30min): J'ai maquetté et commencé l'intégration de la page de gain quotidiens des allcoins
Lucas E
-
Modification de la sources de données(4h): J'utilise actuellement KTORM en ORM afin de gérer une base de données externe dans le code, dans notre cas on va utiliser un conteneur en Postgres hébergé sur Runner. La modification de code est actuellement effectif sur la partie User et sera bientôt effectif sur les bets.
-
Recherche de solution pour création de table SQL(2H): En effet, KTORM n'inclus pas l'insertion des tables automatiquement et nécessite à créer une requête SQL pour créer la table. Cependant, il n'est pas si simple de lancer une requête SQL car la documentation est plutôt floue. Une analyse du Github du projet KTORM a du être faite, la solution a été trouvé dans ce fichier. Une fois compris, j'ai crée une fonction d'extension pour réutiliser l’exécution de requête SQL.
-
Résolution des codes smell et mise en place de sonar(2h): Mise en place de sonar pour kotlin, avec des codes smell plûtot basiques(imports inutiles, variables non utilisées...). Cependant, un code smell a relevé que le salt des mots de passe était en clair. J'ai donc ajouté le salt dans les secrets de drone, mais lors de la récupération les
$disparaissent du salt. J'ai essayé de trouver une technique pour protéger la string sur drone mais aucun changement. J'ai donc repris la structure d'un salt BCrypt et j'ai repéré que les$sont situé au même emplacement à chaque génération, d'où la nouvelle fonction addDollarsSecrets dans la class CryptManager -
Mise en place des entités(6h): J'ai mis en place les différentes entités manipulées dans le code, la modification du code a du être faites car je traitais les instances depuis un array. Les classes suivantes sont stockées en base de données sur le runner Postgres : Bet,Participation,Response,User
