Tutoriel pour faciliter le développement d'applications Web hors-ligne en Java avec GWT

Outre le besoin des applications web de survivre à des déconnexions intempestives, on trouve aussi d'autres intérêts à la conception d'applications hors-ligne. En effet, le standard HTML5 permet de développer aujourd'hui des applicatifs réservés auparavant au monde « natif ». On trouve dans ce standard nombre de concepts historiquement liés aux systèmes d'exploitation et qui n'étaient jusque là pas accessibles aux applications web :

• stockage de données local ;
• stockage de l'application pour permettre son exécution hors-ligne ;
• système de fichiers ;
• un modèle d'exécution enrichi avec les Worker threads ;
• un modèle de connectivité également enrichi : Web sockets, WebRTC ;
• l'accès au matériel : Web GL, Audio, etc. ;
• et aux périphériques (webcam, microphone, gps…).

Il y a donc une niche d'applications qui peuvent maintenant être implémentées sur la plateforme Web. Et ces applicatifs n'ont pas nécessairement l'utilité d'une connexion à Internet. L'avantage de la plateforme Web est son universalité et ses performances croissantes. Un seul code écrit pour cette plateforme peut s'exécuter sur 99 % des terminaux : quel terminal aujourd'hui ne propose pas de navigateur Web moderne ?

Cette universalité permet de considérablement réduire les coûts de conception, de développement et de maintenance d'un logiciel, tout en ciblant un nombre toujours croissant d'utilisateurs, avec des performances largement acceptables dans la plupart des cas.

Je tiens cependant à prévenir le concepteur et le développeur : implémenter ce nouveau paradigme d'applications hors-ligne aura un coût non négligeable au départ.

• L'architecture du code sera différente de l'architecture client/serveur à laquelle nous sommes habitués.
• De nouvelles problématiques (parfois complexes) feront surface et les résoudre sera également une difficulté, car aujourd'hui aucun framework ne prend en charge l'intégralité de la pile applicative nécessaire au déploiement des applications hors-ligne.

Parmi les problématiques que l'on aura à traiter, on trouvera : la tolérance aux pertes partielles ou totales de connexion, la synchronisation de référentiels de données, la gestion des conflits, etc. Ainsi il sera essentiel à qui veut se lancer dans le développement de telles applications de cerner le plus précisément possible le périmètre fonctionnel lié à la gestion de la vie hors-ligne de l'application afin de réduire les coûts et les risques au maximum en amont du développement.

Nous nous trouvons dans une étape transitoire et il y a fort à parier que les outils qu'il nous manque aujourd'hui seront développés par les pionniers des applications hors-ligne.

Au fil de cet article, l'outil de développement que nous utiliserons pour programmer la partie cliente de l'application sera Google Web Toolkit. Celui-ci nous permettra de développer des applications complexes en Java et de faire levier sur la plateforme HTML5 de façon puissante. Bien sûr les applications hors-ligne ne requièrent pas l'utilisation d'un outil spécifique et il est tout à fait possible de développer ces applications directement en JavaScript. Voilà quelques éléments intéressants à noter à propos de GWT :

• c'est un projet open source, initialement créé en 2006 chez Google, qui a depuis pris son envol et dont un comité de pilotage indépendant intégrant les acteurs majeurs de GWT assure désormais la gouvernance ;
• GWT est supporté par une communauté vaste et active ;
• il a été téléchargé plus d'un million de fois ;
• nous permet de partager du code entre client et serveur (dans le cas où le serveur est écrit en Java bien sûr). C'est un point crucial pour les applications hors-ligne, car une couche d'accès aux données sera implémentée sur le client ;
• la plupart des API HTML 5 sont prises en charge ;
• il intègre une bibliothèque nommée « Elemental » qui permet de prendre en compte rapidement et facilement les évolutions HTML5 ;
• à l'instar de JNI sur la JVM, le JSNI nous permet de nous interfacer efficacement avec la plateforme sous-jacente à l'exécution du code Java : le monde JavaScript.

I-C-1. La philosophie de GWT▲

