Entwicklung einer HTML5-Offline-Speicherlösung für iOS / Android im Jahr 2011


74

Das Problem:

Ich benötige eine geräteunabhängige (z. B. HTML5) Lösung zum Speichern und Abfragen von mehr als 250.000 Datenzeilen offline auf einem Gerät vom Typ Telefon oder Tablet (z. B. iOS / Android). Die Idee ist, dass ich Leute habe, die in abgelegenen Gebieten ohne zellulare Datenverbindung arbeiten und Abfragen zu diesen Daten ausführen und sie offline bearbeiten müssen. Teilweise wird es geostandortbasiert sein. Wenn sich also Assets in dem Gebiet befinden, in dem sie sich befinden (verwendet GPS), werden diese Assets angezeigt und können bearbeitet werden. Wenn sie ins Büro zurückkehren, können sie die Daten wieder mit dem Office-Server synchronisieren.

Der Grund, warum ich mich dem aus Sicht des Webstandards nähere, besteht im Grunde darin, Geld und Zeit zu sparen, indem ich es einmal in HTML5 schreibe und es dann plattformübergreifend funktioniert, anstatt es zweimal in Objective C und Java zu schreiben. Auch wenn Sie etwas schreiben, das plattformunabhängig ist, sind Sie nicht eingesperrt und gehen nicht mit dem Schiff unter, wenn alle zu einem neueren wechseln. Wir hatten eine ähnliche App für Windows Mobile 5 geschrieben, jetzt ist sie nutzlos, da diese Plattform tot ist.

Die Offline-Datenbank auf dem Gerät muss sein:

  • schnell (Antworten unter 2 Sekunden)
  • Führen Sie möglicherweise Verknüpfungen durch und haben Sie Beziehungen zu anderen Tabellen, die die Datenbank abfragen können
  • Wählen Sie Daten innerhalb eines bestimmten Bereichs oder Kriterien aus, z. B. durch x & y-Koordinate basierend auf dem GPS-Messwert.

Optionen:

Lokaler HTML5-Speicher:

Gut für kleine Datenmengen <5.000 Schlüssel / Werte. Sie können sogar Arrays / Objekte darin speichern, wenn Sie sie in JSON konvertieren.

Nachteile:

  • Bei mehr als 10.000 Zeilen verlangsamt der Browser selbst auf einem High-End-Computer das Crawlen.
  • Es können keine komplexen Abfragen an den Daten durchgeführt werden, um die gewünschten Daten abzurufen, da Sie den gesamten Speicher durchlaufen und manuell danach suchen müssen.
  • Einschränkungen mit der Speichermenge, die gespeichert werden kann

Web SQL-Datenbank:

  • Entspricht den Anforderungen.
  • Schnelle Ausführung einer Abfrage in 250.000 Zeilen (1-2 Sekunden)
  • Kann komplexe Abfragen, Verknüpfungen usw. Erstellen
  • Unterstützt von Safari, Android und Opera, funktioniert dies auch auf iOS- und Android-Geräten

Nachteile:

  • Ab November 2010 veraltet
  • Sicherheitslücke bei verzeichnisübergreifenden Angriffen. Kein wirkliches Problem, da wir kein Shared Hosting betreiben

IndexedDB:

Schlüssel- / Wertobjektspeicher ähnlich dem lokalen Speicher, außer mit Indizes.

Nachteile:

  • Langsame Ausführung einer Abfrage in 200.000 Zeilen (15 bis 18 Sekunden)
  • Komplexe Abfragen können nicht ausgeführt werden
  • Verknüpfungen mit anderen Tabellen sind nicht möglich
  • Wird von Haupttelefon- oder Tablet-Geräten, z. B. iPad / Android, nicht unterstützt
  • Standard nicht vollständig

Dies lässt die einzige Möglichkeit, die veraltete Web SQL-Methode zu implementieren, die möglicherweise nur für ein weiteres Jahr oder so funktioniert. IndexedDB und lokaler Speicher sind derzeit unbrauchbar.

