Ho un'applicazione web offline che utilizza appcaching. Devo fornire circa 10 MB - 20 MB di dati che salverà (lato client) costituiti principalmente da file di immagine PNG. L'operazione è la seguente:

1. Download e installazione di applicazioni Web in appcache (utilizza manifest)
2. Richieste di app Web da file di dati PNG del server (come? - vedere le alternative di seguito)
3. Di tanto in tanto l'app web si risincronizza con il server ed esegue piccoli aggiornamenti / eliminazioni / aggiunte parziali al database PNG
4. FYI: il server è un server REST JSON, che può posizionare i file in wwwroot per il ritiro

Di seguito è riportata la mia attuale analisi dei "database" basati su client che gestiscono l'archiviazione BLOB binario

VEDI AGGIORNAMENTO in basso

• AppCache (tramite manifest aggiungi tutto il PNG e poi aggiorna su richiesta)
  • CONTRO: qualsiasi modifica di un elemento del database PNG significherà il download completo di tutti gli elementi nel manifest (davvero una brutta notizia!)
• WebStorage
  • CONTRO: Progettato per l'archiviazione JSON
  • CONTRO: può archiviare i BLOB solo tramite la codifica base64 (probabilmente un errore fatale a causa del costo della decodifica)
  • CONTRO: limite rigido di 5 MB per webStorage http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html
• PhoneGap e SQLLite
  • CONTRO: lo sponsor la rifiuterà come app nativa che richiede la certificazione
• file zip
  • Il server crea un file zip, lo inserisce in wwwroot e invia una notifica al client
  • l'utente deve decomprimere manualmente (almeno è così che lo vedo) e salvare nel file system del client
  • L'app Web utilizza l'API FileSystem per fare riferimento ai file
  • CONTRO: ZIP potrebbe essere troppo grande (zip64?), Molto tempo per la creazione
  • CONTRO: Non sono sicuro che l'API FileSystem possa sempre leggere fuori dalla sandbox (penso di sì)
