Rapports hebdomadaires

Semaine 1

2 mai 2023

Première rencontre avec Lena, Zoe et Jian Xin sur le campus. Nous avons testé l’application et visité les bureaux. Pour le développement Android, le mandat de cette session consiste à régler les bogues afin de pouvoir mettre sur le marché l’application écrite avec JavaScript (framework Ionic) : la version sur Google Play est en Kotlin.

En consultant les rapports hebdomadaires et le rapport final de Gaspard, j’ai vu que la transaction de Kotlin vers Ionic, JavaScript et Vue.js a été faite. Il ne reste qu’à régler quelques problèmes tels que l’implémentation des badges et des filtres sur la carte/la liste des œuvres. Par ses recommandations, j’ai consulté les documentations à propos de Ionic et Vue.js pour me familiariser avec le langage.

Semaine 2

10 mai 2023

Premier contact avec le prédécesseur de développement Android, Gaspard. Il m’a présenté le code, décrit comment tester l’application sur bureau et sur Google Play console, mentionné les problèmes à régler dans issues et recommandé des environnements à utiliser.

Pour cette semaine, je me suis familiarisé avec le code, testé l’application sur bureau et écrit de la documentation. Pour ce faire, j’ai téléchargé les dépendances telles que Ionic, l’IDE Webstorm ainsi que le plug-in Sonarlint qui permet de garder le code en qualité. Avec les guidances de Gaspard, j’ai pu tester l’application en commentant la partie du code demandant la permission pour la caméra et la localisation. Pour la documentation, nous avons décidé de le faire sur la branch main.

Semaine 3

15 mai

Réunion en présentiel avec Léna, Zoe et Jian Xin où nous avons fait un tour de table de ce que nous avons appris à ce jour.

Pour cette semaine, il est essentiel de lire « Get api/v3/lastUpdated[Artworks/Places/Heritages] », car il aura bientôt de nouvelles données qui entreront dans le système. Ce serait alors intéressant que les personnes ayant déjà l’appli puissent y avoir accès.

La semaine du 5 juin, Léna rencontrera de nouveaux testeurs. Il serait donc important que, dès le 29 mai (à peu près), l’application Ionic/Vue.js puisse être fonctionnelle et déployer sur le Google Play Store.

La dernière semaine de juin, il aura une présentation de l’application auprès d’une audience. À partir du 15 juin environ, l’application devrait très bien fonctionner.

De ce fait, d’ici là, il faudrait hiérarchiser ce qui est à implémenter. En gardant en mémoire les utilisateurs et les fonctionnalités principales de Mona, implémentez les badges, les mises à jour automatiques et des filtres devraient être la priorité.

Une rencontre avec la graphiste de l’équipe à propos, notamment du UI/UX des filtres, sera planifiée bientôt.


Update
Finalement, nous avons décidé de privilégier ses tâches: Tâches à prioriser Pour l’issue 11, avec les conseils de Gaspard, j’ai utilisé un watcher afin de mettre à jour la carte. Cette vidéo m’a beaucoup aidé. Le focus fonctionne, mais la carte n’est pas render.

Semaine 4

22 mai

La réunion a servi à diviser les tâches entre Gaspard et moi. Je vais continuer avec les tâches ci-dessus. Il fera les issues 7 (implémenter les badges) et 9 (miniature).

Nous avons également discuté du code en lien avec l’issue 11 : il a réussi à render la carte. Il fallait la « mounted ».

J’ai trouvé que faire un code review était fort utile. Comme je ne suis pas tout à fait familière avec l'architecture de mona-mobile, avoir ses conseils sur les différentes méthodes existantes à employer et le mélange d’idée pour aboutir à une solution s’avère efficace. Ainsi, pour les prochaines issues, nous allons procéder de la même façon.

Update

Léna a dit qu'il aura des changements concernant les filtres donc on pourrait repousser cette fonctionnalité à la prochaine mise à jour. Je me suis donc concentrée sur l’issue 8. Pour les faire apparaitre, j’ai décidé d’appeler une fonction qui retourne la valeur directement dans le template, car si j’utilise un data binding avec {{}} et que je les retourne dans la section data, les données ne s’affichent pas une fois que la photo de la découverte est prise. En utilisant un data binding, il fallait retourner à la liste, sélectionner la fiche pour que les commentaires et la note s’apparaissent.

Semaine 5

29 mai

Pour cette semaine, il serait bien de pouvoir

