13. Conclusion

Nous avons écrit le client [Ionic] de l'application [RdvMedecins]. 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] des cours précédents ; c'est une application mobile, installée sur le téléphone, et c'est AUSSI, sans rien changer, une application web.

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. Sur le téléphone, il n'y a pas de navigateur pour garder le cookie du jeton : c'est le code natif d'[Android], par le greffon [CapacitorHttp], qui a joué ce rôle, sans une ligne de code dans l'application (le client [Flutter], lui, devait le faire avec sa classe [ClientAvecCookies]). La sécurité n'a pas bougé : c'est toujours le serveur qui authentifie, qui vérifie les rôles et les règles de gestion, et qui décide de ce qu'un patient a le droit de voir.

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 ; un composant [Angular] a un gabarit, qui lit des signaux. Quand l'état change ([setState] / un signal), l'écran est mis à jour. Avec les signaux, [Angular] sait même exactement quelles parties du gabarit dépendent de quel signal : il n'a rien à comparer ;
[Flutter] dessine lui-même chaque pixel, avec son propre moteur ; [Ionic] fabrique du HTML, que la WebView du téléphone (le moteur de [Chrome]) dessine. D'où une application web légère et naturelle (c'est une page web ordinaire), des outils de mise au point qui sont ceux du web (les outils de développement de [Chrome], sur l'ordinateur comme sur le téléphone), et un savoir-faire réutilisable (HTML, CSS, [TypeScript], [Angular]). La contrepartie : l'application dépend de la WebView du téléphone, et une interface très animée ou très chargée y est moins fluide qu'avec le moteur de [Flutter] ;
les composants d'[Ionic] imitent les composants natifs, dans deux modes, [md] ([Android]) et [ios] ([iPhone]) : la même application prend l'aspect de chaque système. [Flutter] fournit les deux familles de widgets ([Material] et [Cupertino]), mais c'est au développeur de choisir ;
[Angular] fournit beaucoup plus que [React], et à peu près autant que [Flutter] : routeur, formulaires, client HTTP, injection de dépendances, mise en forme ; [Ionic] ajoute les composants mobiles et la navigation en pile ; [Capacitor] l'accès au téléphone. Le client n'a eu besoin d'aucune autre bibliothèque. La mise en page, elle, se fait en CSS (les grilles et les classes utilitaires d'[Ionic]), là où [Flutter] utilise des widgets ([Column], [Row], [Padding]...) ;
[TypeScript], en mode strict, et la vérification stricte des gabarits ([strictTemplates]) détectent à la compilation la plupart des erreurs que détecte [Dart] : une valeur [null] oubliée, une propriété mal orthographiée, un argument du mauvais type. Mais les types de [TypeScript] disparaissent à l'exécution : un JSON mal formé n'est pas détecté à la réception, comme il l'était par le filtrage de [Dart] 3 ;
la contrepartie : deux fichiers par composant (la classe et le gabarit), un décorateur à remplir ([imports], [templateUrl]), et, entre [Angular], [Ionic] et [Capacitor], trois outils dont il faut connaître la part de chacun.

Les notions d'[Ionic] et d'[Angular] rencontrées dans ce cours (composants, signaux, gabarits, entrées et sorties, cycle de vie, injection de dépendances, directives, routeur et gardes, formulaires réactifs, [Promise] et [Observable], internationalisation, greffons de [Capacitor]) sont celles de toute application [Ionic]. Pour aller plus loin :

les documentations officielles : ionicframework.com/docs (la liste des composants, avec leurs propriétés et leurs exemples), angular.dev (son tutoriel et ses guides) et capacitorjs.com/docs ;
les tests : les tests unitaires d'[Angular] ([ng test], avec [Vitest]), qui manipulent un composant sans navigateur réel, et les tests de bout en bout ([Playwright], avec lequel ont été faites les copies d'écran de ce document), qui pilotent la vraie application dans un navigateur ;
les bibliothèques de gestion d'état ([NgRx] et son [SignalStore]), utiles quand l'état partagé devient très riche ;
les greffons de [Capacitor] : le stockage sécurisé du jeton, les notifications, l'appareil photo, la géolocalisation, le partage... : un greffon par besoin, officiel ou communautaire ;
les applications web progressives (PWA) : la version web de l'application, installable et utilisable hors connexion, avec le paquet [@angular/pwa] ;
l'iPhone : le même code produit une application [iOS] ([npx cap add ios]), à construire sur un [Mac] avec [Xcode] ; les composants d'[Ionic] y prennent d'eux-mêmes l'aspect d'[iOS] si l'on ne force pas le mode [md].