Pour ce début d'année 2010, voici un nouvel article sur l'utilisation de GWT avancé. Cela concerne des techniques de programmation permettant de construire des applications GWT ambitieuse maitrisable ("Large Scale Application".

Les enjeux

Derrière ces articles techniques, il y a aussi des enjeux commerciaux.

L'impression de vitesse est très importante pour les tous les utilisateurs. Pour Driveo, c'est un critère discriminant dans le choix de la solution par rapports aux concurrents offline. Cela passe donc par la maitrise du premier chargement et donc la taille du fichier javascript généré par GWT.

L'agilité à corriger, maintenir et à faire évoluer l'application est aussi un facteur très différenciateur pour Driveo par rapport à la concurrence offline qui évolue plus lentement. Pour cela, la maintenabilité et la maitrise de la croissance d'une application doit passer des pratiques de conception le permettant.

Event Bus et MVP

Cette partie est la plus compliquée. Cependant, le paragraphe va être court. En effet, il y a la présentation donnée au normandy jug et surtout Google a surtout un article complet dessus.

Vous trouverez donc ma présentation au normandyjug qui évoque l'objectif de découplage des composants d'une application.

Enfin, l'équipe GWT a sortie un tutoriel nommé Large scale application development and MVP. Le code source de l'exemple est même disponible. L'exemple comprend même une utilisation de la gestion de l'historique avec GWT.

Le code de Driveo est cours de migration vers ces pratiques (20% sur Bus Events, 10% sur MVP). Les premiers avantage sont une diminution du code et meilleur maitrise de la maintenance.

Cependant, la migration en mode événementiel est à prendre avec des précautions car cela influence la conception complète de l'application. Il faudra veiller à éviter la prise en compte d'événement en double (par le bus events (nouveau code) et par listener/handler (ancien code)) car la localisation de prise en compte de l'évènement n'est pas la même.

Enfin, la partie la plus importante est le découplage des modules constituant l'application. Cela va permettre un code splitting plus efficace.

Code Splitting

Par le simple ajout de GWT.runAsync, dans l'embranchement principale de l'application (le menu, l'accueil, le tableau de bord), il est possible de reporter le chargement de certains modules en fonction du profil de l'utilisateur ou du module (si c'est un module peu fréquemment utilisé).

Le problème c'est que c'est efficace uniquement si les modules sont correctement découplés. On en revient donc aux pratiques de Bus Events et MVP.

Heureusement, pour pouvoir analyser ce découplage, l'équipe de GWT a ajouté l'analyse SOYC de votre code (SOYC = Story Of Your Compile). Cela vous permet, entre autre, d'avoir des rapports HTML qui permettent de savoir dans quel bloc de javascript compilés vos classes GWT se trouvent.

Pour cela, il faut ajouter les arguments " -compileReport -XsoycDetailed extra /path/path/report/application " à votre ligne de compilation. Attention, pour moi, avec ses options la compilation est passé de 9mn à 33mn! Il ne faut donc pas les laisser par défaut.

Pour conclure voici un graphique d'évolution de la taille de Driveo (Javascript compilé par GWT + CSS + noyau d'images) :