Pour que les personnes aux îles de la Madeleine puissent tester l’application (pas celui écrit en Kotlin), il serait bien que ces tâches soient faites pour le 2 juin. Cette version sera alors mise dans le internal testing et l’open testing afin d’avoir le plus de rétroaction possible. Elle doit être assez stable pour les différents types d’utilisateurs ne perdent pas leurs données aux updates ou au premier téléchargement. Si jamais je rencontre des points à améliorer au point de vue UI/UX, les écrire dans une liste.

Sinon, entre-temps, vérifier comment les données sont structurées avec Ionic afin de pouvoir les mettre à jour à partir d’une certaine date et si le changement de port est possible pour avertir les gens du serveur.

Update

Je voulais mettre la version ayant la localisation des découvertes à partir des découvertes et l’affichage des notes/commentaires dans le internal testing, mais j’ai eu de la difficulté lorsque je faisais "Ionic cap build android" : ça ne trouvait pas mon Android Studio. Le code de Mona est sur Ubuntu (WSL2) alors qu’Android Studio, sur Windows. J’ai essayé de changer l’ « Environment variable» en faisant echo export CAPACITOR_ANDROID_STUDIO_PATH="/mnt/c/[path de Android Studio]" >> ~/.bashrc Par contre, ça n’ouvrait pas automatique Android Studio. Lorsque je l’ouvrais manuellement, il avait d’autres problèmes. Finalement, pour régler la situation, j’ai migré le code sur Windows.

Par la suite, Gaspard avait déjà implémenté une fonction qui met à jour les données en vérifiant si depuis la dernière date de mise à jour, il y a de nouvelles données qui se sont ajoutées. Je n’ai donc pas besoin de l’implémenter.

Dans l’éventualité que les tests doivent être roulés sur un port spécifique, il devrait être possible de le changer.

Pour cette semaine, j’ai réussi à enlever les informations « inconnues » des fiches descriptives et à afficher la distance dans la liste des découvertes. J’ai fait une première release dans internal testing. En mettant à jour l’application, les images pour les patrimoines ne s’affichaient pas et les permissions ont été enlevées. Léna voulait également que les distances soient en m lorsqu’elles sont moins de 1 km. Elles doivent être arrondies à l’unité près. Après avoir corrigé les erreurs, j’ai donc fait une autre release dans internal et open testing. Comme je voulais faire des tests d’utilisabilité dans la semaine suivante, open testing est un moyen facile et rapide pour les testeurs d’essayer la version Ionic. Il est bien important de mettre de remplir le champ « Feedback URL or email address », cocher « unlimited testers » et confirmer « resume track » pour que la version bêta s’affiche dans le Google play store au public.

Finalement, je n’ai pas fini d’implémenter le filtre, car j’avais la difficulté de faire afficher la liste des découvertes par distance puis par ordre alphabétique. J’ai décidé d’utilisé ion modal à la place d’ion grid comme cela permettait une plus grande flexibilité. Avec ion modal, le filtre est automatiquement fermé lorsque le modal est réduit à 0% par l’utilisateur.

Semaine 6

5 juin

Aujourd’hui, nous avons rencontré Julie et Barbara. Pendant la rencontre Zoom, nous avons parlé notamment de changer la page découverte du jour pour la page découverte la plus proche.

Update

J’ai fait 5 tests d’utilisabilité cette semaine. Voici les conclusions : Résultats des 5 tests d'utilisabilité Pour plus de détails de chaque test d’utilisabilité, les informations se retrouvent dans ce Google Doc.

Semaine 7

12 juin

Nous avons rencontré Guy Lapalme aujourd’hui pour nous présenter, discuter de ce que nous avons appris et mentionner nos objectifs.

Pour ce qui est de l’application Android, il faudrait le rendre public bientôt. Afficher la liste par distance, implémenter les badges et changer la première page à la page carte doivent être faites le plus tôt possible. Comme l’application permet présentement de prendre une seule photo des découvertes et qu’ils existent des anciens utilisateurs qui ont de multiples photos de la même découverte, un problème surviendra peut-être lors des mises à jour. Il faudrait trouver une solution.

Il faudrait également vérifier si les photos des testeurs la semaine dernière s’affichent bien dans le serveur.

Éventuellement, pour les images dans la collection, elles devraient s’afficher en plein d’écrans lorsque les utilisateurs cliquent dessus.

Update

Les photos des testeurs sont présentes dans le serveur, mais ne s’affichent pas comme il le faut.

Comme Gaspard s’occupe des badges, il va implémenter les fonctions qui vont peupler ce database, le temps que le serveur implémente le service de télécharger les assets des badges. Il a également changé la première page à la page carte. Sinon, j’ai eu de la difficulté à trier la liste par distance. Il avait un gros problème de performance lorsque j’essayais de calculer la distance lors de la population des découvertes. Comme alternative, je me suis inspirée de ce Gaspard avait fait pour trier la liste d’A-Z.

