Sprint 7 : 27/05 - 09/06
Durée du sprint :
40h
User Stories concernées :
- Ajouter et rechercher des amis (avec pseudo) sous iOS
- Consulter sa liste d'amis et le ranking sous iOS
- Images de profil
- Paris privés
Démo :
S'ajouter mutuellement en amis sur les deux clients, puis se voir apparaître dans notre liste d'amis / ranking Créer un pari privé et s'assurer que seuls les invités y ont accès.
Arthur
-
Recherche d'un utilisateur et ajout d'un ami (3h): J'ai implémenté la route de permettant de rechercher un utilisateur via son pseudo. La recherche utilise la distance de Levenshtein la recherche approximative. J'ai également rajouté le "status d'amitié" au UserDTO. Il s'agit de l'enum suivante :
- NOT_FRIEND : Si les deux utilisateurs ne sont pas amis
- REQUESTED : Si l'utilisateur 1 a demandé l'utilisateur 2 en ami mais que ce dernier ne l'a pas encore accepté.
- FRIEND : Si les deux utilisateurs sont amis.
J'ai aussi fait l'implémentation dans le client Android, qui permet la consultation et la gestion des amis dans l'écran "Amis", et la consultation du classement.
-
Annulation d'un bet (2h): J'ai rajouté côté API le système d'annulation d'un Bet. Ainsi, si le créateur du pari ne l'a pas confirmé après 1 semaine, le pari est considéré comme annulé et les participants sont remboursés. Cela permet d'éviter à une personne de bloquer des coins pendant trop longtemps.
-
Implémentation du pari populaire (2h): J'ai rajouté le bet populaire en cours dans la page des bets au sein du client Android.
-
Demandes d'amis (2h): J'ai fait la route d'API renvoyant l'ensemble des requêtes d'amis entrantes pour un utilisateur donné. J'ai également rajouté la fonctionnalité dans le client Android, permettant d'accepter ou de décliner ladite demande d'ami.
-
Correction de la recherche (30min): Suite au rendez-vous, j'ai corrigé la recherche d'un utilisateur. À présent, les utilisateurs sont filtrés par rapport à une distance maximale. Cette distance est égale à la moitié de la taille de la recherche. Ainsi sur une recherche de 4 caractères, 2 caractères de différence maximum sont autorisés. La recherche est ensuite triée de la distance la plus faible à la plus grande. J'ai également utilisé la fonction levenshtein_less_equal de postgres, bien plus performante dans notre cas, à la place de la fonction levenshtein.
-
Correction de la confirmation de Bet sous iOS (30min): J'ai corrigé l'envoi de réponse d'un Bet dans le client iOS. Côté API, nous attendions directement la String sans formattage. Le client iOS renvoyait un objet json { result: "Yes" }. Cela était une ancienne manière de faire, que l'API n'accepte plus. L'erreur vient donc d'un manque de communication, car le changement n'a pas été communiqué aux personnes s'occupant du client iOS.
-
Création d'un Bet custom sous Android (1h): J'ai fait les composants permettant la création d'un pari avec des réponses personnalisées sous Android. Cette fonctionnalité était déjà prévue dans l'API, mais n'était pas encore implémentée dans le client Android.
Emre
-
Recherche pour ajouter un ami et affichage du classement côté iOS (3h): J'ai réalisé les fonctions pour la recherche d'amis. Étant donné qu'il n'y avait pas de composant convaincant en swiftUI pour la recherche, j'ai décidé de faire via un Input ma propre barre de recherche, de façon qu'à chaque lettre entrée une requête soit envoyée à l'API et que la liste des utilisateurs soit rafraîchie. Si la barre de recherche est vide, cela réaffiche la liste d'amis actuelle. En implémentant l'envoi de la demande d'amis à une personne, pour éviter l'exploitation excessive de l'API, le statut de l'ami est changé dans le modèle au lieu de rafraîchir et de récupérer de nouveau la liste d'amis après la demande, ainsi que lors de la suppression d'un ami ou d'une demande d'amis. Comme pour l'affichage de la liste d'amis, je récupère et trie les amis de l'utilisateur connecté à l'application selon leur nombre d'AllCoins, pour les afficher dans la page Ranking.
-
Complétion du README pour installer l'App côté iOS (30min): Pour les personnes voulant avoir l'application sur un émulateur ou leurs appareils Apple, j'ai réalisé un court tutoriel dans le README du dépôt pour expliquer les étapes et outils nécessaires.
-
Correction du bug de la participation sous iOS (30min): J'ai corrigé un bug d'affichage dans le client iOS qui dupliquait les participations lorsque deux personnes différentes participaient au même pari. Ce bug faisait que la première participation écrasait la deuxième dans l'affichage.
-
Invitations des amis dans un bet privé sous iOS (2h): Dans la page de création d'un bet, j'ai implémenté le choix entre créer un pari privé ou public, ainsi que la sélection d'amis à inviter dans le cas où l'utilisateur souhaite que le pari soit privé. J'ai donc dû récupérer la liste d'amis au chargement de la page, stocker les IDs des utilisateurs sélectionnés ainsi que le statut du bet (privé ou public) pour l'envoyer à l'API.
-
Liaison du Paris Populaire avec l'API sous iOS (1h): À partir de la coquille du composant visuel TrendingComponent réalisée au départ de l'application, j'ai réalisé le binding en utilisant la nouvelle route /bets/popular de l'API.
-
Affichage des paris gagnés de l'utilisateur sous iOS (2h30): La vue des paris gagnés étant déjà réalisée dès le départ, j'ai dû de mon côté réaliser les fonctions pour récupérer les paris gagnés renvoyés par l'API, implémenter les nouvelles classes (BetResultDetail et BetResult), ainsi que faire la liaison de tous les textes qui étaient actuellement en dur avec les données reçues de l'API. Cette tâche m'a pris pas mal de temps dû au fait que le processus pour tester et récupérer des bets gagnés est très long (nécessite de créer deux utilisateurs, qu'un crée un pari, que l'autre y participe, attendre la fin du pari, entrer la réponse, revenir sur la page ...). Pour une question d'efficacité, il aurait été préférable que cette tâche soit réalisée plus tôt en parallèle avec Android (qui a été réalisée 2 sprints plus tôt) pour tester et avancer plus rapidement.
Lucas D
-
Maquette et intégration des indications de listes vides (1h): J'ai ajouté une maquette et intégré des indications pour informer l'utilisateur qu'une liste devrait être affichée mais qu'elle est actuellement vide, avec des informations pour la remplir.
-
Travail sur les requêtes d'amis (2h): J'ai ajouté la fonctionnalité de requête d'amis dans les vues en affichant 2 pages accessibles en séparant les amis et les requêtes d'amis.
-
Gérer les bugs de chargements de certains bets (1h): Lors de nos tests nous avons vus que certains bets on un problème de chargement. Par exemple, sur une ancienne version il était possible de selectionner le type "bet sportif" qui n'est pas encore géré ce qui a créé un bet qui ne charge pas. Il a donc fallu ajouter une verification dans la vue pour afficher un message d'erreur si les données sont pas chargées.
-
Bets personnalisés(2h): J'ai modifié nos composants pour prendre en charge les bets custom qui n'ont pas le meme affichage dans la bet detail view. La ligne est donc maintenant décomposée en plusieurs lignes pour chaque réponse comme prévue sur les maquettes.
-
Gérer l'historique des participations(2h): J'ai du modifier du code au niveau de l'historique des paris car nous récupérions des betDetails alors que ce sont des BetResultDetail qui n'ont pas les memes attributs. Cela a permis de régler l'historique et d'afficher les composants avec le status gagné ou perdu et les coins misés.
-
Travail sur les images de profils(1h30): J'ai modifié le composants des photo de profil pour afficher soit l'image de l'user soit les 2 premieres lettre de son prénom.
Lucas E
-
Sauvegarde des images de profil des utilisateurs en base de données (6h): Le code binaire des images de profil des utilisateurs est stocké dans une base de données. Lorsqu'une requête GET est effectuée sur une image, celle-ci est reconstituée et stockée dans le conteneur de l'API. Pour récupérer une image, il suffit de faire une requête GET sur 'https://codefirst.iut.uca.fr/containers/AllDev-api/users/images/0a34c6f9-10de-430c-888b-80e1bbce2a5a', où l'UUID est celui de l'utilisateur dont on souhaite récupérer l'image.
-
Mise en place de logs (2h): Des logs ont été rajouté pour remplacer ceux déjà mit en place avec KTOR (qui sont particulièrement illisibles).
-
Route pour récupérer des users d'un bet (30 min): Les interfaces IOS/Android ont besoin de prévisualiser les images des utilisateurs dans la liste des bets. Il a donc fallu faire une route qui récupère 4 users d'une liste de participant.
-
Gestion des codes smells (30 min): Les codes smells étaient simple à résoudre sauf un qui était pour la complexité d'un algorithme. Les autres codes smells étaient pour de la répétition de String, j'ai donc rajouter des constantes dans l'objet ApiMessage.
-
Ajout des bets privés (2h30): Pour la gestion des bets privés, il a fallu construire une nouvelle table qui met en relation un id d'user et un id de bet (invitation). Il a fallu aussi gérer le fait que l'user créateur pouvait voir ces propres bet, sauf qu'on stock uniquement son username pour simplifier les vues, dorrénavant c'est l'id de l'utilisateur qui est stocké en base de données. J'ai donc du modifié la création du userdto en convertissant un id en username pour ne pas impacter les clients.
-
Test de l’API (1h): Debut de tests avec la base de données afin de confirmer la conformité des classes et du schéma de la base de données.
