Skip to content

7. Chapitre 6 - Conclusion et étapes suivantes

7.1. Ce qui a été construit

Ce document a porté vers une application Android native le cœur fonctionnel et l’authentification de l’application [RdvMedecins] du document original de 2014 :

  • un serveur [NestJS] complet (le même que dans les variantes Angular, React, Vue.js et Flutter du cours, installé et testé au chapitre 2 mais dont le code n’est pas étudié ici), exposant les mêmes routes métier JSON que le serveur Spring 4 original, toutes protégées par un jeton JWT ;
  • un client Android écrit en [Kotlin] avec [Jetpack Compose] (Material 3) offrant les mêmes fonctionnalités que le client AngularJS 1.x original - choix d’un médecin et d’un jour, consultation de l’agenda, réservation et annulation d’un rendez-vous - complété d’un écran de connexion, d’une session persistée ([SharedPreferences]), d’une interface adaptée au rôle de l’utilisateur connecté, et du passage français/anglais de l’interface ([TranslationsService], avec les dictionnaires des autres variantes).

Ce client reprend fichier pour fichier l’architecture du client Flutter. Les différences les plus marquantes tiennent à la plateforme plus qu’au langage : la recréation de l’activité à la rotation de l’écran, qui impose un [ViewModel] et [rememberSaveable] ; l’interdiction des accès réseau sur le thread principal, qui impose les coroutines ; et les réglages du manifeste (permission [INTERNET], HTTP en clair). Du côté de l’interface, Compose rend le code plus court que Flutter : des fonctions plutôt que des classes, et des états observés automatiquement plutôt que [setState(...)] et [notifyListeners()].

7.2. Ce qui reste hors périmètre ou à porter

7.2.1. L’internationalisation français/anglais - traitée dans ce document

Le document original proposait de basculer l’interface entre le français et l’anglais, à l’aide de la bibliothèque angular-translate. Ce portage reprend cette fonctionnalité avec [TranslationsService] (cf. chapitre 4) et les dictionnaires [fr.json]/[en.json] des autres variantes, embarqués dans le dossier [assets/] de l’application. Comme ses prédécesseurs, il change de langue à la volée, sans relancer l’application.

7.2.2. Le mode « debug » du client - délibérément hors périmètre

Le document original incluait un mode d’affichage technique qui donnait accès au modèle brut de la vue courante. Ce portage ne le reconstruit pas : Android Studio offre aujourd’hui, en dehors de l’application, des outils bien plus complets - le débogueur, l’inspecteur de mise en page ([Layout Inspector], qui montre l’arbre des fonctions @Composable, leurs paramètres et le nombre de leurs recompositions) et le journal [Logcat].

7.2.3. Un délai réseau artificiel - reporté

Le document original permettait de régler un délai artificiel avant chaque réponse du serveur, pour observer le comportement de l’interface sur un réseau lent. Cette fonctionnalité n’a pas encore d’équivalent dans ce portage. L’émulateur Android permet toutefois de simuler un réseau lent ([Extended Controls / Cellular / Network type]).

7.3. Un mot sur la méthode suivie dans ce document

Le client de ce document a été compilé et exécuté par Claude lui-même, dans l’émulateur Android du poste du réviseur et avec son accord : chaque fonctionnalité a été testée (connexion avec les deux rôles, échec de connexion, choix du médecin et du jour, réservation, annulation, changement de langue, déconnexion, rotation de l’écran), et les captures du chapitre 4 ont été prises pendant ces tests. Ces essais ont fait apparaître deux problèmes, corrigés et documentés au chapitre 5 : l’adresse [10.0.2.2] injoignable sur ce poste, et un bouton tronqué sur l’écran étroit du téléphone.

7.4. Pour aller plus loin dès maintenant

  • ajouter un écran de détail d’un rendez-vous, pour découvrir la navigation entre écrans avec la bibliothèque [Navigation Compose] ;
  • afficher un indicateur de chargement ([CircularProgressIndicator]) pendant les appels au serveur, en ajoutant un état [enCours] à [AppViewModel] ;
  • remplacer [SharedPreferences] par [DataStore], l’API de stockage recommandée aujourd’hui, entièrement asynchrone (fonctions [suspend] et [Flow]) ;
  • écrire des tests : des tests unitaires de [decoderReponse(...)] ou de [TranslationsService.t(...)], puis des tests d’interface avec la bibliothèque [compose-ui-test] ;
  • relire le README de chaque dossier du client : chacun résume le rôle des fichiers qu’il contient.