5. Conclusion

Nous avons construit l'application client / serveur suivante :

Pour arriver à la version finale du code, nous avons du expliquer de nombreux points des frameworks AngularJS et Spring 4. Ce document peut donc être utilisé pour se former à l'utilisation de ces deux frameworks. Le paragraphe 1.3 explique où trouver les codes et comment les exploiter.

Nous avons montré que l'application client / serveur était utilisable dans divers environnements :

• comme une application web classique ;
• comme un binaire exécutable sur des émulateurs Android ;

Encore une fois, ce tutoriel n'est pas exhaustif quant à l'étude des deux frameworks. Pour Angular, il faudrait certainement présenter les outils de tests qui l'accompagnent. Les tests sont des étapes indispensables lors de l'écriture d'une application. Les outils qui gravitent autour d'Angular permettent de les automatiser et des inclure dans un processus d'intégration continue.

De ce travail, je retiendrai deux points :

• l'écriture du service web Spring a été moyennement compliquée. Dès le départ, je connaissais bien les concepts de Spring. Je n'ai rencontré de difficultés qu'avec la sécurisation du service web puis plus tard avec la gestion des entêtes HTTP CORS, deux domaines que je ne connaissais pas ;
• l'écriture du client Angular a été beaucoup plus complexe pour différentes raisons :
  • j'avais une connaissance insuffisante du langage Javascript et de ses possibilités ;
  • j'ai eu du mal à comprendre comment fonctionnait la programmation asynchrone au sein du navigateur. Je raisonnais comme sur un serveur où cet asynchronisme est obtenu avec l'utilisation simultanée de plusieurs threads. Dans le navigateur, il n'y a qu'un thread, et les tâches asynchrones sont traitées successivement et non pas en parallèle. Plus précisément, des tâches asynchrones peuvent s'exécuter en parallèle (requêtes HTTP multiples par exemple) mais les événements qu'elles produisent lorsqu'elles sont terminées, sont eux traités séquentiellement. Il n'y a donc pas d'excécution concurrente à gérer avec les nombreux problèmes qui vont avec ;
  • Angular est un framework riche avec de nombreuses notions (MVC, directives, services, portée des modèles, ...). Son apprentissage est long ;
  • Angular n'impose pas de méthode de développement. Ainsi pour arriver à un même résultat, on peut utiliser différentes architectures. C'est déroutant. Je suis plus à l'aise avec des frameworks fermés où tout le monde utilise les mêmes patrons de conception (design pattern). J'ai donc constamment cherché à reproduire les modèles de conception que j'utilise côte serveur. Je suis satisfait du résultat car je pense qu'il est reproductible. C'est ce que je cherchais. Mais je ne sais pas du tout si je me suis écarté ou non des « bonnes pratiques » d'Angular ;

Serge Tahé, juillet 2014.