Le cache d'application est la fonctionnalité qui permet de demander au navigateur de stocker certains fichiers en avance à partir du serveur afin de les rendre disponibles pour l'exécution de l'application lorsque la connexion au serveur est indisponible.

Ceci se fait par deux éléments.

• L'ajout du tag « manifest » à la balise HTML de la page principale de l'application. La valeur de ce tag contiendra une référence au fichier décrit ci-dessous.
• La mise à disposition de ce fichier manifest qui contient le nom des ressources que le navigateur doit mettre en cache. Ce fichier doit impérativement être décrit avec le type MIME « text/cache-manifest ».

Quand le navigateur rencontre le tag manifest, il commence à télécharger toutes les ressources décrites dans le fichier spécifié. Lorsque la connexion au réseau est indisponible, le navigateur se servira des ressources ainsi mises en cache pour présenter à l'utilisateur la page en question, et ceci sans qu'il ne se rende compte de rien. C'est-à-dire que pour l'utilisateur, l'application se charge exactement de la même façon, qu'Internet soit connecté ou pas.

Le navigateur gère également la vie du cache. Il vérifie périodiquement si une nouvelle version du fichier manifest est disponible et le cas échéant met à jour le contenu de son cache.

Cette API permet aussi de s'abonner aux événements liés à la gestion du cache – tels que sa mise à jour par exemple, ou encore la terminaison de celle-ci. Cette API permet donc une gestion assez fine de la dynamique du cache et il devient par exemple possible de prévenir l'utilisateur qu'une nouvelle version de l'application est disponible, ou bien de demander explicitement au navigateur de vérifier la présence d'une mise à jour.

Pour plus de détails sur l'API Application Cache, je vous conseille de vous reporter au lien suivant : http://www.html5rocks.com/en/tutorials/appcache/beginner

II-A-1. Cache d'application - GWT▲

// S'exécute dans le contexte de la compilation  
@Shardable  
@LinkerOrder( Order.POST )  
public class AppCacheLinker extends AbstractLinker {  
 ...  
 @Override  
 public ArtifactSet link(LinkerContext context, … ) {  
  for( Artifact artifact : artifacts )  
   sb.append( artifact.getPartialPath() );  
  
  emitString( logger, sb.toString(), context.getModuleName() + ".appcache" );  
 }  
}

II-A-2. Intégration de l'API du cache en GWT avec JSNI▲

public enum AppCacheEvent {
 // Application en cache
 CACHED, 
 // Vérification en cours
 CHECKING, 
 // Téléchargement en cours
 DOWNLOADING, 
 // Une erreur s'est produite
 ERROR, 
 // Pas de mise à jour
 NOUPDATE, 
 // Le fichier manifest n'existe plus
 OBSOLETE, 
 // Mise à jour en cours
 PROGRESS, 
 // Mise à jour prête à être déployée
 UPDATEREADY;
}

public final class AppCache extends JavaScriptObject {
 // call Javascript from Java
 public static final native AppCache get() /*-{
  return $wnd.applicationCache;
 }-*/;

 // launch an app cache update
 public final native void update() /*-{
  this.update();
 }-*/;

 public interface Callback {
  void handleEvent( AppCacheEvent event );
 }

 // register to App Cache events
 public final native void registerEvents( Callback callback ) /*-{
  this.addEventListener('cached', function( s ) {
   // Call Java from Javascript
   callback.@package.AppCache.Callback::handleEvent(Lpackage/AppCacheEvent;)(@package.AppCacheEvent::CACHED);
  } );

  // inscription aux autres événements...
 }-*/;
}

Non contents de pouvoir exécuter notre application sans connexion Internet, il va maintenant falloir que celle-ci puisse accéder à ses données localement (pourvu bien sûr qu'elles aient été rapatriées sur le poste client lors d'une connexion antérieure…). Les données de l'application seront bien sûr persistantes au-delà du rechargement de l'application, et du redémarrage du navigateur.

II-B-1. Conserver localement les données dans le navigateur de l'utilisateur▲

