13. Conclusion

Nous avons écrit le client [Android] natif de l'application [RdvMedecins], en [Kotlin] et [Jetpack Compose]. Pour l'utilisateur, il offre les mêmes écrans que l'application HTML du cours [NestJS], que les clients [Vue.js], [Angular] et [React], et que le client [Flutter].

Le serveur, lui, n'a pas changé. Son API JSON, dont le contrat (routes, corps, codes et clés d'erreur) a suffi pour écrire le client sans jamais lire son code, sert indifféremment un navigateur et un téléphone. Une seule différence : sur le téléphone, il n'y a pas de navigateur pour garder le cookie du jeton, et c'est le client HTTP ([OkHttp] et son [CookieJar]) qui a joué ce rôle, en quelques lignes. La sécurité n'a pas bougé : c'est toujours le serveur qui authentifie, qui vérifie les rôles et les règles, et qui valide les formulaires.

Le lecteur qui a suivi le cours [Flutter] peut comparer :

• les deux reposent sur la même idée : l'interface est une fonction de l'état. Un widget [Flutter] a une méthode [build()] qui renvoie un arbre de widgets ; une fonction [@Composable] APPELLE d'autres fonctions [@Composable]. Quand l'état change ([setState] / l'affectation d'un [mutableStateOf]), l'interface est recalculée ; [Compose] ne réexécute que les fonctions qui lisent l'état modifié ;
• [Flutter] dessine lui-même chaque pixel, avec son moteur, sur toutes les plates-formes ; [Compose] est la boîte à outils d'interface d'[Android] lui-même : l'application est plus légère, s'intègre naturellement au système (thème, langue, accessibilité, gestionnaire de mots de passe), et a accès directement à toutes les API d'[Android]. En contrepartie, elle ne tourne que sur [Android] ([Compose Multiplatform], de [JetBrains], permet de viser aussi l'iPhone, le bureau et le web) ;
• [Kotlin] et [Dart] sont deux langages typés, compilés, aux types non nullables, très proches. [Kotlin] apporte les classes [data] (et leur [copy]), les interfaces [sealed] et le [when] exhaustif, les extensions, les coroutines, la sérialisation écrite à la compilation ;
• sur [Android], l'activité est RECRÉÉE à chaque changement de configuration (rotation, langue) : il faut penser à ce qui doit survivre ([rememberSaveable], [ViewModel], la route de la navigation) ;
• l'écosystème de [Jetpack] fournit, en bibliothèques officielles, ce que [Flutter] demande à des paquets : la navigation, le [ViewModel], [DataStore], les tests.

Les notions rencontrées dans ce cours (fonctions [@Composable], état et recomposition, effets et cycle de vie, [CompositionLocal], [ViewModel] et [StateFlow], coroutines et [Flow], navigation et gardes, formulaires, ressources et langues) sont celles de toute application [Android] moderne. Pour aller plus loin :

• la documentation officielle, developer.android.com/compose, ses parcours de formation (« Android Basics with Compose ») et son guide d'architecture ;
• l'injection de dépendances avec [Hilt] (plutôt que l'objet [Application] et [LocalDependances]) ;
• [Retrofit], qui écrit la couche d'accès à l'API à partir d'une simple interface annotée ([@GET("medecins")]) ;
• les tests : les tests unitaires (le réducteur de l'exemple 06, les règles de l'exemple 07), et les tests instrumentés de [Compose] qui pilotent l'application sur un émulateur (c'est avec eux qu'ont été faites les copies d'écran de ce document, cf. annexes) ;
• [Room], la base de données locale, pour une application qui fonctionne hors connexion ;
• [Compose Multiplatform], pour réutiliser ce code sur l'iPhone et le bureau.