William Nelson
Ali El Mufti

En collaboration avec le personnel de l'UGA, le but était de créer une application de covoiturage solidaire pour la ville de La Mure permettant aux personnes à mobilité réduite ou âgées de se déplacer plus simplement. Ces personnes peuvent télécharger l'application, demander un déplacement et des conducteurs bénévoles peuvent répondre à ces requêtes après avoir téléchargé l'application également.

Cette application est disponible sur Android, iOS et on propose même une solution Web pour ceux qui ne possèdent pas de smartphone. Le service est 100% gratuit et requiert juste la création d'un compte avec son adresse mail.

L'essentiel de cette application est qu'elle soit intuitive sans trop d'informations, il est important de se rappeler que des personnes âgées ne sont pas forcément très à l'aise avec les nouvelles technologies. A part ça, nous n'avions pas trop de contraintes et nous avons pu laisser parler notre créativité et compétences pour choisir les technologies et construire les interfaces. Nous en parlerons plus en détails dans la suite.

Nous avons fait le choix d'utiliser ce langage de programmation en particulier car il correspondait le plus à ce que l'on voulait atteindre, à savoir une application disponible sur toutes les plateformes, que ce soit Android ou IOS et qui ai aussi une alternative sur le web. De ce fait, Flutter nous semblait être le choix le plus adéquat car il nous permet grâce à un seul code généré de pouvoir obtenir ces 3 alternatives en même temps. De plus, Flutter a une documentation assez riche sur internet et il est très facile à prendre en main même pour des personnes qui n'ont jamais utilisé Dart au par avant. Ajouté à cela le fait qu'un grand catalogue d'extensions sont disponibles gratuitement et utilisables sans forcément altérer le code précédemment généré.

Concernant le stockage de nos données, nous avons choisi d'utiliser FireBase.
Firebase est une plateforme développée par Google comme Flutter afin de pouvoir créer des applications Web et Mobiles. De part sa compatibilité avec Flutter, nous avons choisit de l'utiliser comme base de donnée distante grâce au service Cloud Firebase. Dans cette base de données nous avons divisé nos stockages en 3 parties :

• Partie Conducteur

  • Nous aurons ici tous les conducteurs qui se seront inscrit sur l'application en tant que conducteurs, ils auront tous un ID bien définit pour eux, de plus, chaque conducteur aura un certain nombre de champs spécifiques :
    • Prénom
    • Nom de famille
    • Numéro de téléphone
    • Les trajets en cours

• Partie Utilisateur

  • Tous les passagers sont disponibles ici, ils ont chacun un identifiant propre mais aussi des champs bien spécifiques:

    • Nom de famille
    • Prénom
    • Historique de touts les trajets faits
    • Numéro de téléphone

• Partie Requests

  • Chaque requête a un identifiant propre mais aussi une serie de champs qui nous aideront pour le bon fonctionnement du trajet :
    • La Date
    • Les identifiants de l'utilisateur et du conducteur
    • Le lieu de départ ainsi que ses coordonnées géographiques
    • Le lieu d'arrivé ainsi que ses coordonnées géographiques
    • Les coordonnées géographiques de l'utilisateur et du conducteur
    • Le statut de la commande : Ouvert ou Fermé

Ces dispositions ainsi que ces techniques nous ont permis d'agencer notre base de données.
Concernant les IDE que nous avons utilisé dans notre projet, nous avions commencé a coder sur Visual Studio

Cet IDE nous a été utile au début car il offre une interface assez intéressante pour la gestion des dépendances de Flutter, seulement, on se retrouve assez limité au niveau des fonctionnalités et surtout au niveau de l’aperçu du code.

Nous avons donc décidé de changer d'IDE et de passer sur Android Studio :

N'ayant pas tous les deux un téléphone Android, Android Studio offre la possibilité d'utiliser un émulateur de téléphone sous Android. De ce fait, les tests et l'implémentation de nouvelles fonctionnalités se font plus rapidement.

Concernant notre architecture, nous avons opté pour l'architecture suivante :

Durant ce projet nous avons réalisé les fonctionnalités techniques suivantes :

• Base de donnée distante Firebase
• Possibilité de s’inscrire et de se connecter en tant que passager et en tant que conducteur
• Affichage de tous les trajets disponibles pour un conducteur
• Prise en charge d’un trajet par le conducteur
• Création d’un trajet par le passager
• Possibilité de changer ses données personnelles
• Interface de contact
• Possibilité de choisir un lieu de rencontre spécifique
• Interface responsive
• Possibilité de choisir avec une carte ou une adresse les lieux de rencontre
• Possibilité d’avoir une photo de profil pour chaque utilisateur
• Google Maps avec tracé du trajet