Semaine 8

19 juin

Après avoir discuté avec Lena, il n’est pas nécessaire de mettre à jour en direct la distance lorsque l’utilisateur se déplace. Un bouton refresh suffit pour l’utilisateur qui veut connaître la distance des découvertes depuis sa nouvelle localisation.

Update

Les distances de la liste des découvertes peuvent maintenant se mettre à jour à l’aide d’un bouton. Cette version est sur internal testing. Comme la liste était déjà render au mounted, j’ai utilisé :key pour re-render la liste. En bref, un component reste tel quel une fois qu’elle est mounted. Pour qu’elle puisse être re-render, il existe différent moyen. La meilleure solution est d’utiliser :key. Lorsque la valeur de :key est modifiée, vuejs est obligé de re-render le component. Cette découverte aidera grandement pour créer de nouvelles listes selon les filtres.

Pour les fiches descriptives, seuls les objets artwork contiennent la propriété « accessibilité ». Comme les données sont mises à jour d’après la dernière date de mise à jour, les artworks déjà collectés ont un champ undefined pour accessibilité. Il faudrait faire une mise à jour régulière une seule fois pour tous les utilisateurs.

Semaine 9

29 juin

Je n’ai pu aller à la rencontre à cause d’un empêchement.

Update

La version Ionic a été sortie en prod. Lors du premier essai, il avait une erreur java.lang.SecurityException: No active admin ComponentInfo{com.google.android.apps.mtaas.deviceadmin/com.google.android.apps.mtaas.deviceadmin.DeviceAdminReceiver}. Au 2e essai, cette erreur n’est plus revenue. Elle devrait être résolue tout de même dans le futur.

Cette semaine, je m’attaque au filtre. L’utilisateur peut maintenant trier par distance ou AZ. J’ai utilisé v-model, inspiré de la solution ici, pour connaître le choix sélectionné parmi les ion-radio.

En essayant d’implémenter le filtre par œuvres, patrimoines et lieux, j’ai rencontré un problème de performance. La liste des découvertes triées par distance et AZ sont générés lors du loading. Ça ne ralentit donc pas l’application. Par contre, quand l’utilisateur filtre, la liste des découvertes est itérée au moment de la sélection. Comme la quantité est énorme. Il faudrait trouver un moyen d’accomplir cette tâche efficacement.

Semaine 10

Pour filtrer les découvertes, à la place d’utiliser une boucle for, j’ai utilisé la méthode filter propre à JavaScript. J’ai pensé à utiliser une librairie, mais éventuellement, les découvertes ne dépasseront pas 300 000. Côté performance, filter est assez rapide.

Pour ce qui est du css, il est presque complet. J’utilise présentement document.getElementByID() pour changer le css. De ce fait, modal ne se souvient pas de la sélection si je le réouvre. Comme une découverte ne peut pas appartenir à plus de deux catégories, il faudrait utiliser ion radio group.

Cette semaine, j’ai lu également le guide d’accessibilité d’Ionic . J’ai appris qu’il existait, en plus d’aria label et alt, des techniques tel qu’aria hidden et des ccs fonctionnalités permettant d’améliorer le contraste et réduire le mouvement.

J’ai cherché comment rendre le tutoriel interactif, car, actuellement, le tutoriel constitue d’images avec beaucoup de texte. Ion-popover semblerait être la solution.

Semaine 11

10 juillet

La récupération de mot de passe via email devrait bientôt être prête. La prochaine étape serait donc d’implémenter une section dans paramètre permettant aux utilisateurs d’ajouter leur courriel. Dans cette partie, la personne pourrait également modifier leur nom d’utilisateur et leur mot de passe. Je vais poursuivre avec les badges, écrire un guide d’accessibilité sur le répertoire et commencer d’écrire le code pour le tutoriel interactif. D’ici la fin de session, le but est de faire un dernier push dans prod.

Update

J’ai trouvé un bug dans le code d’implémentation des filtres. Pour améliorer la performance, seulement 50 découvertes sont emmagasinées dans un array au départ. Le nombre augmente seulement lorsque l’utilisateur souhaite en voir plus. Lorsqu’il ou elle souhaite filtrer par œuvre, héritage ou place, rien ne peut apparaitre, car dans les 50 découvertes, il n’en a pas. Je crois avoir réglé ceux problèmes en créant un array contenant tous les découvertes avant le mounted de la vue.

Semaine 12

17 juillet