Ich bin mir nicht sicher, wie Mozilla und Microsoft den Standard der Web SQL-Datenbank veraltet haben und warum das W3C dies zulässt. Angeblich haben sie einen Anteil von 77% am Desktop-Browser-Markt. Auf fortschrittlichen Mobilgeräten haben Mozilla und Microsoft nahezu keinen Einfluss, da Safari, Opera und Android über 90% des Marktanteils haben . Wie Mozilla & Microsoft bestimmen können, welcher Standard auf dem Mobilfunkmarkt verwendet werden soll, auf dem am wahrscheinlichsten Offline-Speicher verwendet wird, macht keinen Sinn.

In den Kommentaren von Mozilla, warum sie stattdessen mit IndexedDB arbeiten wollten, geht es hauptsächlich um 'Entwicklerästhetik' und sie mögen die Idee, SQL in JavaScript auszuführen, nicht. Ich kaufe es nicht.

  1. Derzeit ist der vorgeschlagene Standard minderwertig und eine äußerst grundlegende NoSQL-Implementierung, die langsam ist und nicht einmal die erweiterten Funktionen unterstützt, die Benutzer in einer Datenbank benötigen. Es gibt eine Menge Boilerplate-Code, um die Datenbank einzurichten und Daten herauszuholen, aber sie behaupten, dass die Leute darüber einige nette Abstraktionsbibliotheken schreiben werden, die erweiterte Funktionen bieten. Ab Oktober 2011 sind sie nirgends zu sehen.

  2. Sie haben den vorhandenen Web SQL-Standard, der tatsächlich funktioniert und in den wichtigsten Browsern für Mobilgeräte / Tablets implementiert ist, abgelehnt. Während ihr "neuer" und "besserer" Standard in den großen mobilen Browsern nicht verfügbar ist.

  3. Was sollen wir als Entwickler für die nächsten 3-5 Jahre verwenden, wenn die IndexedDB-Spezifikation möglicherweise standardisiert wird, mehr Funktionen hat, in den wichtigsten Browsern für Mobilgeräte / Tablets implementiert ist und es einige nette Bibliotheken gibt, die die Dinge einfacher machen?

Das W3C sollte den Standard der Web SQL-Datenbank parallel ausführen und nur die Probleme beheben. Es unterstützt bereits die wichtigsten mobilen Plattformen und funktioniert recht gut. Die Tatsache, dass Mozilla und Microsoft als die beiden Player mit der höchsten Desktop-Browser-Freigabe diesen Standard ausrangieren konnten, ist ziemlich zweifelhaft und könnte als Versuch angesehen werden, den Fortschritt auf den mobilen Webplattformen zu behindern, bis sie aufholen und anbieten können konkurrierende Lösungen gegen iOS / Safari und Android.

Zusammenfassend hat jemand eine Lösung für mein Problem, die für iOS / Android für Telefon / Tablet-Geräte funktioniert. Möglicherweise eine nette Wrapper-API, die mehrere Datenbankimplementierungen im Hintergrund mit Abfragefunktion verwenden kann und mit der Sie auswählen können, welche Datenbank Priorität hat. Ich habe Dinge wie Liegestühle gesehen, aber ich bin mir ziemlich sicher, dass Sie standardmäßig nur lokalen Speicher verwenden können und auf die anderen zurückgreifen. Ich denke, ich würde lieber Web SQL (standardmäßig) als die langsameren Optionen verwenden.

Jede Hilfe für eine Lösung sehr geschätzt, danke!


5
Gut geschriebener Artikel! Dies ist eine dieser Situationen, in denen die nativen Anwendungen zweifellos das Argument "native vs web app" gewinnen - aber ich weiß, dass Sie das nicht hören möchten. In diesem Fall ist Web SQL meines Wissens die beste Option - ich würde den Benutzer auch zwingen, Zeilen herunterzuladen, die für die Speicherorte relevant sind, an die er gehen möchte, im Gegensatz zur gesamten Datenbank -, wenn Sie der Meinung sind, dass sie möglicherweise irgendwo mit einem schrecklichen Update aktualisiert werden müssen Verbindung, ganz zu schweigen von der Geschwindigkeitssteigerung beim Durchsuchen eines DB 1/5 der Größe (unsicher auf der Skala Ihres DB)
amcc

2
Sie können die Probleme mit WebSQL nicht einfach beheben, da eine der Anforderungen für den Standard, der zum W3C-Empfehlungsstatus übergeht, darin besteht, dass es unabhängige und interoperable Implementierungen gibt. Da die Spezifikation im Grunde "tun, was SQLite tut" lautet, wird dies niemals passieren.
Robertc

