We want to help developers like you. Tell us about how you work: http://qsurvey.mozilla.com/s3/Developer-Audience-Survey-V2/?s=mdn

Travaux hors-ligne

Cet article nécessite une relecture rédactionnelle.

Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

Créer des web apps ouvertes fonctionnant hors-ligne est un important problème à résoudre : les utilisateurs peuvent se retrouver hors-ligne lors de leurs déplacements. De plus, avoir des fichiers disponibles localement fera que votre application exécutera moins de requêtes au serveur et par conséquent sera plus fluide.

Cet article fournit des recommandations pour concevoir des applications hors-ligne aussi rapidement et facilement que possible, à travers des FAQs, des exemples et d'autres références en bas de page pour ceux ayant besoin d'informations détaillées sur le fonctionnement des technologies concernées tels que IndexedDB, localStorage, AppCache, XHR et bien plus.

Offline workflow

Le diagrame suivant illustre la manière typique de fonctionner d'une application hors-ligne. L'application est d'abord téléchargée/installée et ensuite démarrée — via le navigateur dans le cas d'une web app en ligne, et installée et lancée dans le cas d'une application installable (ex: sur Firefox OS.) A partir de là, la suite logique serait de stocker les assets et les ensembles de données initiaux de l'application sur l'appareil, après quoi l'application pourra être utilisée, stocker ses données hors-ligne et les synchroniser periodiquement avec celles du serveur.

Pour ses futures exécutions, l'application essayera de détecter si elle est en ligne ou non. Si c'est le cas , elle se synchronisera avec le serveur et téléchargera de nouvelles données et assets. Dans le cas contraire, elle continuera d'utiliser ses données actuelles hors-ligne.

Recommandations

Ce qui suit est un regroupement de recommandations et de bonnes pratiques pour mettre en place et exécuter hors-ligne des web apps rapidement.

Détecter la disponibilité du réseau

Il y a quelques APIs disponibles pour détecter l'accès de l'utilisateur au réseau. Elle sont particulièrement utiles car permettent de passer les requêtes HTTP is aucune connexion au réseau n'est détecté. Vous pouvez aussi afficher moins de messages d'erreur. Par exemple : si vous codez un client Twitter, un message comme “Les nouveaux tweets ne peuvent être chargés hors-ligne” est plus compréhensible que “Impossible d'établir une connexion HTTP.”

Essayez de ne charger des données depuis votre/toutes API seulement quand c'est nécessaire, et gardez les données en cache pour éviter de les charger à nouveau. En pré-chargeant certaines données, vous aiderez l'utilisateur à profiter de certaines parties de votre application hors-ligne.

navigatorOnline.onLine est conçu pour détecter le mode hors-ligne, mais ce n'est pas très sûr. Il existe de nombreux autres méchanisme de détection de mode hors-ligne, mais nous recommandons d'utilisant un librairie faite pour cela, comme offline.js.

Si vous utilisez XMLHttpRequest pour mettre à jour les données de façon dynamique, vous pouvez vérifier la réponse pour déterminer si la connexion à été coupée durant l'utilisation de l'application. Si votre application possède les privileges de systemXHR, vous pouvez vérifier que la connexion à un site est coupé durant une connexion active (iOS le fait avec Apple.com).

// We'll assume we aren't online.
var online = false;

// Assume we're a packaged app with systemXHR permissions.
// https://developer.mozilla.org/docs/Web/Apps/App_permissions
var request = new window.XMLHttpRequest({mozSystem: true});
request.open('HEAD', 'http://www.mozilla.org/robots.txt', true);
request.timeout = 5750;

request.addEventListener('load', function(event) {
   console.log('We seem to be online!', event);
   online = true;
});

var offlineAlert = function(event) {
   console.log('We are likely offline:', event);
}

request.addEventListener('error', offlineAlert);
request.addEventListener('timeout', offlineAlert);

request.send(null);

