Discussion :

[Bovino]

Ludovic Chane Won In, de Ippon Technologies, vous propose un article : Une application HTML5 desktop en mode offline.

Dans cet article, l'auteur vous fait partager son retour d'expérience sur un projet d'application de type « desktop » en HTML5 utilisant l'API offline.

N'hésitez pas à faire part de vos remarques et commentaires voire d'apporter des informations complémentaires sur des problématiques similaires que vous auriez pu rencontrer lors de vos propres développements.

Une application HTML5 desktop en mode offline.

[SylvainPV]

Bon article

Une des problématiques que j'avais rencontrée avec une web app offline était qu'il fallait enregistrer les actions de l'utilisateur pour les synchroniser plus tard lorsque la connexion a été retrouvée.

Pour réaliser cela, j'ai créé une méthode Javascript destinée à tous les appels AJAX sortants, qui lorsque la requête échouait la plaçait dans une pile elle-même stockée dans le localStorage. Puis, toutes les 30 secondes, lorsque la pile n'est pas vide le script essaie de la vider en relancant dans l'ordre les requêtes (First In First Out).

Pour aller plus loin, il faut passer par un templating full client-side (c'est à dire générer toutes les pages en Javascript à partir de la data) de telle sorte que même si l'utilisateur est hors-ligne et la requête échoue, les pages peuvent encore être "mises à jour" avec les actions de l'utilisateur. A l'étape de synchronisation le modèle côté client ne change pas, ce qui fait que l'utilisateur passe du online au offline et vice-versa en toute transparence (bien que j'ajoute un signe disctinctif aux données encore non synchronisées)

Connaissez-vous d'autres moyens de gérer les actions utilisateur en hors-ligne et la synchronisation ?

[Invité]

bonjour

localStorage c'est vraiment pratique mais il est un problème qui n'est pas évoque c'est la façon dont est stoker ces donnés par le navigateur ou plutot les navigateurs car chaques navigateurs a son fichier de sauvegarde et contrairement aux cookies si je sauvegarde un fichier avec chrome il ne sera pas possible de le visualisé avec firefox et vice versa.

[Kaamo]

@mekal : Apparemment, dans l'article il est mentionné qu'ils ont utilisé Locache pour gérer les navigateurs n'implémentant pas le LocalStorage. La librairie propose aussi des outils afin de gérer l'écriture/la lecture de façon simple. (voir le lien)

Cela reste une appli pour une seule personne, qui n'a pas besoin de se resynchroniser avec le serveur derrière. Dommage, c'est le plus intéressant

Personnellement, j'utilise IndexedDB. localStorage étant synchrone, ça peut te bloquer le rendu du document tant que tout n'est pas chargé en mémoire. Sans parler des 5 Mo de limite, des données qui ne sont en fait que des chaines, du traitement stringify/parse redondant dont on aimerait bien se passer, de l'accès disque à chaque appel de localStroage (qui peut être long en cas d'antivirus qui check etc), du système non transactionnel / pas de concept d'index (donc pour chercher dans la base locale .... ) ... etc, Bref, localStorage, à part être plus simple d'utilisation qu'IndexedDB, je m'en éloigne autant que je le peux.
Mais oui, pour ce type d'application en exemple, ça semble suffisant mais t'es vite limité avec ça.

ps : A noter que Google Chrome Frame va bientôt mourir (ça date d'il y a moins d'une semaine)

Connaissez-vous d'autres moyens de gérer les actions utilisateur en hors-ligne et la synchronisation ?

Non, j'utilise la même technique à ceci près que c'est avec une IndexedDB et du websocket. Mais dans la logique c'est similaire. Un démon qui tourne toutes les X secondes pour checker la connexion et synchroniser si nécessaire et un "flag" pour différencier le "synchro" du "non-synchro". Bien sûr du templating côté client. Aussi, certaines actions sont impossibles à réaliser en offline, du coup c'est plus un mode "dégradé" qu'un mode déco.

[SylvainPV]

Oui l'IndexedDB mais depuis que j'ai un projet de 2 mois qui a été quasi-foutu à la poubelle à cause de l'abandon de l'API WebSQL, je me méfie Au moins le localStorage est supporté quasi partout et ce n'est pas prêt de changer

[Kaamo]

C'est clair que sur ce point, je n'ai rien à dire localStorage est beaucoup mieux supporté. Mais les "têtes pensantes" du Web s'orientent sur IndexedDB qui sera un standard W3C donc ne sera pas abandonné comme l'a été WebSQL. J'ai travaillé sur IndexedDB en me basant sur la spéc de mai 2012 et elle a évolué depuis peu (mai 2013).
Du coup, faut rester à la page pour ne pas que tout te claque entre les pattes. Mais c'est un peu le jeu quand tu utilises une techno en cours de stabilisation .. tu essuies les plâtres