2
Hey, du hast gerade mein Abschlussprüfungsprojekt beschrieben :) Aus meiner Sicht gibt es zwei Möglichkeiten, wenn du Offline- und Abstiegsleistung benötigst. 1. Verwenden Sie den lokalen Speicher und reduzieren Sie die Daten auf die absolute Basis. oder 2. Erstellen Sie eine native App (mit einer skalierbaren Benutzeroberfläche?) und klonen Sie sie dann auf die andere Plattform (Sie haben bereits die Spezifikationen für die erste festgelegt, sodass es viel schneller ist, sie für die anderen Plattformen erneut zu entwickeln Nachteil ist, dass Sie mehr als eine pflegen müssen)
Michael Olesen

2
Denn bevor sie das verlangten, hatten wir W3C-Empfehlungen, die kein Browser tatsächlich implementierte. Alle drei Browser verwenden SQLite. Es gibt keine SQLite-Spezifikation, das ist einer der Gründe, warum es keine gute Basis für einen Standard ist.
Robertc

1
@robertc Wie meinst du, es gibt keine Spezifikation? Es basiert auf dem SQL92-Standard mit einigen geringfügigen Auslassungen . Ich habe diese Seite gefunden, die wie eine Spezifikation erscheint. Und was ist mit all den anderen Dokumentationen auf der SQLite-Website, die tatsächlich Teil der Spezifikation sind, nicht wahr? Was muss es sonst noch gültig sein?
zuallauz

Antworten:


18

Ich würde empfehlen, die JayData- Bibliothek zu besuchen , die genau den Zweck hat, eine speicherunabhängige Datenzugriffsschicht für mobile Geräte zu erstellen. JayData bietet eine Abstraktionsschicht mit Unterstützung für JavaScript Language Query (JSLQ) und JavaScript CRUD und lässt Sie mit verschiedenen Offline- und Online-Datenspeichertypen genauso arbeiten. JayData unterstützt den Umgang mit komplexen Entitäten und auch Entitätsbeziehungen entweder lokal oder remote.

Zum Zeitpunkt des Schreibens unterstützt JayData die folgenden Speicher oder Protokolle: webSQL (sqLite) / IndexedDB / OData / YQL / FBQL.

Ihr spezielles Problem mit verschiedenen Systemen, die unterschiedliche Speicher-Engines bereitstellen, kann mit der Provider-Fallback-Funktion von JayData leicht behoben werden: Es verwendet jede Speicherschicht, die es finden kann, und bietet dennoch dieselbe API für den Verbrauchercode.

In Bezug auf WebSQL, das bis 2012 veraltet ist: Zum Zeitpunkt des Schreibens ist es WebSQL, das immer noch eine Geräteabdeckung von 95% aufweist, einschließlich Samsung SmartTV und Amazon Kindle. Schauen Sie sich kindle an, das WebSQL-Unit-Tests mit JayData ausführt .


Ich bin damit einverstanden, dass die Unterstützung von JavaScript Language Query und das Anbietermodell die JayData-Bibliothek zu einer guten Option für die HTML5-Offline-Speicherlösung machen.

Update: JayData unterstützt jetzt auch HTML5 localStorage. Die JayData-Bibliothek führt den JSON-Stringify / Parse-Job aus und stellt eine saubere, einheitliche Datenverwaltungs-API und ein Konzept bereit.
Robesz

1
Ich würde gerne Ihre Antwort als die akzeptierte geben, da sie genau das klingt, was benötigt wird. Haben Sie jedoch Leistungsbenchmarks für eine große Datenbank, z. B. 250.000 Zeilen? Es würde mich interessieren, ob es so viele Zeilen verarbeiten kann, die sowohl den IndexedDB- als auch den WebSQL-zugrunde liegenden Speicher verwenden (je nach Gerät), und wie lange es dauert, eine grundlegende Abfrage vom Typ "Wo" durchzuführen, um eine der Zeilen anhand einiger Kriterien zu finden .
zuallauz

2
@zuallauz Ich habe gerade einen solchen Benchmark gemacht. Das Abrufen von 5-10 Artikeln von 250K-Artikeln dauerte 60 ms auf der Website mit einem Android-Nexus 2 und 25 ms auf einem Lumia 920 mit Windows Phone. (IndexedDB ist definitiv schneller).
Peter Aron Zentai

