Evènements

DevFest 2012 : HTML 5 déconnecté

Publié le : Auteur: Florent DUPONT Laisser un commentaire
evenement

On commence ce début d’année avec une série d’articles en retour au DevFest 2012 qui a eu lieu à Nantes en novembre. Plusieurs articles autour de HTML, la mobilité, le Web et le Cloud font une retrospective sur les différents sujets de cette conférence et pour débuter une année 2013 sur le thème de l’innovation et des technos tendances…

HTML 5 en mode Offline ?

HTML 5 en mode déconnecté, cela peut paraître étonnant puisque l’on a tendance à penser les pages web comme étant fortement liées à une connexion réseau. Et pourtant, HTML 5 permet d’accéder à des applications tout en étant hors ligne.

Quel intérêt ?

  • Garder l’accès à un site en cas de coupure ou d’absence de connexion
  • Mise à jour des ressources (images, CSS, scripts) seulement si nécessaire
  • Optimisation du temps de latence (les ressources étant cachés en local le site s’affiche plus rapidement)
  • Saisie hors ligne et synchronisation ultérieure

L’idée derrière tout ça est de garder les ressources en local, mais également les données ! Le mode déconnecté, s’appuie sur 3 notions :

  • Application Cache
  • Client-side Storage
  • Navigator Online

Application Cache

L’application cache permet de stocker les ressources « physiques » d’un site. Cela rappelle évidemment le cache d’images existant, sauf qu’ici l’application cache va plus loin en cachant tout type de ressources : html, js, css, autres.
Il s’agit d’un cache maîtrisé et persistant (non, un Ctrl+F5 ne videra pas le cache applicatif !) définit au plus haut niveau de la page web, dans la balise <html> sous la forme d’un Manifest.
Ce manifest (nommé par convention manifest.appcache et qui doit suivre un type MIME spécifique) définit différentes règles dont les plus importantes :

  • Quelles ressources mettre dans le cache ?
  • Quelles ressources aller chercher sur le serveur ?

Le cache met à jour les données seulement si le manifest change (on maintiendra un numéro de version dans le manifeste ; si celui-ci change, alors le fichier change et le navigateur le rechargera).

L’utilisation de cache applicatif a un intérêt même en mode connecté car il permet une amélioration des performances et une diminution de la charge serveur.

Client-Side Storage

Maintenant que nous avons nos ressources en mode déconnecté, il faut pouvoir stocker les données applicatives. La notion de « Client-side Storage » met à disposition une base de données locale cloisonnée par origine du site : protocole + sous-domaine + domaine + port.
Plusieurs solutions existent :

  • Lecture / ecritures dossier : FileReader / FileWriter
    … MAIS Seulement sous Chrome
  • Web SQL Database : Chrome, Opera, Safari, iOS, Android
    … MAIS pas sous Firefox ni IE et de plus, la spécification n’est plus maintenue.
  • IndexedDB : stockage de type NoSQL, asynchrone, transactionnel, idéal pour recherche.
    … MAIS pas disponible sous Chrome, FF, IE10

Beaucoup de solutions, mais existe-t-il une solution pérenne et standard ? Oui !

  • Web Storage : stockage de type clé-valeur, synchrone, stockage textuel, sans index (donc pas optimisé pour la recherche), compatible tous navigateurs, standard, simple d’utilisation.

Deux types de storage :

  • Session-storage : pour une session utilisateur
  • Llocal-storage : durée de vie globale

Malgré ses défauts apparents, il est possible de lui adjoindre d’autres API / frameworks pour :
– rendre asynchrone les accès (en plaçant les requêtes dans des WebSockets)
– faciliter la sérialisation en stringifiant du JSON (Librairie Lawnchair par exemple)

Attention quand même car ces données métiers doivent être limitées : LocalStorage impose une limite à 5 Mo !!!!

Navigator online

L’intérêt de l’application Web est de savoir quand elle est connectée et quand elle ne l’est pas, afin de gérer au mieux son flot d’exécution (par exemple, éviter les appels serveurs si le réseau n’est pas disponible, et dans ce cas stocker en local).
Une API du navigateur permet de savoir si l’on est en mode connecté ou pas. Le problème est que – bien que cette fonctionnalité soit spécifiée – elle n’est pas implémentée de manière uniforme sur les différents navigateurs…
On ne peut donc pas se baser de manière fiable sur cette information. Et quand bien même cette information serait fiable, il reste des questions à se poser :

  • Est ce que le fait d’être connecté au réseau m’assure d’avoir accès à Internet ?
  • Est ce que le fait d’avoir accès à internet m’assure d’accéder à mon serveur Web, à mon backend ?

Evidemment non.
Le mode « connecté » dépend donc avant tout de la disponibilité de mon backend. La solution à mettre en place, est donc de se créer un système de « ping » applicatif qui va vérifier de manière régulière que mon backend est toujours disponible pour se considérer en mode « connecté ».

Bonne pratique : il est préférable de penser avec une architecture « OffLine First ». Prévoir au plus tôt que son application Web sera accessible en mode déconnecté coûtera moins d’effort que de le prendre en compte après coup sur une application connecté, car elle nécessite de gros changement en terme d’architecture.

Plus d’informations sur ces sessions

DevFest 2012  site officiel

Les présentations de :

Les infos utiles et astuces en plus

Pour connaitre les fonctionnalités HTML 5 implémentées sous votre navigateur, vous pouvez vérifier sur Can I use ?

Pour détecter depuis JS si une fonctionnalité HTML 5 est implémentée par votre navigateur : Modernizr.

Si Internet Explorer n’implémente pas une fonctionnalité HTML 5, vous pouvez toujours intégrer Chrome sous la forme d’un plugin avec ChromeFrame !