Pendant la réunion, nous avons décidé que la présentation se déroulera le 21 août. Comme objectif pour la fin de session, j’espère compléter l’implantation de la page Badges et Paramètres de connexion. J’aimerai également m’accorder du temps pour nettoyer le code.

Update

Certains components d’Ionic doivent être emballé par un div tel que ionic-label pour le css soit appliqué sur l’élément. Bien qu’en testant sur le navigateur le css semble être affecté, ce n’est pas le cas dans l’application dans le téléphone. J’ai découvert cette erreur lorsque le margin et padding ajouté n’apparaissaient pas dans l’app.

J’ai réussi à créer un fichier json qui indiquera si la base de données doit être peuplée auprès du serveur uniquement une seule fois. Ce document sera fort utile dans le futur lorsque nous souhaiterons, par exemple, ajouter de nouvelles propriétés aux découvertes. Le champ accessibilité s’affiche donc maintenant dans les fiches descriptives. Les badges sont aussi complètement réinitialisés.

J’ai créé un prototype très basique de la page Badge et Paramètres de connexion. Il restera à le polir et à écrire la logique permettant de les faire fonctionner.

Semaine 13

24 juillet

Comme d’habitude, nous avons fait un tour de table. Cette semaine, je dois mettre la version Android avec filtre sur internal testing.

Update

En faisant la page « Paramètre de connexion », ion-input n’avait pas la même apparence que celui documenté dans la documentation officielle d’Ionic. En cherchant un peu, la version Ionic utilisée présentement est la 6e alors que les documentations suivent Ionic 7. J’ai donc mis à jour toutes les dépendances dans la même occasion. Dans le design dans Figma, le mot de passe est affiché. Cela implique que dans l’application, il faudrait emmagasiner cette valeur quelque part. Pour des raisons de sécurité, je ne crois pas que cela devrait être fait. J’ai donc modifié un peu le design que je vais présenter à la réunion la semaine prochaine.

Lorsque j’ai changé de branche pour continuer à travailler sur les badges, j’ai remarqué que la mise en page est différente. Cela est dû aux mises à jour des dépendances que j’ai faites dans la branche Paramètre de connexion. Je ne comprends pas pourquoi les nouvelles versions de dépendances n’ont pas été isolées dans la branche paramètre.

En revenant à la branche main, j’ai eu le même problème. En un build dans Android studio, j’ai donc eu des erreurs telles que celui-ci Execution failed for task ':capacitor-cordova-android-plugins:compileReleaseJavaWithJavac'. > error: invalid source release: 17

J’ai donc malheureusement pas peu push en internal testing

Semaine 14

31 juillet

Pour afficher plus de détails sur les badges, une page tel que dans IOS s’ouvrira à chaque fois que l’utilisateur clique sur un. Son titre devrait être déplacé en haut (avant l’image) pour la version Android.

Update

Il est crucial de ne pas mettre à jour toutes les dépences tels que j’ai fait, car cela créera beaucoup d’erreurs. Si jamais cela arrive, pour régler le problème, il faudra copie-coller dans le package.json les versions de dépendances dans package-lock.json. Ensuitre, entre la commande « npm update » dans le terminal.

Pour les badges, il reste à améliorer la mise en page lorsque son titre est trop long. La page est donc à 90% fini. La logique derrière est complétée. Par contre, je n’ai pas trouvé comment vérifier si les utilisateurs ont obtenu les badges Université de Montréal et Ville de Laval, car ils ne correspondent à aucune propriété des découvertes. La page de détails sur les badges est en cours de construction. Je l’ai mis en pause, car j’ai découvert des erreurs qui surviennent au build qui ne sont pas présents au dev.

Semaine 15

7 août

Lena m’a informé qu’il faut vérifier la propriété « owner » des découvertes afin de savoir si l’utilisateur a obtenu les badges Université de Montréal et Ville de Laval.

Update

L’application crash lors de l’ouverture en raison d’un pointeur nul pour la propriété path lors de la lecture d’un fichier. À la place de lui passer une variable qui contient le chemin, j’ai assigné à path un string. Le problème a pu être ainsi résolu.

J’ai corrigé la mise en page de badges. Display : flex désactive la propriété width. Les conteneurs ont donc différentes tailles. À la place de width, il faut remplacer par la propriété min-width.

J’ai ajouté les badges manquants à la page. Pour les œuvres de l’Université de Montréal, la propriété owner renvoie la valeur de Montréal sans accent alors que le titre du badge en contient un. Je ne peux donc pas extraire la propriété titre et owner de ces objets pour les comparer. Il a fallu le hardcoder.