1
@zuallauz Da hast du recht, und wir werden es tun. IndexedDB ist in jeder Hinsicht viel schneller - mit Ausnahme komplexer Abfragen mit mehreren Feldern. Das Einfügen von Daten unter WebSQL kann jedoch langsam sein. Eine zum Schreiben geöffnete Transaktion kann kostspielig sein (60-120 ms).
Peter Aron Zentai

13

Ich würde CouchBase Lite auschecken. Es ist eine nahezu voll funktionsfähige Implementierung von CouchDB , die auf Android und iOS ausgeführt wird.

iOS

Android

Wenn Sie Ihre App in etwas wie PhoneGap verpackt haben, können Sie native HTML 5-Apps für beide Plattformen erstellen und müssen nur ein kleines Stück Android / iOS-spezifischer Programmierung durchführen, um CouchDB zu implementieren.

Vorteile:

  • Fast View-Engine zum Abfragen über viele Datenzeilen hinweg.
  • Dirt einfache und leistungsstarke Replikationsunterstützung eingebrannt.

Nachteile:

  • Key-Value Store - Es wird einige Zeit dauern, bis Sie sich daran gewöhnt haben.

Danke, hört sich so an, als könnte es funktionieren, aber Sie brauchen ein Mac-System, von dem ich glaube, dass es dafür entwickelt und die Schlüssel usw. produziert wird? Wir haben keine Macs.
zuallauz

CouchDB ist ziemlich interessant, aber ich bin nicht davon überzeugt, dass sein Modell, Indexaktualisierungen ("Ansicht") faul zu machen (ausgelöst durch eine Abfrage oder durch einen Stapelprozess), wirklich gut funktioniert. Die meisten Anwendungen, die ich gesehen habe, gehen davon aus, dass Daten nach dem Hinzufügen effizient abgefragt werden können und die meisten anderen NoSQL-Datenbanken mehr Arbeit in die Schreibtransaktionen stecken, sodass Lesetransaktionen schneller sind.
RichVel

@RichVel: Nach meiner Erfahrung waren die Ansichtsaktualisierungen auf den Mobilgeräten nie ein Problem. Einer der Hauptgründe für die Verwendung von CouchDB oder TouchDB ist jedoch die äußerst leistungsstarke und dennoch einfach zu verwendende Replikation.
Williams

1
Ich habe angefangen, CouchDB nach Replikation auf Mobilgeräten zu durchsuchen, wollte aber die Server-Datenbank nicht wirklich für Mobilgeräte verfügbar machen oder CouchDB auf dem Server verwenden, um die Replikation zu erhalten. Also schaue ich mir jetzt einen Datensynchronisations-Cloud-Dienst namens Simperium an, siehe simperium.com und simperium
RichVel

6

Ich habe weiter recherchiert und nach einer Lösung für mein eigenes Projekt gesucht. Es sieht so aus, als ob diese Bibliothek vielversprechend ist: http://nparashuram.com/IndexedDBShim/

Es ermöglicht die Verwendung der IndexedDB-API mit WebSQL hinter den Kulissen.

Die Tests bestehen auf dem neuesten iPad, iPhone 5 und Android 4.2.2.

Hoffe das hilft jemandem.


Spät zur Party, aber ich empfehle auch indexeddbshim.js. In einer Cordova / PhoneGap-Umgebung funktioniert es ziemlich gut, eine einzige Lösung für IOS und Android bereitzustellen.
Douglas Timms

2

Ich würde dir sagen, dass du Corona dafür verwenden sollst . Es handelt sich um eine private Plattform für mobile Anwendungen, die SQLite unterstützt.

Vorteile

  • Es ist einfach und hat eine große Unterstützung für SQLite und muss keine seltsamen Dinge mit HTML5-Speicher tun

Nachteile

  • Sie müssen dafür bezahlen, wenn Sie es im Android Market oder im iOS Market verwenden möchten.

Ich füge hier ein, was sie dazu sagen:

Corona unterstützt SQLite-Datenbanken auf allen Plattformen. Dies basiert auf der integrierten SQLite-Unterstützung auf dem iPhone und einer kompilierten Version von SQLite auf Android. Beachten Sie, dass dies die Größe der Android-Binärdatei um 300 KB erhöht.

