Ming-Xia Delvas
Rapport hebdomadaire
Semaine 1 : 29 août - 4 septembre
La première semaine, j'ai eu une rencontre avec Lena et le reste de l'équipe. Elle nous a expliqué le fonctionnement de l'application, quels outils/plateforme qu'on allait utiliser. J'ai installé l'application sur mon cellulaire et j'ai regardé les options qu'il y avait. J'aie lu les rapports que Dina avait écrit la session précédente dans le but de me mettre à jour par rapport au développement de l'application. Par la suite, je l'ai contacté pour organiser une rencontre pour qu'elle puisse m'expliquer les procédures d'installation des logiciels.
Semaine 2 : 5 septembre - 11 septembre
Suite à la première rencontre avec Dina, elle m'a expliqué le code, quelles tâches je devrais faire au cours de la session et m'a demandé de faire une minie formation sur Kotlin puisque c'était la première fois que j'utilise se langage. Par la suite, j'ai essayé d'éxécuter l'application, mais j'ai eu des problèmes de localisation SDK. J'ai pu régler le problème, mais un autre problème est survenu et il m'était impossible de voir l'application sur l'émulateur. Il a fallu que j'aille lire la documentation de Gradle pour comprendre d'ou venait le problème. J'ai aussi commencé à faire ma page web, installer WinSPC et j'ai du revoir quelques notions par rapport au langage HTML.
Voici les liens qui ont été utiles pour ma formation Kotlin:
Voici les liens qui ont été utiles pour ma formation Android:
Semaine 3 : 12 septembre - 18 septembre
J'ai terminé ma formation avec Kotlin et Android Studio. Durant la semaine, on a eu une rencontre avec toute l'équipe pour faire une mise à jour des bugs qu'il y avait par rapport à l'application. J'ai regardé les "issues" sur github et contacté les personnes qui les avaient écrit dans le but de savoir quels problèmes avaient été réglé ou non. J'ai filtré les problèmes selon l'ordre de priorité et j'ai décidé que de commencer par le problème de téléchargement des photos dans la liste des oeuvres, car dans la version Android, on a un problème de lenteur. Je n'ai pas encore pu résoudre le problème puisque j'ai encore un peu de difficulté à bien comprendre le code. J'ai contacté la personne qui avait soulevé ce problème et j'attends ça réponse pour avoir plus d'information. Après, j'ai commencé à regarder/faire des recherches sur comment faire l'icône de localisation des oeuvres d'art comme la version iOS.
Semaine 4 : 19 septembre - 25 septembre
Durant la semaine, Thomas et moi avons regardé comment le serveur allait réagir quand on utilisait l'application et finalement le problème de lenteur a été réglé. J'ai fait des recherches sur l'architecture MVVM dans le but de comprendre comment faire une bonne architecture pour une application mobile et comment on pourrait améliorer notre architecture pour que ça soit plus efficace lors de l'utilisation. Aussi, j'ai essayé de régler quelques bugs telque le problème de localisation des oeuvres. Toutefois, j'avais trouvé une solution avec GoogleMap, mais Lena m'a dit qu'elle préférait utiliser seulement des open source, donc je n'ai pas pu utiliser cette solution. Ensuite, j'ai remarqué qu'il y avait de quoi de similaire dans la map oeuvre du jour, c'est-à-dire quand on clique sur l'icone position de oeuvre du jour l'icone vide apparait. Ainsi, j'ai essayé de comprendre le code et j'ai pu avoir une piste sur comment implémenter l'icone pour afficher le nom des oeuvres dans la map. Toutefois, il me reste à regarder comment bien l'implémenter, car pour le moment j'ai des problèmes avec le UI. J'ai aussi regardé le bug concernant l'affichage des badges selon les quartiers. Pour ça, il a fallu que je regarde chaque code concernant les badges et que je comprenne d'ou venait le bug. Malheuresement,je n'ai pas pu le régler, car ça m'a pris énormément de temps à comprendre tout les codes. J'ai participé à une activité fait par Mona et j'ai pu en apprendre plus sur les oeuvres de Montréal et sur comment l'application fonctionnait ainsi que découvrir de nouveaux bugs dans la version Android.
Voici les liens qui ont été utiles pour ma formation MVVM:
Semaine 5 : 26 septembre - 2 octobre
Après avoir une la rencontre hebdomadaire avec l'équipe Mona, cela m'a permis de mieux m'enligner sur comment régler le bug des icones de localisation des oeuvres dans la map. En effet, Lena m'avait proposé de faire un schéma qui résumerait ce que je voudrais dans chaque classe et c'est quoi les liens entre elles. Ainsi, cette idée m'a énormément aidé, car j'ai pu faire un design de l'architecture du code des maps. Le but est de décomposer le code de MapFragment. J'ai fait 2 classes dont une est LocationFragment qui est le parent de la classe PinFragment. Par la suite, j'ajouterais Oeuvre du jour, car pour le moment la Map des oeuvres et Map de oeuvre du jour sont 2 clases séparés et le but est d'utiliser la hiérachie des classes.
Voici une image du brouillon que j'ai fais et que je me suis inspirée :
.
Semaine 6 : 3 octobre - 9 octobre
J'au eu un problème avec Android Studio, je n'étais pu capable de connecter l'app avec un émulateur et j'avais un problème avec gradle. J'avais éssayé de régler le problème, mais au final ça ajoutait 20 000 fichiers dans le projet. J'avais essayé de tout supprimer, mais mon ordinateur surchauffait et Android Studio se fermait automatiquement. Ainsi, je n'ai pas pu push sur github les modifications que j'avais fait par rapport au MapFragment et j'ai du désintaller Android Studio et re cloner le projet Mona. Après avoir re installer le logiciel et le projet tout a pu fonctionner et j'ai mis à jour les tutoriels de Mona. J'ai aussi eu un rdvs avec Dina pour parler des bugs dont je faisais face. On a essayé de debugger mon code mais on s'est rendu compte que modifier une architecture sur un code déjà fait peut un 'challenge' un peu trop difficile pour moi. Ainsi, on a pensé à une nouvelle astuce qui était de faire un fichier xml et à partir du fichier appeller une fonction retournant le nom de l'oeuvre et l'artiste comme ça on aura déjà l'implémentation et la seule chose à modifier serait le visuel de l'icone. J'ai aussi commencé à regarder comment implémenter le dark mode.
Semaine 7 : 10 octobre - 16 octobre
J'ai pas mis beaucoup de temps en raison de la mi session et des projets/exams à faire.
Semaine 8 : 17 octobre - 23 octobre
J'ai fait plusieurs recherches sur comment rendre une image cliquable à partir de l'icone de localisation de l'oeuvre d'art. Un des gros
incovénient est qu'il existe plusieurs exemples sur Internet, mais la majorité utilise GoogleMap, donc leur implémentation est différente
et font appel à différentes fonctions qui n'existe pas dans MapView. Par la suite, j'ai regardé des exemples avec MapStreetSource, car leur
implémentation est assez similaire à ce qu'on a, mais ce que j'ai trouvé c'était des exemples/documentatitons qui datait d'il y a 10 ans,
donc ça faisait en sorte que les fonctions n'existent plus ou on changé de type de retour. Aussi à cause que les codes étaient super gros
pour retourner seulement une bulle et les utilisait Bitmap et je n'étais pas sur de bien comprendre Bitmap ou sinon on utilise des fonctions
dont nous on n'a pas ex: les getter et setter. J'avais pensé de peut-être des getter et setter ce qui pourrait à la fois rendre la tâche plus
difficile, car il faut nettoyer le code et ça rendrait la tâche à la fois facile pour avoir accès aux informations des oeuvres. Mais encore
on revient au problème d'architecture.Sinon j'avais vu qu'on pouvait le faire avec la classe Dialogue mais ça va afficher une 'boite de message'
et non un popup comme on veut.
Ensuite, après avoir regardé divers exemples/documentations, j'ai essayé de faire une fonction 'addMarker' qui prend un paramètre
un OverlayItem, j'appel cette fonction dans la déclaration de la valeur overlayObjet. Cette valeur permet de retourner vrai lorsque
l'icone de tel oeuvre est appelé. Ensuite, j'associes les informations données (le titre de l'oeuvre) à la bulle_map (xml) et j'ai
créé une fonction showMarker() qui permet d'afficher ou de fermer la map_bubble quand on clique dessus. Cependant j'ai remarqué que
ça ne fonctionne pas, à cause que je devrais appeler l'attribut de ma classe Marker() dans la fonction onCreateView pour que ça puisse
s'afficher. Sauf que le problème c'est qu'en déclarant dans la fonction onCreateView, aucune "bubble" ne s'affiche pas. Ceci est
peut-être du au fait que je ne présice pas la localisation de l'oeuvre.
J'ai essayé d'écrire une fonction qui retourne la longitude et latitude de n'importe quelle oeuvre pour avoir accès à coordonnées
GeoPoint(x,y) et à partir de cela faire un appel sur l'oeuvre même pour avoir accès aux données (titre), mais encore sans succès
à cause que mon bug était que ça n'affichait rien. Aussi, j'avais du mal à relié les pins avec l'image xml (bubble_pop) que j'ai fait
puisque c'est la pin qui est cliquable et non la bulle. J'ai aussi lu la documentation et l'implémentation de OverlayItem, MapView,
Marker pour voir s'il n'y avait pas de fonctions qui peuvent pertinantes pour nous. J'en est trouvé mais ce qui me complie un peu
plus la tâche c'est ce que les fonctions que je trouvais qui pouvait être intéressantes prennent en paramètre attributs différents
de nous. Donc, il fallait que je pense à quelle genre de méthode que je pourrais faire et qui permettrait de faire appel aux fonctions
déjà établie dans les classes nommées plus haut.
En fait le problème est que c'est difficile de venir debbuger des codes qui ne vient pas de toi, après concernant l'architecture, l'autre
problème est qu'il y a plusieurs appel à d'autres classes dont je ne suis pas sur de bien comprendre la différence, exemple la classe Overlay
vs OverlayItem, aussi pourquoi la classe Toast fonctionne quand on appuie sur une pin mais la Marker non. Après il y a le problème de manque
d'accès aux attributs (avoir des getter/setters) pour les localisations des oeuvres. Exemple, pour avoir les points de locailisation de
l'oeuvre, les points déclaré dans une valeur qui déclare une fonction à l'intérieur et qui fait le calculs des GéoPoints. Il y a un
locationCallback, mais d'après ce que j'ai compris du code c'était pour le user et non les oeuvres. Cependant, j'ai vu qu'on fait souvent
appel oeuvreList pour avoir accès aux coordonnés. Donc, je me demande si ça serait mieux de faire des getter et setter, mais ça reste à voir.
J'ai essayé d'écrire une fonction pour que lorsque l'utilisateur ouvre l'oeuvre du jour il puisse avoir une oeuvre non collectée.
On a eu une journée de rencontre et durant la séance nous avons travaillé sur le site web de Mona.
Semaine 9 : 24 octobre - 30 octobre
Puisque mon idée de Marker ne fonctionnait pas, j'ai essayé de continuer avec le Toast. Ainsi, j'ai implémenter l'image de la map_bubble
avec le titre de l'oeuvre lorsqu'on clique sur une pine. Ça a fonctionné, mais la bulle appararaissait au centre de l'écran et non en
fonction des pines. Ainsi, j'avais proposé à Lena d'implémenter une fonction qui déterminent les coordonnées de l'endroit ou la personne
à touché la pine sur l'écran et à partir de cela afficher la bulle. Lena n'était convaincu en raison qu'il pourrait avoir des complications
en raison d'avoir trop de Overlay qui se supperposent.Puisque c'est un toast et qu'on ne peut pas cliquer sur le popup et aussi on ne peut
pas afficher le popup au bonne coordonnées. À cause de cela, j'ai regardé si ce faisable de rendre l'image clickable et insérer un texte
dans l'image au lieu d'un toast. J'ai aussi regardé si c'était possible d'implémenter des fonctions qui rendent le toast clickable et oui
ce l'est mais il faut déclarer une variable qui appartient à la classe WindowManager et jouer avec les LayoutParams. J'ai aussi regardé
l'option window popup qui pourrait de la même façon que le popup qu'on veut, mais le problème des coordonnées et du clickable
persistent.
J'ai aussi parlé avec Dina pour lui parler de mon idée d'implémentation pour avoir une oeuvre non collectée dans l'oeuvre du jour et
elle m'a dit que c'était déjà fait dans la version android, mais qu'elle allait vérifier. Aussi Lena m'avait dit que dans l'oeuvre du
jour, nous n'avions plus besoin de la variable calendar(int). Pour appeller l'oeuvre du jour, on fait appel à la classe OeuvreDetailViewModel
qui possède comme attribut un oeuvreId(int). Ainsi, j'ai commencé à regarder quel était l'utilité de cette attribut et si c'est seulement
dans la classe FragmentOuevreduJour qu'on appelle OeuvreDetailViewModel, si oui je vais faire une nettoyage du code pour enlever l'attribut
oeuvreId et aussi nettoyer le code FragmentOeuvreDuJour.
Semaine 10 : 31 octobre - 6 novembre
Dans l'oeuvreDao, il y avait déjà une request permettant d'avoir une liste des oeuvres non collectés, mais cette request n'était utilisé nul part.
Donc, j'ai appelé dans OeuvreRepository la request de getNotCollected qui me retourne la liste et j'ai initialisé la liste dans OeuvreViewModel.
Au départ, quand j'avais parlé avec Lena, j'étais supposé enlever l'attribut calendar qui faisait référence à l'oeuvreId dans les classes parents
et qui est de type int. Après avoir regarder le code et essayé d'implémenter une fonction qui retourne une oeuvre du jour non collectionénné
de l'utilisateur, je me suis dis que finalement je vais surement garder l'attribut et changer le nom et l'implémentation, car je voulais faire
un Random().nextInt() qui renvoie un int de l'oeuvre qui va être son oeuvreId.
J'ai eu une rencontre samedi avec Lena pour discuter du bug que j'avais concernant la bubble map. Ainsi, on a regardé ensemble le code et essayer
de comprendre pourquoi je n'étais pas capable d'afficher ma 'bubble' aux bonnes coordonnées et on a décidé que ça allait être plus facile de faire
d'afficher un message au lieu d'avoir une bulle. Elle m'a aussi demandé de grossir la pin qui a été cliqué par l'utilisateur pour pouvoir savoir
laquelle il a cliqué et facilité son expérience. Aussi, en ce moment lorsque l'utilisateur appuie longuement sur la map un message apparait demandant
la confirmation de changer la position du pin. Cependant, cela rend les utilisateurs confus ou ne se rappelle plus comment faire. Pendant la rencontre,
Lena m'a demandé si c'était possible d'implémenter une fonction qui permet à l'utilisateur de cliquer n'importe ou sur la carte excepté les pins et de
faire apparaitre le message au lieu d'utiliser le long Press.
Donc, j'ai crée une fonction onClickMap qui permet d'afficher un AlertDialogue lorsqu'on clique sur un pin. Dans le dialogue, il y le titre de
l'oeuvre et un icone de la liste des l'oeuvres. Par la suite, j'ai crée une autre fonction onOeuvreClick, qui permet aux utilisateurs de cliquer
sur l'icone et ça les amènera directement à la fiche de l'oeuvre en question. Toutefois, lorsque je travaillais, j'ai eu un bug peut importe dans
quel branche sur git que j'étais, quand je roulais l'émulateur, la liste des oeuvres, les pins sur la map et l'oeuvre du jour ne s'affichait pas.
J'ai attendu une soirée et le lendemain j'ai un autre bug, je ne peux pas me connecter au serveur. Pendant ce temps, j'ai commencé à regarder le
code des badges et essayé de comprendre pourquoi le derinier badge de celui de Quartier et de Catégorie ne s'affichent pas au complet.
J'ai passé 4 jours a essayé de debugger le bug, j'ai cherché partout comment faire, j'ai re installer windows 2 fois en pensant qu'en supprimant
tout les fichiers existant et en recommencant à 0, ça allait régler le problème. J'ai aussi re installé android studio ainsi que mona-kotlin 2 fois.
J'ai nettoyer le cache du projet, supprimer toutes modifications que j'avais apporté dans git en pansant que j'allais avoir l'ancienne version, mais
non ça n'a rien changé. J'ai switcher de branches dans git pour essayer d'accèder aux anciennes versions, mais le problème d'affiches des données
persistent toujours. Dina et moi avons passé 3h00 à essayer de debugger, ça n'a rien donné. Après Thomas a aussi essayé de m'aider et on a trouvé que
la liste de l'url de artwork était vide et qu'on y avait accès seulement quand il y a une mise à jour dans artwork. Donc, on a supposé que ça venait de
la mon problème, mais on ne l'a pas encore résolu. J'ai regarder le database de mon emulateur et remarqué qu'artwork table était vide, mais pas celui du
badge et j'ai regardé le code, fait des debugs, lancé des prints. Prochaine étape est que je vais essayer sur mon veille ordi pour voir si ça peut régler
le bug et pour que je puisse continuer à travailler dessus.
Semaine 11 : 7 novembre - 13 novembre
J'ai essayé sur un autre ordinateur d'installer android et le projet mona et j'avais toujours la même erreur. J'ai regardé les commits qu'il y a eu par rapport
aux database dans android studio et il n'y a eu aucun changement. La dernière fois, Dina m'avait envoyé les fichiers de "artwork_table" et celle des "badges". Donc,
ce que j'ai regardé comment remplacer mes fichiers de database en pensant que ça allait fonctionné, mais finalement ça n'a pas réglé mon problème.
Donc, j'ai du en parlé avec Lena et Dina de ce problème et on s'est dirigé vers une solution qui était de regarder l'architecture de Mona et de faire un diagramme de
classe UML du projet. J'ai contacté Jean-Marc pour qu'il puisse m'expliquer comment il a structuré son code pour m'en inspirer.
Par la suite, j'ai commencé mon diagramme de classe, j'ai regardé les classes du database et inseré chaque fonctions dans le diagramme. J'ai aussi fait des recherches sur
certaines classes dont j'étais peu familière par exemple data classe dans le but de mieux comprendre leurs fonctionnanilités. Après, j'ai regardé
le code et noté ou ce que ça pourrait poser problème de couplage dans le code et apporté les modifications dans le diagramme. Ainsi, dans le BadgeRepository, à la place
d'avoir une variable badgesList: LiveData
J'ai commencé la section "vue" dans le diagramme, c'est-à-dire les classes dont je savais qu'il fonctionnait parfaitement et n'avait pas de problèmes, je les ait mis dans le diagramme.
J'ai regardé la section "viewmodels" du code et j'ai aussi commencé à regarder chaque code de la section fragment afin de trouver quel section de code se répète plusieurs fois dans différent fragments
et qui pourrait être implémenté dans la section "viewmodels" pour alléger le code et avoir plus facilement accès aux données.
Semaine 12 : 14 novembre - 20 novembre
Après avoir eu une rencontre avec Dina et Lena, nous sommes venu à la conclusion d'enlever la classe BadgeFr et BadgeEn, donc j'ai supprimé ces deux classes du diagramme. J'ai créé une classe parent nommé Article contenant les informations telque id et location. Ensuite, j'ai créé une classe OeuvrePlace et une classe Patrimoine contenant les informations
dépendamment si c'est un lieu ou un patrimoine qui héritait de la classe Article. J'ai aussi regardé la classe object SaveSharedPrefence, car à la dernière rencontre Dina avait dit que cette
classe était importante et que je devais la mettre dans le diagramme. Donc, j'ai lus plusieurs documentations pour comprendre c'est quoi la classe Object Declarative et aussi pourquoi c'est mieux
de choisir ce type de classe à la place de Data ou Open Classe. J'ai aussi regardé l'implémentation des fonctions de la classe SaveSharedPrefence et ou qu'elles étaient appelé pour voir quelles étaient leur utilitée.
J'ai ajouté les classes qui faisait partie du fichier Task et j'ai ajouté une nouvelle classe qui est PatrimoineTask pour que ça aille chercher le bon fichier. J'ai aussi regardé la clase SaveOeuvre et ainsi que
toutes ses fonctions implémenté pour voir si le bug d'enregistrer les oeuvres se situait dans cette classe. J'ai aussi re-regardé l'implémentation du code IOS pour voir comment il avait fait leur architecture.
J'ai regardé l'implémention du modelView c'est-à-dire j'ai regardé chaque classe ainsi que leurs fonctions et je suis allée voir dans le code ou est-ce que les fonctions étaient appelé et quel était leur fonction dans le code dans le code.
Je voulais m'assurer qu'on allait bien chercer les informations des oeuvres, car Lena avait mentionné que certaines oeuvres n'avait pas toutes leurs informations, d'ou l'importance de regarder chaque
fonction. J'ai commencé la classe PatrimoineViewModel mais n'a pas encore fini. Il a fallu que je regarde c'était quoi les liens entre les classes pour savoir quel genre de flêches je dois utiliser
dans mon diagramme et aussi connaitre les relations entre chaque classe.
Semaine 13 : 21 novembre - 27 novembre
Après avoir parlé avec Lena, nous avions discuté d'un 'problème' dans l'interface ArticledDao, il fallait que je m'informe sur le sujet de l'hérite. On se demandait s'il était possible de faire seulement une sous-classe qui implémente l'interface ArticleDao et qui retourne soit un patrimoine, place ou oeuvre au lieu d'avoir trois sous classe dont une patrimoine, une oeuvre et une place. Suite à mes recherches en lien avec le patron de fabrique, il est possible de le faire et à la place de retourner un type d'objet, je ferais une vérification si l'objet qui est passé en paramètre de type oeuvre, place ou patrimoine et en fonction de l'objet je retournerais une instanciation d'une des sous-classes de Article. Par la suite, j'ai créé une classe UserLocation permettant d'avoir accès aux fonctions du user. J'avais remarqué que plusieurs de ces fonctions étaient déclarée dans différentes classes, mais n'étaient pas implémenter dans une classe spécifique permettant d'override la fonction. En ce qui à trait au problème d'envoie de photo, j'ai décidé d'utiliser le patron d'état et j'ai créé une interface qui a une seule spécialité qui est d'envoyer les photos.
Semaine 14 : 28 novembre - 4 décembre
J'ai commencé la partie Fragment. Ainsi, j'ai regardé tout le code et j'ai cherché quelles fonctions faisait appel à quelles classes. J'ai subdivisé la classe MapFragment et la classe OeuvreItemMapFragment, car ces deux classes contenaient plusieurs variables identiques ainsi que des fonctions. Ce que j'ai décidé de faire, c'était de crée une classe parent nommée Map contenant les variables et les fonctions en commun et à partir de de cette classe, il y a deux sous-classes qui est MapArticleFragment et ArticleItemMapFragment. J'ai aussi subdivisé la classe ListFragment puisque celle-ci contenait plusieurs fonctions et c'était facile de s'y perdre. J'ai regroupé toutes les fonctions qui ajoute quelque chose dans la liste et j'ai mis dans une sous-classe nommée ListAddFragment. Le même principe s'applique aussi pour ArticleInfo. J'ai aussi créé trois sous-classes qui héritaient de la classe parent CollectionFragment, permettant de réduire le couplage et d'accéder plus facilement aux objets.
Semaine 15 : 5 décembre - 11 décembre
J'ai ajouté la section Activity dans le diagramme de classe et j'ai re regardé les liens entre les classes pour que puisse faire les bonnes associations. Ensuite, j'ai du faire le diagramme de classe du projet actuel, afin de comparer les quelques différences que j'ai apporté dans le code ainsi que dans la nouvelle architecture du programme.