BreizhCamp : Applications mobiles avec GWT 2.0 par Salvador Diaz
Pour cette session, Salvador DIAZ nous a fait une petite piqûre de rappel sur GWT : ses concepts, ce qu’il était et ce qu’il n’était pas, mais également les raisons pour lesquelles GWT était un bon choix pour le développement d’applications mobiles.
Je vous propose ici un résumé succinct de cette session, exposant le point de vue de Salvador sur le sujet
Généralités
Comme évoqué en introduction, la première partie de la session était plutôt axée sur un rappel sur GWT. En effet, alors qu’il est souvent résumé à “écrire du java et produire du javascript”, il ne faut pas omettre qu’il a principalement été conçu pour contourner les problèmes de compatibilité entre navigateurs tout en permettant de réutiliser au maximum le code, permettant ainsi aux navigateurs de ne re-télécharger que le nécessaire. Pour ce faire, GWT offre une API riche et puissante qu’elle soit bas-niveau (possibilité de manipuler le DOM, le Document, JSNI, HttpRequest, JSON) mais également une API plus haut-niveau (avec la possibilité de manipuler/développer des widgets, des composites et en offrant un UIBinder, un Editor, une communication RPC et JSO).
Au niveau de l’écosystème Java, GWT offre le support d’outils comme Eclipse, Maven, cobertura mais également de librairies et framework comme Guice, Guava, JUnit, JMock, Spring, Restlet.
A noter toute fois, que GWT n’est pas :
- Une solution miracle pour répondre aux incompatibilités entre navigateurs et nécessite une bonne connaissance de javascript.
- Une abstraction parfaite du navigateur.
- Swing dans le navigateur.
- Google puisque, par exemple, il existe de nombreux commiteurs non google mais également d’autres contributions comme Vaadin.
En plus de ces différents points, Salvador est revenu sur deux concepts de GWT à savoir la séparation qu’il existait entre :
- La navigation et le concept d’activity & place présent depuis la version 2.1 et où une activité représente un écran alors que la place son identifiant (ou pour faire plus simple son URL)
- La couche de présentation avec l’UIBinder et ses trois responsabilités : la disposition (View.UI.xml), le style (View.css) auquel il est possible d’ajouter de la logique (par exemple une css différente en fonction du navigateur) et le comportement (View.java) qui permet d’ajouter des handlers et du contenu.
GWT, un bon choix pour les applications mobiles?
Cette partie de la session de Salvador a abordée plus précisément le sujet principal de la présentation avec les raisons qui faisaient que GWT pouvait être un bon candidat pour le développement d’applications mobiles puisque, de par son mode de fonctionnement, il permettait une bonne optimisation pour la consommation mobile.
En effet, GWT nécessite peu d’aller/retour avec le serveur puisque seulement trois fichiers sont nécessaires cotés client :
- index.html qui pèse environ 1ko
- application.nocache.js qui pèse environ 8 ko (qui peut être compressé en 4 ko)
- [MD5].cache.html qui pèse environ 140 ko (qui peut être compressé en 45 ko)
En outre, le CSS pouvant être spécifique à chaque navigateur, il peut être optimisé. Les images peuvent quant à elles être directement traitées comme une donnée javascript évitant ainsi de nombreux accès au serveur.
En cas de besoin de communication avec un autre serveur, concernant les limitations de Same Origin Policy, il est possible, plutôt que de passer par un proxy sur le serveur, de jouer avec les exceptions qui existent sur les images, les scripts qui peuvent être rendu exécutable mais surtout d’utiliser JSonP qui permet de wrapper le JSon dans du javascript; permettant ainsi de traiter la donnée.
De plus, GWT est particulièrement bien adapté pour bénéficier des avancées de HTML 5 avec :
- le mode off-line en peuplant le contenu du fichier manifest aisément puisque seul trois fichiers sont transmis au client,
- la librairie gwt-mobile-webkit pour le web SQL qui offre une API à la iBatis (à utiliser avec parcimonie comme nous le conseil Salvador),
- le mode LocalStorage (qui sera inclus dans GWT 2.4) qui correspond à un stockage de type clé/valeur qui s’avère être plus simple qu’une utilisation directe à Web SQL.
Enfin, GWT permet d’utiliser n’importe quelle librairie javascript grâce à JSNI qui est une interface native à javascript mais également de bénéficier des avancées de CSS3 afin de diminuer les requêtes serveurs (par exemple, CSS3 permet de gérer nativement les ombres d’images alors qu’il serait nécessaire d’en utiliser de nombreuses sinon).
Conclusion
En conclusion de sa session, Salvador finit avec cinq points essentiels :
A l’heure du cloud, le CPU reste coûteux (passé un certain seuil, il faut payer sa consommation CPU…) et déléguer le traitement coté client peut être une solution.
- Les applications GWT peuvent être performantes et optimisés.
- HTML 5 rocks!
- Web SQL est une fausse bonne idée.
- Toute API Rest devrait supporter JSonP.
A noter que toutes les démos faites pendant la présentation de Salvador se trouvent aux urls ci-dessous :
Licence
Sauf mention contraire, le contenu de ce blog est mis à disposition selon les termes de la licence Creative Commons.