Concernant notre gestion de projet, vu que l'un d'entre nous était déjà familier avec les technologies que nous avons précisé précédemment, nous avons opté lors du début du projet pour du Pair Programming. Cette approche nous procuré énormément d'avantages comme le fait de pouvoir s'approprier les outils plus rapidement, le fait de pouvoir s'adapter à un nouveau environnement de travail et finalement de pouvoir apprendre à coder dans un langage inconnu assez rapidement.

Nous nous sommes par la suite organiser de telle sorte que notre projet puisse se diviser en 3 grandes étapes :

• Créations des outils de travail

  Configuration de la base de donnée Installation de Flutter sur les machines

• Création des fonctionnalités principales de l'application

  Possibilité de créer un trajet Possibilité de prendre en charge un trajet Interfaces différentes pour les conducteurs et pour les utilisateurs Pouvoir paramétrer son compte Pouvoir se déconnecter Pouvoir s'inscrire Pouvoir se connecter

• Ajout de détails dans l'application et rattraper un éventuel retard

  Refonte totale de l'interface graphique de l'application Generation de l'APK Cacher les clés API

Concernant les outils d’organisation, nous avons utilisé l'outil de gestion de projet de Git.

Cela a ses avantages comme par exemple, une utilisation simplifiée, nos commits, nos pull request et nos issues sont automatiques organisées et triées en 4 catégories :

• To Do
• In Progress
• To Review
• Done Cela nous permet de garder une trace de tout ce que l'on fait, sans pour autant s'encombrer avec un Trello en parallèle de notre Git.

En plus de Git, afin de pouvoir communiquer l'un avec l'autre, nous avons aussi utilisé Discord

Nous sommes à 2888 de lignes codées (nous ne comptons pas les lignes générées par Flutter). Au niveau des langages utilisées nous sommes à 99.5% de Dart et le reste c'est du généré, essentiellement du JSON, Java et du XML.

Là dessus, nous sommes à 50.82% de lignes de codes pour Ali et 49.18% pour William. Si nous prenons en compte le nombre de commits, nous sommes à 43.10% pour Ali et 56.90% pour William.

Pour conclure notre projet, nous pouvons dire qu'il a été extrêmement intéressant que ce soit au niveau de la conception ou au niveau des technologies que nous avons utilisé. L'utilisation de Flutter et son apprentissage ont été très formateur pour l'ensemble de l'équipe et nous nous sentons prêt a réitérer l’expérience sur un nouveau projet.

Le fait que notre groupe soit composé de deux personnes a aussi été une experience plus qu'interessante car nous avons du recourir a des techniques de gestion de projet qui sortent de l'ordinaire, comme par exemple le Pair Programming que nous avons évoqué précédemment. De plus, ce projet a été pour nous quelque chose de très important car très formateur, en effet, nous avons eu la chance de travailler sur un projet concret où nous pouvions directement interagir avec notre conception et de ce fait, cela a rendu le projet beaucoup plus interactif et agréable a traiter.

Nous regrettons cependant de ne pas avoir eu plus de temps durant ce projet, ainsi que le fait que la plupart du projet s'est passé en distanciel, cela a, selon nous, ralentit l'avancement du groupe.

Nous pouvons donc à partir de cela tirer quelques conclusions qui pourront nous être utiles pour nos projets à venir, à savoir faire plus de séances en présentiel, créer des maquettes en avance afin de pouvoir se baser dessus et ainsi avoir une interface encore plus optimisée mais aussi, nous devons apprendre a mieux gérer le temps impartit ainsi que nos sprints.

Pour notre démonstration, nous allons commencer par l'inscription d'un utilisateur en tant que passager, puis nous allons, avec ce même utilisateur, nous connecter. Nous allons ensuite procéder à la création d'une course car nous souhaitons allons au marcher de la Mure par exemple. Par la suite, nous allons nous connecter en tant que conducteur et prendre en charge la commande établie précédemment. Nous vous montrerons ensuite comment une course se déroule sur l'interface conducteur ainsi que sur l'interface passager et finalement, nous allons vous montrer la fin de course à savoir, une fois que le passager est déposé et qu'il y a eu une double validation de la course.