Spécifications des améliorations
Dans cette partie nous expliciterons plus en détail le travail qui a été effectué durant le semestre dans le but d'apporter un certain nombre d'améliorations à l'application. Afin de structurer ce document, il a été décidé de le diviser en plusieurs parties correspondant chacune à un point du modèle de qualité logiciel.
Ce modèle est divisé en cinq points clés permettant de mesurer la qualité d'un logiciel :
- Reliability (ou Fiabilité)
- Efficiency (ou Optimisation et/ou Efficacité)
- Maintainability (ou Maintenabilité)
- Usability (ou Convivialité)
- Functionality (ou Fonctionnalité)
L'application contenant un certain nombre de requêtes pour fonctionner, la plus grande partie du travail a été effectué dans le but d'améliorer l'optimisation de ces requêtes, c'est pour cela que ce document insistera beaucoup plus sur cet aspect du modèle.
L'optimisation est un point très important lorsqu'il s'agit de développer une application ou un logiciel car il faut éviter à tout prix que l'expérience de l'utilisateur soit affectée par des problèmes de performances. Lorsque l'on développe une application dans le but d'être utilisée par le grand public, il est nécessaire de mettre en place des bonnes pratiques afin de s'assurer que l'utilisateur revienne utiliser l'application.
Il y a de nombreuses raisons pouvant causer une perte de performance dans une application :
- Architecture générale de l'application basée sur des mauvaises pratiques
- Interactions avec des serveurs distants de mauvaises qualitées
- Mauvaise gestion de l'accès aux données
- Mauvaise gestion de l'espace disque et du réseau
Il est possible de résoudre la plupart de ces problèmes en utilisant un certain nombre de bonnes pratiques et en prenant en compte lorsque l'on développe l'application les différents composants et les difficultés qui y sont liées. Il faut également prendre en compte que chaque utilisateur aura une expérience différentes selon l'environnement dans lequel il utilise l'application, il est donc nécessaire d'effectuer des tests réguliers car il est possible que des problèmes de performances non-apparent lors du développement existent lors du passage en production.
Dans le cas de notre application, les problèmes de performances sont principalement liés aux requêtes émises aux serveurs distants et à l'utilisation de services tiers tel que l’utilisation de l’API Google Maps. En effet, l'application est dépendante de ces requêtes afin de pouvoir proposer à l'utilisateur les différentes fonctionnalités qu’elle propose. Il faut comprendre que lorsque nous réalisons une requêtes, il faut attendre la réponse du serveur mais également le chargement des données car ces requêtes sont de natures asynchrones. Si ces données sont très lourdes, le chargement peut prendre beaucoup de temps. Il est donc logique de concentrer ce travail d'optimisation sur le traitement de ces requêtes. De plus, il est également nécessaire de prendre en compte qu'au fur et à mesure de l'avancé de l'application, le nombre de requêtes augmentera afin d'offrir à l'utilisateur des ressources de plus en plus complètes et précises, il est donc obligatoire de prendre ce facteur en compte si nous souhaitons que l'application évolue au mieux.
Il faut également prendre en compte que cette application est tout d'abord faite pour être utilisée sur un smartphone, et que même si aujourd'hui le réseau mobile est très performant, de nombreux vitraux se trouve dans des endroits où ce même réseau n'est pas aussi performant.
L'application dans son état actuel souffre d'un certain nombre de problèmes de performances, ce qui affecte grandement l'expérience de l'utilisateur. La page Tour qui représente la page d'accueil de l'application peut mettre plusieurs secondes avant de se charger. Il faudra donc prendre en comptes les différentes variables qui ont été explicitées précédemment afin d'apporter des solutions à ces différents problèmes.
Dans cette partie nous décrirons plus en détails les différentes solutions d'optimisations qui ont été mises en place lors du développement du fork afin d'améliorer les performances de l'application et résoudre les problèmes de performances.
Précédemment, nous avons vu que les problèmes de performances dans le cadre de l'application étaient principalement causés par une mauvaise gestion des requêtes aux serveurs distants.
Afin de répondre à ce problème, une solution consiste à paralléliser les différentes requêtes. En effet, après observation du code, nous avons pu remarquer qu'une bonne partie des requêtes étaient imbriquées, cela signifie que certaines requêtes attendent que la réponse d'une autre requête soit envoyé avant d'être à son tour d'être envoyée aux serveurx distants.
Cela cause deux problèmes :
- Certains affichages sont bloqués par cette attente
- L'application prends énormément de temps avant de charger toutes les requêtes. (C'est à dire le temps de chargement de la première requête, et ensuite le chargement des requêtes suivantes)
Afin de répondre à ce problème la solution consiste à paralléliser les requêtes grâce à l'utilisation de l'objet Promise en Javascript. Cet objet permet de réaliser des calculs asynchrones et permet également de paralléliser des requêtes asynchrones.
Il faut comprendre que le choix d'imbriquer les requêtes était dû à une inter-dépendance des fonctions d'affichages. Pour résoudre ce problème il fallait d'abord faire en sorte que chaque fonction se chargeant de l'affichage d'une partie de la page soit indépendante au maximum. Il n'est pas possible d'atteindre une indépendance parfaite car certains affichages sont dépendants de plusieurs requêtes.
Quand ce travail a été réalisé il faut, pour chaque page, paralléliser les requêtes grâce à l'utilisation de l'objet Promise évoqué précédemment.
Cette parallélisation est effectué aussi bien pour les requêtes aux serveurs Argos et Steatite que pour les différentes requêtes effectuées à travers l'API Google Maps.
Afin d'optimiser au mieux les requêtes, nous avons également recours à la parallélisation des affichages. Même si les requêtes sont effectuées au même moment, le temps de chargement de chacune d'entre elle sera différente. Il est donc possible d'utiliser les fonctions d'affichages au moment où les données de la requêtes sont chargées cela dans le but de ne pas attendre que toutes les données soient chargées avant d’afficher les résultats.
Cette solution possède des limites, car même si les fonctions d'affichages sont indépendantes, il est possible que certains affichages se doivent d'être fait après d'autres. C'est pour cela qu'il est nécessaire d'avoir un point de synchronisation correspondant aux chargements de toutes les requêtes, c'est ensuite qu'il faut réaliser ces fonctions d'affichages.
Ces deux solutions sont appliquées à toute les pages de l'application, ce qui permet d'obtenir des temps de chargement plus raisonnables. De plus cela permet de répondre au problème du blocage de l'affichage.
Lorsqu'il s'agit d'effectuer un certain nombre de requêtes à un serveur distant, il faut généralement utiliser HTTP (Hypertext Transfer Protocol). Il s'agit d'un protocole de requête et réponse entre un client et un serveur. Quand on établit une requête HTTP, une réponse est renvoyée au client, celle-ci contient un ensemble d'informations détaillant la requête comme : la méthode de la requête (POST,GET), la date, le statut, le serveur, etc...
Ce statut correspond à un code permettant d'indiquer la réussite ou non de la requête. Voici quelques exemples :
- 200 : Correspond à une requête HTTP réussie.
- 304 : La ressource n'a pas été modifiée, il est donc possible d'utiliser le cache.
- 404 : La ressource que nous essayons d'obtenir n'a pas été trouvée.
- 403 : La requête est est valide, mais le serveur refuse d'y répondre.
Le code 304 signifie donc que la ressource que nous essayons d'obtenir n'a pas été modifiée depuis la dernière fois et que par conséquent il n'est pas nécessaire de re-transmettre la ressource car le client peut utiliser une copie toujours disponible localement.
Cela devient très intéressant pour l'optimisation de l'application car nous pouvons réutiliser ces données en cache et retrouver exactement le même résultat en un temps beaucoup moins élevé.
Par exemple : Quand nous récupérons les données du viewpoint "Histoire des Religions", afin de construire l'ensemble des parcours auxquels l'utilisateur peut accéder on obtient des chargements dix fois moins élevés avec l’utilisation du cache.
Quand la page est rechargée et si les données n'ont pas été modifiées côté serveur, la requête renvoyé enverra le status 304, il n'est donc pas nécessaire de changer toutes les requêtes afin de charger les données en cache mais il est nécessaire de trouver une autre solution pour les pages suivantes.
En effet, la page Map et la page Tour n'utilisent pas les mêmes requêtes sur Argos, hors il est possible d'utiliser les même requêtes que précédemment afin d'obtenir des résultats similaires. Cela va de même avec la page Explore et la page Description.
Une solution à ce problème consiste à utiliser les mêmes requêtes tout au long de l'application, cela obligera l'application à utiliser les données du cache à la place des données téléchargées quelque soit la page.
C'est pour cela qu'il faut remplacer au maximum l'ensemble des requêtes faites sur chaque page, afin que celles-ci soit similaire à celle des pages précédentes. Il faut prendre en compte que parfois il n'est pas possible d'avoir recours à ces mêmes requêtes car il faut utiliser des données complètement différentes. Dans le cas de Explore et Description, il faut faire des requêtes à Steatite, ce qui n'était pas nécessaire dans les pages précédentes.
L'utilisation du cache permet dans ce cas là de réduire considérablement les temps de chargements.
Lorsque la page Tour est chargée, celle-ci propose la liste des différents parcours ainsi que quatres informations concernant chaque parcours : Le nombres de vitraux, le nombre d'endroits à visiter, la distance du parcours, et la durée du parcours.
Il est très difficile de prévoir la distance et la durée du parcours sans l'utilisation de l'API Google Maps, celle-ci nous permet de proposer à chaque utilisateur un parcours sur une carte interactive. Lorsque ce parcours est chargé, nous avons accès à ces données, hors ce parcours n'est pas chargé dans la page Tour. Il serait donc nécessaire de charger ces données dans la page Tour , mais cela n'est pas productif car l'ensemble des données peut être très lourds à charger et c'est pour cela que cela ne se présente pas comme une solution optimale.
Les développeurs précédents ont décidé de ne pas implémenter une fonction permettant de calculer la distance, et ont répondu au problème de récupération de la durée du parcours en implémentant une fonction ayant pour rôle de faire une approximation de cette valeur.
Comme solution nous avons décidé d'utiliser l'API Web Storage qui permet de stocker des valeurs dans le cache du navigateur grâce à des pairs clé/valeur. Quand l'utilisateur arrive sur la page Map, nous enregistrons la valeur de la distance et de la durée avec comme clé l'identifiant du topic concerné.
Cette solution est seulement partielle car l'utilisateur est obligé de charger la page Map afin d'obtenir cette valeur sur la page Tour.
Voici les différents résultats obtenus grâce à l'optimisation de l'application. Ces résultats prennent en compte les variations de connexion du réseau mobile. Afin de dévoiler des résultats consistants nous avons choisis de prendre l'exemple du parcours "Jehan Macardé" contenant 2 lieux et 2 vitraux. Ces résultats sont exprimés en milliseconde et représente une moyenne de la vitesse de chargement. Il faut également prendre en compte que le nombre de requêtes par pages change entre les résultats sans optimisation et avec les optimisations.
Résultats pour la page Tour
*|Sans Optimisation (3 requêtes)| Avec Optimisation (5 requêtes) -----|------|---------|------------ Sans cache|2000| 1500 Avec Cache|1000| 800
Résultats pour la page Map
*|Sans Optimisation (4 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|3500|3000 Avec Cache|650|750
Résultats pour la page Explore (prends en compte le chargement des images)
*|Sans Optimisation (2 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|1300|2100 Avec Cache|1000|1300
Résultats pour la page Description (prend en compte le chargement de l'image)
*|Sans Optimisation (1 requêtes)| Avec Optimisation (4 requêtes) -----|------|---------|------------ Sans cache|3300|2800 Avec Cache|1000|1200
Résultats pour la page Tour
*|Sans Optimisation (3 requêtes)| Avec Optimisation (5 requêtes) -----|------|---------|------------ Sans cache|21000| 20000 Avec Cache|800| 800
Résultats pour la page Map
*|Sans Optimisation (4 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|41000|45000 Avec Cache|1000|900
Résultats pour la page Explore (prends en compte le chargement des images)
*|Sans Optimisation (2 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|20000|28000 Avec Cache|7000|11000
Résultats pour la page Description (prend en compte le chargement de l'image)
*|Sans Optimisation (1 requêtes)| Avec Optimisation (4 requêtes) -----|------|---------|------------ Sans cache|36000|25000 Avec Cache|6000|11000
Résultats pour la page Tour
*|Sans Optimisation (3 requêtes)| Avec Optimisation (5 requêtes) -----|------|---------|------------ Sans cache|6000| 6400 Avec Cache|600| 500
Résultats pour la page Map
*|Sans Optimisation (4 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|12000|27000 Avec Cache|700|850
Résultats pour la page Explore (prends en compte le chargement des images)
*|Sans Optimisation (2 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|6000|8300 Avec Cache|2300|3800
Résultats pour la page Description (prend en compte le chargement de l'image)
*|Sans Optimisation (1 requêtes)| Avec Optimisation (4 requêtes) -----|------|---------|------------ Sans cache|11000|13000 Avec Cache|2200|3600
Résultats pour la page Tour
*|Sans Optimisation (3 requêtes)| Avec Optimisation (5 requêtes) -----|------|---------|------------ Sans cache|2600| 2500 Avec Cache|800| 400
Résultats pour la page Map
*|Sans Optimisation (4 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|5000|5400 Avec Cache|1200|720
Résultats pour la page Explore (prends en compte le chargement des images)
*|Sans Optimisation (2 requêtes)| Avec Optimisation (7 requêtes) -----|------|---------|------------ Sans cache|2200|2800 Avec Cache|1200|1300
Résultats pour la page Description (prend en compte le chargement de l'image)
*|Sans Optimisation (1 requêtes)| Avec Optimisation (4 requêtes) -----|------|---------|------------ Sans cache|4900|5400 Avec Cache|1300|1700
Il existe encore dans l’application un certain nombre de problèmes à résoudre concernant l’optimisation de celle-ci :
-
Le serveur sur lequel est hébergée l’application est un petit serveur, ce qui peut grandement affecter les performances. Afin de répondre à ce problème, il faudrait héberger l’application sur un serveur plus performant.
-
L’utilisation du cache et du statut 304 semble être limité au serveur Argos et par conséquent il ne semble pas possible d’utiliser le cache pour les requêtes faites à Stéatite.
-
Le chargement des images est très long car ces images sont très lourdes. Afin de répondre à ce problème, il faudrait la possibilité de pouvoir charger des images réduites et compressés (ou de taille moindre) afin de pouvoir télécharger plus rapidement ces images.
Les fonctionnalités de l’applications représentent une part importante du développement de celle-ci, il est nécessaire de proposer à l’utilisateur des fonctionnalités lui permettant au mieux d’utiliser l’application afin que celui-ci passe une bonne expérience.
L’application VV propose à ses utilisateurs des données expertes en matière de vitrail. En effet les parcours thématiques proposés sont d’une grande précision. Si un vitrail correspond à une période précise de l’histoire, alors cela sera représenté lors de l’utilisation de l’application, et si les experts se rendent compte que la période était incorrecte, alors ces données seront mise à jour et l’utilisateur pourra en profiter instantanément.
Il faut également proposer à nos utilisateurs les données les plus complètes possible, car chaqu’un d’entre eux aura des goûts différents, et plus de données nous proposerons plus nous pourrons espérer obtenir de nouveaux utilisateurs. Il s’agit de donner le choix aux utilisateurs.
L’application est développé afin d’être utilisée sur smartphone, il s’agit d’un facteur très important quand il s’agit de proposer des fonctionnalités intéressantes à l’utilisateur car il est possible d’exploiter des technologies qui ne sont pas forcément présentent dans tous les ordinateurs de bureaux ou ordinateurs portables. L’utilisation du GPS est une chose très intéressante quand nous savons que l’application utilise une carte interactive et qu’il faut proposer à notre utilisateur un parcours dans l’espace. La majorité des smartphones actuels possèdent des GPS de très grandes précisions.
Un des travail d’amélioration de l’application consiste à développer et implémenter des fonctionnalités pouvant être intéressante pour l'utilisateur.
Dans la version de base de l’application, seul les topics les plus bas dans la hiérarchie étaient présents, ce qui offrait une certaine limite à l’utilisateur car si celui-ci était intéressé par un parcours concernant un sujet un peu plus large alors celui-ci ne pouvait pas y accéder.
Afin de développer une fonction permettant de récupérer l’ensemble de ces parcours, il fallait tout d’abord comprendre comment fonctionne cette hiérarchie.
Chaque topic possède un ensemble de broader et de narrower, les topics les plus hauts dans la hiérarchie ne possèdent pas de broader, et les topic les plus bas dans la hiérarchie ne possèdent pas de narrower.
La solution implémenté est différente entre Tour et le reste des pages. En effet, la page Tour utilise la bibliothèque List.js qui agit comme une mini base de données pour la page, il a donc été décidé de l’utiliser afin de garder en mémoire l’identifiant du broader de chaque sujet, si ce sujet ne possède pas d’identifiant alors il est le plus haut dans la hiérarchie.
Le broader d’un topic en particulier possède donc en mémoire l’ensemble des données de tous ces narrower, c’est à dire l’ensemble des lieux et l’ensemble des vitraux. Il ne faut pas oublier que parfois un vitrail peut appartenir à plusieurs narrower pour un même broader, il est donc nécessaire de garder également en mémoire les identifiants des différentes items afin de ne pas compter un vitrail en double.
Pour Tour, tous ce fait de bas en haut, nous analysons les données du corpus, et en général les items sont reliées aux sujets les plus bas dans la hiérarchie, par conséquent quand nous analysons un item, nous remontons l’ensemble des sujets grâce à l’identifiant du broader enregistré précédemment, nous incrémentons la valeur du nombre de vitraux et de lieux par un sans prendre en compte les doublons et jusqu'à ce que le topic en question ne possède plus de broader.
Pour les pages Explore, Description et Map, il faut tout faire de haut en bas, en effet lorsque nous récupérons un topic situé au plus haut dans la hiérarchie, nous risquons de nous trouver avec des résultats vides, car aucune item n’est liée directement avec ce topic. Il faut donc récupérer récursivement l’ensemble des topics situés plus bas dans la hiérarchie en partant du topic de base. Quand cette liste de topics est récupérée, il est possible d’analyser le corpus et de relier chaque vitrail correspondant à ce sujet.
Toutes ces fonctions nous permettent donc d’offrir à l’utilisateur la possibilité de réaliser tous les parcours possible.
Le corpus de base utilisé dans l’application de possède de nombreuses données mais il semble que l’utilisateur soit limité à celui-ci, or, il est possible de récupérer sur Argos et Steatite de nombreux autres corpus.
Grâce au travail réalisé sur l’optimisation de l’application il est maintenant possible d’accéder aux données contenues dans les autres corpus sans que cela prenne un temps considérable. Cela donne la possibilité à l’utilisateur d’avoir accès à des données qui n’étaient pas disponibles par le passé.
Dans l’application actuelle, la position de l’utilisateur n’est pas assumée. Le parcours décrit par la carte correspond donc à l’ordre d’obtention des différents lieux lors du chargement des données.
Cela n’est pas très pratique car il est possible qu’un utilisateur vive au centre de ville de Troyes comme à Romilly-sur-Seine. Il serait donc pratique de pouvoir offrir un parcours personnalisé à l’utilisateur. De plus, si le premier lieu est situé au centre ville de Troyes, le second à Géraudot, et le troisième encore au centre de ville de Troyes, alors le parcours fera passer l’utilisateur deux fois dans le centre ville de Troyes (au lieu d’une).
Afin de répondre à la première problématique, nous utilisons l’API de Geolocation, cette API nous permet de récupérer la latitude et la longitude de l’utilisateur, celui-ci possède le choix de partager ces coordonnées ou non. Ensuite, il suffit de comparer ces coordonnées aux coordonnées des différents point de passage que l’on récupère grâce à l’utilisation de l’API Google Maps. Il s’agit de calculer la distance entre chaque point de passage et la position de l’utilisateur. Pour cela il suffit d’utiliser la formule d’ “Haversine”. Nous récupérons ainsi un ensemble de distance, et il suffit donc maintenant de choisir le nouveau point de départ du parcours et de retracer les différentes directions grâce à l’API Google Maps.
Si l’utilisateur décide de ne pas vouloir utiliser l’API de Geolocation, alors le parcours de base sera affiché.
Afin de répondre à la seconde problématique, l’API Google Maps offre un moyen d’optimiser chaque point de passage grâce à une implémentation du “Problème du voyageur de commerce”, ce problème consiste à trouver le plus court chemin pour un ensemble de villes et l’ensemble des distances entre chaque paires de villes. Cela permet donc d’optimiser le chemin et de faire en sorte que l’utilisateur réalise le plus court chemin.
Pour la page Tour, il est maintenant possible d’avoir 392 parcours au lieu de 383, cette différence ne semble pas énorme mais elle correspond au nombre de sujet n’ayant pas de broader. Il est possible de voir la vrai différence dans les images suivantes.
Car aucun test n’a été effectué dans une autre ville que Troyes, il n’est pas possible de montrer que la géolocalisation fonctionne parfaitement.
- L’API de Geolocation ne semble pas consistante selon les navigateurs et cela peut poser un certains nombre de problèmes. Par exemple, il est normalement possible de pouvoir décider d’un temps avant que la boîte de dialogue demande à l’utilisateur si il est possible d’utiliser sa localisation disparaisse ou non. L’idée était que si l’utilisateur ne réagissait pas après un certains temps alors le chemin de base serait tracé sur la carte, mais vu que cela ne semble pas fonctionner alors il a été décidé de charger la carte dans tous les cas, et si l’utilisateur décide d’utiliser la position actuelle, alors les directions seront rechargées.
La convivialité d’utilisation de l’application est un aspect important car elle doit permettre à l’utilisateur de pouvoir naviguer dans l’application de façon agréable afin que celui-ci ait une expérience d’utilisation optimale.
L’application étant destiné pour une utilisation sur smartphone, il était nécessaire de rendre l’expérience agréable sur des petits écrans. Le groupe de développeur précédent a bien compris cela en utilisant le framework Ratchet, leur permettant de développer une application mobile utilisable dans un navigateur.
La gestion de la taille de l’écran est le point le plus important en terme de convivialité.
De base la carte sur la page Map prends la moitié de la place et le reste est destiné à afficher l’ensemble des lieux situés sur la map.
Quand cette page est utilisé sur un ordinateur de bureau ou un ordinateur portable cela ne semble pas poser de problème, mais lorsque nous utilisons cette page sur un petit écran tel que celui d’un smartphone, il est possible parfois de cliquer sur un lieu et de charger la page suivante quand l’utilisateur essayait seulement de naviguer sur la carte.
De plus les lieux indiqués sur le bas de la page ne semble pas indiquer à quel marker de la map ceux-ci font références.
La solution trouvé à ce problème consiste à utiliser les InfoWindow de l’API Google Maps. Il s’agit de petites boîtes de dialogues pouvant contenir des informations affichées en HTML qui apparaissent quand on clique sur un des markers de la carte. En utilisant les InfoWindow, il est possible d’afficher dans la map un lien redirigeant vers la page suivante, et également d’indiquer le nom du lieu en question.
La seule difficulté de cette solution réside dans le fait qu’il n’est pas possible de modifier les markers placés automatiquement par l’API Google Maps, il fallait donc utiliser une propriété spéciale afin de faire disparaître ces markers et générer de nouveaux markers afin de les placer manuellement sur la carte (en utilisant les mêmes coordonnées).
Avant :
Après :
La maintenabilité correspond à l’ensemble des mesures mises en places permettant d’assurer l’adaptation et la portabilité de l’application ainsi que le bon fonctionnement de celle-ci.
Vitraux-Visiteur est une application qui a été développé par un certain nombre d’étudiant,et dans le future sera développé par d’autres étudiants, il est donc tout logique de proposer un certain nombre de mesure afin de s’assurer que la transition entre les différentes équipes de développement se déroule au mieux.
Il est également nécessaire de faire attention à la fiabilité de certaine données car le cas présent nous utilisons des données disponibles sur des serveurs distants et les traitons avec un service tiers proposant une autre interprétation de ces données. Il est donc nécessaire de mettre en place des mesures permettant de s’assurer qu’il y a une bonne coordination.
Précédemment nous évoquons l’utilisation de données de serveurs distants avec d’autres services tiers.
Les données des corpus nous donnent un certains nombre de donnée géographique permettant de placer les lieux sur la carte interactive. Les lieux ne sont pas placés directement, mais subissent un traitement depuis l’API Google Maps retournant des coordonnées par rapport à ce lieu.
Il est possible que parfois ces données soient faussées car l’API Google Maps n’arrive pas à retrouver les données exacts. Par exemple, pour l’église St Remy de Troyes, l’API nous renvoie tout simplement “10000,Troyes”, ce qui place le marker à un endroit complètement différent que celui que nous recherchons. Ces données sont donc faussées et affectent l’utilisateur. Il est également possible que parfois l’API prioritise des villes possédant des noms similaires situés dans des départements différents.
La solution implémentée consiste à la création d’un objet, ou chaque clé correspond à un nom d’endroit contenu dans la base de données, quand ce résultat est faussé, et comme il n’y a pas d’accès direct possible au serveur contenant ces données, il est donc nécessaire d’associer à cette clé une valeur permettant de rapprocher au maximum de l’endroit voulu.
Au lieu d’utiliser directement l’API Google Maps afin de retrouver l’endroit, l’application utilisera cette valeur et l’API Google Maps renverra un résultat correct ou approximativement correct (pour St Remy, il n’est pas possible de désigner le lieu directement, il faut donc utiliser une rue juste à côté).
Cela correspond à une solution partielle à ce problème.
-
Il serait bien de revoir l’architecture complète de l’application car il semble que le code lui même n’est pas organisé selon de bonnes pratiques.
-
List.js est uniquement utilisé dans la page tour, ce qui affecte l’organisation du code car il y a création de fonctions ayant un rôles similaires mais codées différemments selon les pages. Il serait utile d’utiliser cette liste dans un contexte globale, même si cela signifie recharger les mêmes requêtes à chaque chargement de page.