J'aimerais illustrer grâce à la problématique de l'authentification un aspect très agréable de GWT. En préalable, je vous rappelle d'abord que l'espace de stockage local n'est absolument pas sécurisé. N'importe quelle personne équipée d'un outil de débogage du navigateur (Firebug par exemple) peut très facilement extraire les données que vous avez stockées pour l'utilisateur. Il en va donc naturellement que pour authentifier un utilisateur en mode déconnecté, vous aurez à stocker localement une donnée chiffrée (son mot de passe salé et chiffré en SHA-1 par exemple – l'algorithme de chiffrement dépendra bien sûr de la sensibilité des données et du niveau de protection que vous souhaitez fournir à l'utilisateur).

Partons pour l'exemple du principe que vous allez stocker le mot de passe de l'utilisateur chiffré par l'algorithme SHA-1. Il vous faut donc trouver une bibliothèque implémentant SHA-1, ou bien l'implémenter vous-même, ce qui n'est pas vraiment conseillé.

Et c'est ici que GWT trouve un réel avantage par rapport à JavaScript : la quantité de bibliothèques open source disponibles en Java est énorme, et pour peu que vous trouviez celle qui vous plaît, il ne vous restera en général qu'à copier le code source en question dans votre projet. Il sera ensuite transformé en JavaScript par le compilateur GWT de façon transparente. Attention tout de même, ceci n'est possible que si la bibliothèque en question n'utilise pas de fonctions « interdites » en GWT comme l'introspection, les threads, etc. Dans de tels cas, un effort de portage sera nécessaire. Lors de la réalisation d'un POC pour une application supportant le mode déconnecté, il m'a suffi d'à peine dix minutes pour trouver une bibliothèque SHA-1 écrite en Java qui me semblait assez solide (merci ganymed-ssh-2), et pour l'intégrer dans mon projet GWT. J'avais alors à disposition côté client la méthode souhaitée, à savoir :

String shaEncoded = sha.digest( String clearString );

Lorsque je parlais de fonctionnalités évoluées de stockage et d'interrogation des données requises pour le développement de notre pile applicative, je n'aurais pas rêvé mieux qu'un moteur SGBD relationnel SQL.

Partant de la constatation que seul le Local Storage était disponible pour la persistance des données, il fallait alors imaginer soit implémenter un moteur de base de données (quelques années de développement), soit se contenter d'une sérialisation basique et d'interrogations des données sous forme de parcours en « brute-force » de nos collections de données. Un moteur SQL disponible en quelques lignes de code. Vous allez voir, c'est exactement ce dont nous allons disposer !

Vous connaissez peut-être l'excellent JBoss ERRAI, un projet très intéressant et ambitieux qui vise (entre autres) à implémenter intégralement la norme JPA pour le framework GWT. Je vous invite à vous informer au sujet de ce projet, néanmoins, il reste encore peu mature (sur le sujet du stockage local), et nombre de requêtes (même des jointures simples) ne sont toujours pas implémentées (et ne le seront sans doute jamais, ce que l'on comprend si l'on s'intéresse à l'architecture de cette bibliothèque – c'est mon avis).

La bibliothèque que je veux vous présenter s'appelle SQL.JS. De quoi s'agit-il exactement ? Et bien c'est tout simplement l'équivalent en JavaScript de la très célèbre implémentation SQLite écrite en C. Si vous ne connaissez pas SQLite, sachez que vous l'utilisez régulièrement, cette implémentation étant intégrée à la plupart des navigateurs, à Android, à IOS, etc. En fait c'est tout simplement le moteur SGBD le plus déployé de la planète (environ 500 millions de déploiements). Cette information peut sembler être un pur argument marketing, mais c'est en fait un gage de qualité : cette bibliothèque est très fiable et son code très stable et performant.

Comment donc cette base de code en C peut-elle se retrouver « convertie » en JavaScript ? Et bien, cela est possible grâce à un outil que j'adore : le compilateur emscripten, écrit par Alon Zakai. Pour ne pas rentrer dans les détails, je dirai simplement qu'emscripten est un cross-compilateur de C vers JavaScript basé sur l'infrastructure de compilation LLVM, je vous invite à vous informer sur ces sujets.