• USB o scheda SD (indietro all'età della pietra ....)
  • L'utente sarà locale sul server prima di andare offline
  • Quindi potremmo fargli inserire una scheda SD, lasciare che il server la riempia con file PNG
  • Quindi l'utente lo collegherà al laptop, tablet
  • L'app Web utilizzerà l'API FileSystem per leggere i file
  • CONTRO: Non sono sicuro che l'API FileSystem possa sempre leggere fuori dalla sandbox (penso di sì)
• WebSQL
  • CONTRO: w3c l'ha abbandonato (piuttosto male)
  • Potrei considerare un wrapper Javascript che utilizza IndexedDB e WebSQL come riserva
• FileSystem API
  • Chrome supporta la lettura / scrittura dei BLOB
  • CONTRO: non è chiaro su IE e FireFox (IE10, ha msSave non standard)
  • caniuse.com segnala il supporto IOS e Android (ma ancora una volta, è solo r / w di JSON o include l'API blob completa per la scrittura?
  • CONTRO: Le persone di FireFox non amano l'API FileSystem e non è chiaro se supportano il salvataggio dei blob: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
  • PRO: molto più veloce di IndexedDB per i blob secondo jsperf http://jsperf.com/indexeddb-vs-localstorage/15 (pagina 2)
• IndexedDB
  • Buon supporto in IE10, FireFox (salva, leggi i blob)
  • Buona velocità e gestione più semplice rispetto a un file system (eliminazioni, aggiornamenti)
  • PRO: vedi test di velocità: http://jsperf.com/indexeddb-vs-localstorage/15
  • Vedi questo articolo sull'archiviazione e la visualizzazione di immagini in IndexedDB: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
  • CONTRO: Ho confermato che Chrome non supporta ancora la scrittura di blob (bug corrente, ma non è chiaro quando verrà risolto)
  • AGGIORNAMENTO: gli sviluppatori di Chrome confermano che stanno lavorando su questo sia per desktop che per Android! nessuna sequenza temporale ancora.
• Wrapper JavaScript LawnChair http://brian.io/lawnchair/
  • PRO: wrapper molto pulito per IndexedDB, WebSQL o qualsiasi database tu abbia (pensa a polyfill)
  • CONTRO: impossibile memorizzare BLOB binari, solo dati: uri (codifica base64) (difetto probabilmente fatale a causa del costo della decodifica)
• IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb
  • Parashuram ha scritto un bel wrapper JQUERY per l'interfaccia IndexedDB non elaborata
  • PRO: semplifica notevolmente l'utilizzo di IndexedDB, speravo di aggiungere uno shim / polyfill per Chrome FileSystemAPI
  • CONTRO: dovrebbe gestire i BLOB, ma non sono riuscito a farlo funzionare
• idb.filesystem.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
  • Eric Bidelman @ Google ha scritto un PolyFill ben collaudato API FileSystem che utilizza DB indicizzato come ripiego
  • PRO: FileSystem API è adatta per archiviare i BLOB
  • PRO: funziona alla grande su FireFox e Chrome
    • PRO: ottimo per la sincronizzazione con CouchDB basato su cloud
  • CONTRO: non è chiaro perché, ma non funziona su IE10
• Libreria JavaScript PouchDB http://pouchdb.com/
  • ottimo per sincronizzare un CouchDB con un DB locale (utilizza WebSQL o IndexedDB (non è un mio problema però)
  • CONTRO: NESSUN CONTRO, PouchDB ora supporta i BLOB binari per tutti i browser recenti (IE, Chrome, Firefox, Chrome su dispositivi mobili, ecc.) Così come molti browser meno recenti. Non è stato così quando ho scritto per la prima volta questo post.

NOTA: per vedere un dato: codifica uri di PNG ho creato un esempio su: http://jsbin.com/ivefak/1/edit

Caratteristiche desiderate / utili / non necessarie

• Nessuna app nativa (EXE, PhoneGap, ObjectiveC, ecc.) Sul client (applicazione web pura)
• Deve essere eseguito solo sull'ultimo Chrome, FireFox, IE10 per laptop
• Desidero fortemente la stessa soluzione per tablet Android (anche IOS sarebbe bello) ma per funzionare è necessario un solo browser (FF, Chrome, ecc.)
• Popolazione DB iniziale rapida
• REQUISITO: Recupero molto veloce delle immagini dall'applicazione web dalla memoria (DB, file)
• Non pensato per i consumatori. Possiamo limitare i browser e chiedere all'utente di eseguire impostazioni e attività speciali, ma riduciamolo al minimo

Implementazioni IndexedDB

• C'è un eccellente articolo su come IE, FF e Chrome implementano internamente questo a: http://www.aaron-powell.com/web/indexeddb-storage
• In breve:
  • IE utilizza lo stesso formato di database di Exchange e Active Directory per IndexedDB
  • Firefox utilizza SQLite, quindi implementa un database NoSQL nel database SQL
  • Chrome (e WebKit) utilizzano un archivio chiave / valore che ha eredità in BigTable

I miei risultati attuali

• Ho scelto di utilizzare un approccio IndexedDB (e polyfill con FileSystemAPI per Chrome fino a quando non viene fornito il supporto blob)
• Per il recupero delle tessere, ho avuto un dilemma dal momento che le persone di JQUERY stanno cercando di aggiungere questo ad AJAX
• Sono andato con XHR2-Lib di Phil Parsons, che è molto simile a JQUERY .ajax () https://github.com/pmp/xhr2-lib
• Prestazioni per download da 100 MB (IE10 4s, Chrome 6s, FireFox 7s).
• Non sono riuscito a far funzionare nessuno dei wrapper IndexedDB per i BLOB (sdraio, PouchDB, jquery-indexeddb, ecc.)
• Ho arrotolato il mio wrapper e le prestazioni sono (IE10 2s, Chrome 3s, FireFox 10s)
• Con FF, presumo che stiamo riscontrando il problema delle prestazioni dell'utilizzo di un DB relazionale (sqllite) per uno storage non sql
• NOTA, Chrome dispone di eccezionali strumenti di debug (scheda sviluppatore, risorse) per l'ispezione dello stato di IndexedDB.

Risultati FINALI pubblicati di seguito come risposta

Aggiornare

PouchDB ora supporta i BLOB binari per tutti i browser recenti (IE, Chrome, Firefox, Chrome su dispositivi mobili, ecc.) Oltre a molti browser meno recenti. Non è stato così quando ho scritto per la prima volta questo post.

Risultati Cache BLOB offline per mappe slippy PNG

analisi

• 171 file PNG (totale di 3,2 MB)
• Piattaforme testate: Chrome v24, FireFox 18, IE 10
• Dovrebbe funzionare anche con Chrome e FF per Android

Recupera dal server web

• utilizzando XHR2 (supportato su quasi tutti i browser) per il download di blob dal server web
• Sono andato con XHR2-Lib di Phil Parsons, che è molto simile a JQUERY .ajax ()
  • https://github.com/pmp/xhr2-lib

Conservazione

• IndexedDB per IE e FireFox
• Chrome: Polyfill (blob archiviato utilizzando FileSystem API, riferimento mantenuto in IndexedDB) polyfill
• Un articolo da leggere su "Come i browser memorizzano i dati IndexedDB"
  • http://www.aaron-powell.com/web/indexeddb-storage
• Nota: FireFox utilizza SQLlite per NOSQL IndexedDB. Questo potrebbe essere il motivo delle prestazioni lente. (blob memorizzati separatamente)
• Nota: Microsoft IE utilizza il motore di archiviazione estensibile:
  • http://en.wikipedia.org/wiki/Extensible_Storage_Engine
• Nota: Chrome utilizza LevelDB http://code.google.com/p/leveldb/

Schermo

• Sto usando Leaflet http://leafletjs.com/ per mostrare le tessere della mappa
• Ho utilizzato il plug-in Tile Layer funzionale di Ishmael Smyrnow per recuperare il Tile Layer dal DB
  • https://github.com/ismyrnow/Leaflet.functionaltilelayer
• Ho confrontato il layer di tile basato su DB con uno storage puramente locale (localhost: //)
• Non ci sono differenze evidenti nelle prestazioni! tra l'utilizzo di IndexedDB e dei file locali!

risultati

• Chrome: recupero (6.551 s), Store (8.247 s), tempo trascorso totale: (13.714 s)
• FireFox: Recupera (0.422s), Store (31.519s), Tempo trascorso totale: (32.836s)
• IE 10: Fetch (0.668s), Store: (0.896s), Tempo trascorso totale: (3.758s)

Per le tue esigenze suggerisco che lo sviluppo di un nuovo polyfill basato su altri due: FileSystem API to IndexedDB e IndexedDB to WebSQL - è l'opzione migliore.

Il primo abiliterà il supporto per l'archiviazione di BLOB in Chrome (FileSystem API) e Firefox (IndexedDB), mentre il secondo dovrebbe fornire il supporto per Android e iOS ( WebSQL ). Quello che serve è solo far lavorare questi polyfill insieme, e suppongo non sia difficile.

NB: Dal momento che non sono riuscito a trovare alcuna informazione sul Web in merito, dovresti verificare se l'archiviazione di BLOB utilizzando il polyfill WebSQL funziona su iOS e Android. Sembra che dovrebbe funzionare però:

var sql = ["CREATE TABLE", idbModules.util.quote(storeName), "(key BLOB", createOptions.autoIncrement ? ", inc INTEGER PRIMARY KEY AUTOINCREMENT" : "PRIMARY KEY", ", value BLOB)"].join(" ")

fonte

Ho esempi di memorizzazione nella cache delle mappe (esempio aperto, scopri regioni e zoom, passa offline e le regioni scoperte saranno disponibili).

Ci sono map.js- map layer per tile offline, storage.js- implementazione dello storage basata su IndexedDb e WebSQL (ma questo prova solo l'implementazione con scarse prestazioni).

• Per i file del sito (html, css, js e così via) preferisco usare la cache dell'applicazione.
• Per l'archiviazione preferisco usare Indexed DB (supporto blob), Web SQL (solo base64), FileWriter (supporto blob, ma solo chrome). Francamente l'archiviazione è un grosso problema per questo. Hai bisogno della soluzione di valore chiave più veloce che li mescoli tutti. Penso che sia una buona decisione usare la soluzione esistente.
• Per il recupero ho usato canvas con CORS. Ma penso a WebWorkers e XHR2 e questo può essere meglio invece canvas perché canvas ha alcuni problemi con CORS in browser diversi e altri (ad esempio questo titolo è stato memorizzato male in opera ).

Ulteriori informazioni sulle dimensioni per 2 miliardi di città ( Minsk ):

• Zoom - 9, piastrelle - 2, dimensione - 52 kb, con precedente - 52 kb;
• Zoom - 10, piastrelle - 3, dimensione - 72 kb, con precedente - 124 kb;
• Zoom - 11, tessere - 7, dimensioni - 204 kb, con precedente - 328 kb;
• Zoom - 12, tessere - 17, dimensioni - 348 kb, con precedente - 676 ​​kb;
• Zoom - 13, tessere - 48, dimensioni - 820 kb, con precedente - 1,5 mb;
• Zoom - 14, tessere - 158, dimensioni - 2,2 mb, con precedente - 3,7 mb;
• Zoom - 15, tessere - 586, dimensioni - 5,5 mb, con precedente - 9,3 mb;
• Zoom - 16, tessere - 2264, dimensioni - 15 mb, con precedente - 24,3 mb;

Alcuni anni fa (non esattamente l'età della pietra), stavo usando un'applet java firmata che interrogava il suo server per i requisiti di sincronizzazione / aggiornamento, scaricava i file appropriati dal server e li salvava sul filesystem dell'utente (non un database). Quella soluzione potrebbe funzionare per te, anche se avrai bisogno di qualcuno che scriva l'applet e la firmi. Per le soluzioni di database, tale applet può utilizzare il jdbc disponibile per la maggior parte dei database utilizzando localhost su una porta adatta (ad esempio, 3306 per MySQL). Credo che il tag dell'applet sia deprecato in Html5 ma funziona ancora. Nessuna esperienza su tablet Android, quindi non posso commentare quella parte.