La première fois que votre application est chargée/installée, elle devrait enregistrer des assets et des données hors-ligne, comme indiqué ci-dessous. Aux chargement ultérieurs, elle devrait avoir un approche progressivement meilleure, puisque l'application est hors-ligne et travaille avec les données disponibles hors-ligne. Si elle est connectée, elle devrait mettre à jour les assets et les nouvelles données disponible.

Stocker des assets hors-ligne

Si vous distribuez votre application en tant qu'application empaquetée sur l'app store (par exemple une application Firefox OS, distribuée via le Marketplace Firefox), alors ce sera fait naturellement. Une fois l'application installée sur l'appareil, les assets seront sauvegardées localement (voir Packaged apps).

Si votre application est hébergée et vous voulez la rendre disponible en tant que web app ouverte et comme application installée sur Firefox OS, vous aurez besoin d'utiliser App Cache, qui suffit pour la plupart des cas, mais possède ses inconvéniants à prendre en compte. Le manifeste AppCache va typiquement lister tout le CSS, les polices, le Javascript, et les images que vous utilisez. Vous pouvez utilisez des outils pour générer votre manifeste ou le créer vous-même. Ceci est un exemple de format, provenant du manifeste de Face Value.

CACHE MANIFEST
# v 0.1 / 12

CACHE:
css/app.css
img/coins/gold@2x.png
js/main.js
js/lib/require.js

NETWORK:
*
http://*
https://*

Note: Si vous utilisez des templates JavaScript comme mustache, soyez sûr d'inclure vos templates dans le manifest AppCache ou precompilez-les dans vos fichier Javascript construits.

Important: Dans votre manifeste AppCache vous ne pouvez pas spécifier de ressources situées sur un différent domaine (même par redirection). Chrome vous laisse le faire tant que vous utilisez SSL, mais cela enfreint les spécifications, et d'autres navigateurs ne le font pas. Gardez ceci en tête si, par exemple, vous servez du contenu d'un CDN avec une origine différente.

Stocker des données hors-ligne

Pour démarrer rapidement avec des données hors-ligne nous vous recommendons d'utiliser localForage, une bibliothèque simple qui vous évite les différences de support entre navigateur pour les technlogies de données hors-ligne. Elle fournit un stockage de données asynchrone via IndexedDB pour les navigateurs qui le supportent. Il utilise ensuite WebSQL pour les navigateurs qui le supportent (comme Safari), et Storage pour les navigateurs avec seulement les suppots les plus basiques. ( Vous pouvez voir plus d'information de support)

localForage utilise une syntaxe proche de localStorage pour récupérer en envoyer des éléments de données:

localforage.getItem('key', function(value) {
        alert('My value is: ' + value);
    });
}
localforage.setItem('key', 'value', doSomethingElse);

Note: Pour plus d'information, lire comment utiliser localForage.

Note: L'API Device Storage est un option disponible sur Firefox OS pour stocker de gros éléments de données, mais IndexedDB (localForage) devrait fonctionner aussi. L'application de référence Podcasts utilise IndexedDB pour stocker les épisodes dans son model d'épisode.

Sauvegarder un état

Durant l'utilisation d'une application, vous devriez vous assurer que son état est sauvegardé de façon périodique pour les données hors-ligne, et sauvegarder l'état localement lorsque l'utilisateur ferme l'application.

Synchroniser coté serveur

Votre application devrait aussi sauvegarder ses données vers le serveur de façon périodique. Si votre application est hors-ligne vous devriez considérer une solution de file d'attente pour gérer un manque de connexion, pour préparer un mise à jour une fois le réseau de nouveau disponible. Nous travaillons sur un solution simple pour faire cela.

Code tier pour aider:

Exemples

Tutoriels

Si vous voulez en savoir plus sur comment localForage et les autres fonctionnent, ces tutoriaux devraient vous aider:

Référence

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : jbeuh, Ilphrin, maattt, slebourdon, Antoine, Caudralys
 Dernière mise à jour par : jbeuh,