Ce qui compte pour nous, c'est que nous avons à disposition un fichier JavaScript qui contient le code de SQLite, avec une API très simple permettant d'exécuter n'importe quelle requête SQL, et de récupérer les résultats des requêtes sous forme de données JSON.

L'API de SQL.JS étant en JavaScript, il va encore nous falloir écrire un peu de code JSNI pour interfacer notre code Java avec, ce qui sera très court :

public class SQLite extends JavaScriptObject {
 // crée une instance SQLite initialisée à partir des données d'un fichier SQLite
 public static final native SQLite open( JsArrayInteger data )
 /*-{
  return $wnd.SQL.open(data);
 }-*/;
 
 // exécute une requête SQL et renvoie son résultat sous forme d'un objet JSON
 public final JSONObject execute( String statement )
 {
  JavaScriptObject jso = _execute( statement );
  return new JSONObject( jso );
 }

 private final native JavaScriptObject _execute( String statement )
 /*-{
  return this.exec(statement);
 }-*/;

 // exporte les données de la base sous forme de fichier SQLite
 public final native JsArrayInteger exportData()
 /*-{
  return this.exportData();
 }-*/;

 // ferme l'instance de la base de données
 public final native void close()
 /*-{
  this.close();
 }-*/;
}

Nous avons à dispositions toutes les méthodes dont nous avons besoin.

• open( data ) permet d'initialiser une instance du moteur SQLite avec les données correspondant au contenu d'un fichier SQLite – une sauvegarde de la base de données que nous aurons stockée bien sûr, dans le Local Storage. Vous pourrez noter ici un point très important : les données qu'utilise SQL.JS sont en tout point identiques à celles utilisées par SQLite. C'est-à-dire qu'il sera tout à fait possible d'exporter une base de données SQL.JS pour la lire avec SQLite. Inversement, il est possible de lire avec SQL.JS une base de données SQLite. Une démonstration de ce point peut être trouvée ici.
• exportData() nous renvoie un tableau d'entiers correspondant à la l'enchaînement d'octets que vous trouveriez dans un fichier SQLite classique. Il ne nous restera qu'à le stocker dans le Local Storage pour persister l'ensemble de nos données.
• execute( statement ) nous permet d'exécuter nos requêtes SQL (et DDL) et d'obtenir les résultats correspondant sous forme de JSON.

Voilà, à partir de maintenant nous avons à disposition une pile applicative plus que correcte pour écrire nos applications hors-ligne. Allez, si vous n'aimez pas traiter avec le langage SQL directement (ce qui est compréhensible), quelques centaines de lignes de code suffiront à bâtir un miniORM vous permettant d'écrire par exemple :

List articles = db.query( "select {Article:a} " +  
 "from Article a " +  
 "left join Marque m " +  
 "where m.id=42" ).getResultList();

Ici nous obtenons une liste d'articles de la marque ayant pour identifiant 42 sous forme d'objets Java.

III-B-1. Des contrats de service homogènes▲

Nous allons maintenant entrer dans la problématique qui est pour moi la plus ardue de toutes celles que nous aurons couvertes ici, à savoir la synchronisation des données. C'est un problème extrêmement vaste, et auquel l'avènement des systèmes informatiques distribués et bases de données réparties (l'essence du « cloud » en fait) doit son salut.

En gros la complexité du problème à résoudre dépendra du niveau d'autonomie que vous voulez accorder à l'utilisateur lorsque l'application est en mode déconnecté. Peut-il simplement lire les données stockées localement ? Peut-il ajouter des données ? Peut-il même modifier les données existantes ? En supprimer ?

Toute la difficulté tient au fait que si vous autorisez l'utilisateur à modifier en mode déconnecté les données issues du serveur, le référentiel des données locales et celui du serveur vont commencer à diverger. Et au moment de la reconnexion, il faudra réconcilier ces deux référentiels, tout en respectant les liens causaux reliant les informations.

Explorons ces différents niveaux de difficulté.

III-C-1. Synchronisation descendante continue (accès hors-ligne en lecture seule)▲

III-C-2. Envoi des ajouts au serveur (accès hors-ligne en lecture et ajout)▲

III-C-3. Envoi des modifications au serveur (accès hors-ligne en lecture et écriture)▲