SQLite ist in allen Versionen von Android, iPhone und iPad sowie im Corona Simulator verfügbar ...


2

"Ich habe Dinge wie einen Liegestuhl gesehen, aber ich bin mir ziemlich sicher, dass Sie standardmäßig nur lokalen Speicher verwenden können und auf die anderen zurückgreifen. Ich denke, ich würde lieber Web SQL (standardmäßig) als die langsameren Optionen verwenden . "

Dies ist konfigurierbar. Jeder der 'Adapter' für Speicher-Engines ist eigenständig. Sie können einen Adapter an den Lawnchair-Konstruktor übergeben oder alternativ die Reihenfolge ändern, in der er auf andere Speicheroptionen zurückgreift, indem Sie die Javascript-Dateien anders verketten, wenn Erstellen der Bibliothek. zB für indexed-db, dann auf sqlite zurückgreifen und dann sqlite schalten:

git clone https://github.com/brianleroux/lawnchair.git  
cd lawnchair  
cat src/Lawnchair.js src/adapters/indexed-db.js src/adapters/webkit-sqlite.js src/adapters/gears-sqlite.js > my_lawnchair.js

Natürlich können Sie, wie die anderen Antworten andeuten, Ihr HTML5 mithilfe von Phonegap usw. in eine native App einbinden. Dann haben Sie viele Optionen. Wenn Sie sich jedoch an Webstandards halten möchten, ist dies möglicherweise ein guter Weg, bis Wir haben eine breite Akzeptanz von IndexedDB.


1

Warum nicht eine einfache Speicher-Engine in Javascript schreiben (die den "standardbasierten" Teil abdeckt)? Anscheinend brauchen Sie nichts Besonderes, also sollte es nicht zu viel Mühe kosten, bis es funktioniert.

Ich würde folgendes tun:

  • Speichern Sie alles in bson oder einem ähnlichen Binärformat.
  • Analysieren und erstellen Sie Indizes in Dateien und lesen Sie diese beim Start.
  • Fragen Sie mit Javascript ab und lesen Sie aus der großen Datei Ihrer (offensichtlich offline) Webanwendung.
  • Aktualisierte Objekte separat speichern.

Diese Lösung ist nur möglich, wenn die Datenbank einfach genug ist. Aber ich denke, es könnte funktionieren - Javascript-Unterstützung ist auf Mobilgeräten gut.

Als Inspiration dient hier eine Btree + -Implementierung in Javascript.

Zum Lesen der lokalen Dateien benötigen Sie die Datei-API , mit der Sie auf lokale Dateien zugreifen können . Es wird in den meisten modernen Browsern unterstützt, sogar in Safari 6 . Ich konnte jedoch nicht feststellen, ob aktuelle iPhone-Browser diese API unterstützen.


Wie hat das JavaScript auf dem Telefon Zugriff auf das Lesen / Schreiben in / aus dem Dateisystem auf den Geräten?
zuallauz

1
Guter Punkt. Anscheinend ist die Datei-API nicht so weit wie es scheint, aber meine Antwort kann etwas zu optimistisch sein. CouchBase sieht aus wie eine sicherere Wette.
Alexanderfernandez

1

Es lohnt sich, meine Open-Source-Bibliothek https://bitbucket.org/ytkyaw/ydn-db/wiki/Home zu besuchen

Javascript-Datenbankmodul für Indexeddb-, WebDatabase- (WebSQL) und WebStorage- (localStorage) Speichermechanismen, die Versionsmigration, erweiterte Abfrage und Transaktion unterstützen.

Als NoSQL-Bibliothek ist der Beitritt manuell, aber nicht unmöglich. In der Bibliothek sind bereits wichtige Verknüpfungsalgorithmen integriert.


Wenn ich im Code eine SQL-Abfrage ausführen muss, um einige Daten abzurufen und zu sortieren, aber auf meinem Gerät IndexedDB ausgeführt wird, kann Ihre Bibliothek dann diese SQL-Abfrage konvertieren, die die Daten aus der IndexedDB-Datenbank abruft?
zuallauz

Die SQL-Unterstützung in meiner Bibliothek ist sehr einfach. Bitte sehen Sie hier, was es kann dev.yathit.com/ydn-db/sql-query.html
Kyaw Tun
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.