Je pense utiliser Firebase pour écrire une application mobile à l'aide de PhoneGap et du cache d'applications HTML5.
Supposons que chaque utilisateur possède une liste d'éléments TODO. Si l'application est lancée alors que le téléphone est hors ligne, pourra-t-il charger les données de la session précédente et se synchroniser lorsqu'une connexion sera établie? Si tel est le cas, je me demande comment cela est mis en œuvre car je n'ai pas trouvé de référence à localStorage dans firebase.js.
La réponse courte est: pas encore.
Une fois qu'une application est connectée à Firebase, le client met en cache les données localement et peut accéder aux données pour lesquelles il existe un rappel "sur" en attente, même après la perte d'une connexion réseau. Cependant, ces données ne sont pas conservées sur le disque, le "mode hors connexion" ne fonctionnera que tant que l'application sera en cours d'exécution.
Un support complet hors ligne viendra dans le futur.
edit 2016: la prise en charge complète hors connexion est désormais possible pour les applications natives iOS et Android: https://www.firebase.com/blog/2015-05-29-announcing-mobile-offline-support. html
CouchDb (serveur) <=> PouchDb (client JS) est une alternative à Firebase qui résout ce problème pour les applications JS. Si vous avez implémenté une couche de service côté client propre Nice, le portage sur PouchDb devrait être relativement simple car il s'agit de bases de données NoSQL/JSON. CouchDb prend également en charge les vues de carte/réduction indexées.
PouchDb est une API Javascript qui implémente un client totalement déconnecté CouchDb. Il peut détecter et utiliser automatiquement stockage local, IndexDb ou WebSQL pour conserver de manière permanente les données locales en ligne ou hors ligne. L'API PouchDb peut être utilisée pour accéder à vos bases de données locales ou distantes (il suffit de changer l'URL) et de connecter une synchronisation complète ou une synchronisation filtrée entre les deux. Il existe de nombreux plug-ins PouchDb, exemples de code et une petite bibliothèque d'encapsuleurs utiles pour prendre en charge l'API de promesses Q d'AngularJS.
Avec PouchDb, vous pouvez démarrer votre application en toute sécurité en mode hors connexion, puis quelques jours plus tard, redémarrez-la et synchronisez toutes vos modifications de données CUD sur le serveur. Cela peut entraîner des collisions de mise à jour et CouchDb prend donc en charge le contrôle de version des enregistrements, conçu pour détecter et suivre ce problème. Par conséquent, vous aurez probablement besoin d'une logique côté serveur pour résoudre ces collisions. Ceci est inévitable pour les systèmes distribués avec une synchronisation hors ligne et une fonctionnalité clé de CouchDb. Je ne suis pas sûr que Firebase prenne en charge cette fonctionnalité MVCC.
PouchDb est essentiellement une réimplémentation d’Apache CouchDb, y compris son protocole de synchronisation. CouchDb et PouchDb sont bien testés, gratuits et open source. Être open source signifie qu'un serveur CouchDb peut également être déployé en tant que service Intranet - en option, synchronisation avec un service de cloud externe. Il existe un certain nombre de fournisseurs d'hébergement CouchDb.
L'équipe d'hébergement Cloudant d'IBM a récemment ajouté ses fonctionnalités de clustering BigCouch au projet Apache CouchDb 2.0 afin que vous puissiez désormais passer de Micro Db (PouchDb) => Serveur unique => Multi-maître (répliqué) => Big Couch en cluster/Geo en cluster. Contrairement à MongoDb, CouchDb prend en charge en toute sécurité le déploiement sur un seul serveur.
REMARQUE: PouchDb peut également se synchroniser sur CouchBase en utilisant le même protocole mais Couchbase! == CouchDb. C'est un produit commercial.
Une autre astuce intéressante est que PouchDb peut être exécuté dans un serveur NodeJS en remplacement de CouchDb. Je pense que ce n'est pas (encore) prêt pour une utilisation en production mais très pratique pour les tests unitaires. Voir express-pouchdb .
Lors de la migration vers CouchDb, vous devez prendre en compte le fait que son modèle de contrôle d'accès est plus limité. Ceci est en partie dû à son algorithme de réplication. Cet article de blog couvre cela en détail (mieux que le réel guide définitif).
En pratique, vous souhaiterez probablement utiliser WebSQL pour votre stockage PouchDB, car il fonctionne beaucoup mieux. - Voici les détails complets sur les adaptateurs de stockage
Il existe un nombre impressionnant de nouveaux bonus "Arbre de Noël" qui sortent toujours des portes de la communauté prolifique de PouchDb.
Une des meilleures caractéristiques de PouchDb est l’ensemble des sources ouvertes plugins (37) et des adaptateurs de cadre d’interface utilisateur (12).
Très vieille question, mais le problème persiste toujours. Je n'utilise Firebase que depuis quelques jours et je ne pouvais pas trouver de solution satisfaisante à ce problème, alors je pensais partager ce que j'avais fini par faire.
Au démarrage de l'application, je vérifie si je suis en ligne navigator.onLine
. Sinon, je lis à partir du stockage local et restaure le firebase ref à partir de celui-ci.
export const firebaseFromLocalStorage = (local, storeRef) => {
// assuming data is array
const localData = JSON.parse(localStorage.getItem(local)) || []
localData.map(obj => {
const key = obj['.key']
delete obj['.key']
storeRef
.child(key)
.set(obj)
})
}
Ensuite, procédez comme d'habitude. Lorsque l'application est en ligne, elle synchronise son état local avec le serveur, tout comme lorsqu'elle démarre en ligne et perd la connexion momentanément.
Bien entendu, cela implique que le stockage local doit être synchronisé avec votre référence de base firebase. Je le fais à chaque opération.
J'espère que cela t'aides