AP4-1 - Stages Android
Contexte
Afin de valider leur BTS, les étudiants doivent effectuer deux stages obligatoires de 5 à 6 semaines par année en entreprise. Pour faciliter la mise en contact des étudiants avec des organisations connaissant la formation (BTS SIO) et ayant déjà eu l’occasion d’accueillir des stagiaires, les données liées aux stages sont conservées dans une base de données stages avec des mises à jour de l’existence ou non des organisations, et de la présence ou non des contacts dans une organisation donnée.
Un service d’API REST et une application Android ont été développés pour permettre aux étudiants et enseignants de consulter cette base de données et d’y ajouter, modifier ou en supprimer des éléments.
L’atelier précédent AP32 consistait à répondre aux demandes d’évolution de la base de données stages et du service d’API REST afin de répondre aux exigences du cahier des charges fourni par les enseignants.
Il s’agit dans cet atelier AP41 de faire évoluer l’application Android pour y intégrer le service API et répondre aux besoins exprimés dans un nouveau cahier des charges fourni pour le projet.
Dans un premier temps, nous avons effectué une rétro conception/documentation de la base de données après une première évolution.
Modèles de conception de la base de donnée sur WinDesign (cliquez pour agrandir l’image) :
Environnement technologique
Ressources et outils (fournies ou à installer)
Android Studio64
Microsoft Visual Studio Code
Plateforme GitLab (suivi du projet)
Service API fonctionnel (PHP)
Talend API Tester (extension navigateur)
Package XAMPP et phpMyAdmin (SGBDR)
Ferme de serveurs VMWare
- serveur US22_WEB (Ubuntu v. 22.04)
Tablette Acer Iconia Tab 10 A3-A40
Cahier des charges
Programmation (langages/formats utilisés)
Langage Java
Format XML
Langage PHP
Format JSON
Description
1 – Prise en main et tests de l’application Android
Dans un premier temps, nous avons chacun cloné en local le répertoire de l’application Android depuis le projet ap41-stages-android sur GitLab et avons vérifié le bon fonctionnement des requêtes à l’API pour l’environnement de test de la section SIO puis sur les deux environnements de travail (développement et production), depuis le poste physique (requêtes directes à l’API) mais aussi avec l’application (émulateur ou tablette physique) .
L’application Android fonctionne comme suit :
– On accède à un écran d’authentification (MainActivity) sur lequel on renseigne un identifiant (adresse mail) et un mot de passe.
– Après authentification, on accède à un écran affichant la liste des organisations ayant accueilli des stagiaires (OrganisationsActivity).
– En appuyant sur une organisation, on accède à l’écran des détails de l’organisation (DetailOrganisationActivity). On peut modifier les informations de l’organisation et valider les modifications en appuyant sur le bouton « Modifier ». On retourne alors à la liste des organisations.
2 – Exigences fonctionnelles – Évolutions mineures
Après avoir vérifié le bon fonctionnement de l’API sur les deux environnements, que ce soit par appel direct de l’API ou via l’application Android, nous avons entamé l’évolution du code de l’application Android selon les attendus du cahier des charges. Il s’agissait dans un premier temps d’effectuer quelques évolutions mineures et nous nous sommes répartis les tâches.
La première exigence fonctionnelle consistait à compléter le formulaire de modification d’une organisation en y ajoutant l’intégralité des informations modifiables. Initialement, les détails de l’organisation comprennent le nom, l’adresse, le code postal et la ville. J’ai ajouté le numéro de téléphone et l’adresse e-mail aux détails de l’organisation.
Pour cela j’ai modifié l’interface graphique de DetailOrganisationActivity pour y ajouter les nouveaux champs, j’ai ajouté les nouvelles propriétés à la classe Organisation puis j’ai modifié le code de DetailOrganisationActivity pour que ces nouveaux champs soient remplis avec les propriétés correspondantes de l’organisation sélectionnée.
La deuxième exigence fonctionnelle consistait à permettre l’affichage de l’adresse e-mail de l’étudiant connecté dans la barre du titre de l’application, sur tous les écrans. Pour cela j’ai permis l’envoi de l’adresse e-mail d’un écran à l’autre à travers les intentions, depuis l’écran d’authentification. Il suffisait ensuite de changer la barre du titre dans chaque écran en y insérant l’adresse e-mail.
3 – Exigences fonctionnelles – Nouvelles fonctionnalités
Au cours de cette dernière étape, l’exigence sur laquelle j’ai travaillé consistait à permettre la consultation des contacts d’une entreprise et la modification des détails d’un contact. J’ai donc ajouté un écran ContactsActivity, accessible depuis les détails d’une organisation avec un bouton Contacts, qui affiche la liste des contacts de l’organisation sélectionnée. En appuyant sur un contact de la liste, on accède à ses détails dans un écran DetailContactActivity. La modification des contacts fonctionne de la même manière que pour les organisations.
Le compte-rendu de cette étape est disponible dans les productions.
Compétences mobilisées
B1.1 – Gérer le patrimoine informatique
B1.2 – Répondre aux incidents et aux demandes d’assistance et d’évolution
B1.4 – Travailler en mode projet
B1.5 – Mettre à disposition des utilisateurs un service informatique
Productions
Code source de l’application – Contacts (ZIP – JAVA/XML)