javascript 2011年为iOS/Android开发HTML5离线存储解决方案

Developing a HTML5 offline storage solution for iOS/Android in 2011

提问by zuallauz

The problem:

问题：

I need a device agnostic (e.g. HTML5) solution for storing and querying 250,000+ rows of data offline on a phone or tablet type device (e.g. iOS/Android). The idea being I have people working in remote areas without any cellular data connection and they need to run queries on this data and edit it while offline. Partly it will be geo-location based so if there are assets in the area they are in (uses GPS) then it will show those assets and let them be edited. When they return to the office they can sync the data back to the office server.

我需要一个与设备无关（例如 HTML5）的解决方案，用于在手机或平板电脑类型的设备（例如 iOS/Android）上离线存储和查询 250,000 多行数据。我的想法是有人在没有任何蜂窝数据连接的偏远地区工作，他们需要对这些数据运行查询并在离线时对其进行编辑。部分它将基于地理位置，因此如果它们所在的区域中有资产（使用 GPS），那么它将显示这些资产并让它们进行编辑。当他们返回办公室时，他们可以将数据同步回办公室服务器。

The reason that I'm approaching this from a web standard point of view is basically to save money and time by writing it once in HTML5 and then it works across multiple platforms rather than writing it twice in Objective C and Java. Also if you write something that's platform agnostic then you're not locked in and don't go down with the ship when everyone moves to a newer one. We had a similar app written for Windows Mobile 5, now it's useless as that platform is dead.

我从 Web 标准的角度处理这个问题的原因基本上是通过在 HTML5 中编写一次来节省金钱和时间，然后它可以跨多个平台工作，而不是在 Objective C 和 Java 中编写两次。此外，如果您编写的内容与平台无关，那么您就不会被锁定，也不会在每个人都搬到更新的地方时随船而沉。我们有一个为 Windows Mobile 5 编写的类似应用程序，现在它没有用了，因为那个平台已经死了。

The offline database on the device needs to be:

设备上的离线数据库需要是：

• fast (responses under 2 seconds)
• potentially perform joins and have relationships with other tables able to query the database
• select data within a certain range or criteria e.g. by x & y co-ordinate based on the GPS reading.

• 快速（2 秒内响应）
• 可能执行连接并与能够查询数据库的其他表建立关系
• 根据 GPS 读数选择特定范围或标准内的数据，例如通过 x 和 y 坐标。

Options:

选项：

HTML5 local storage:

HTML5 本地存储：

Fine for small amounts of data <5,000 key/values, you can even store arrays/objects in it if you convert it to JSON.

对于小于 5,000 个键/值的少量数据，如果将其转换为 JSON，您甚至可以在其中存储数组/对象。

Cons:

缺点：

• For more than 10,000 rows even on a high end machine the browser will slow to a crawl.
• Can't do complex queries on the data to pull out the data you want as you have to iterate through the whole storage and manually search for it.
• Limitations with the amount of storage that can be stored

• 即使在高端机器上超过 10,000 行，浏览器也会慢到爬行。
• 无法对数据进行复杂的查询以提取您想要的数据，因为您必须遍历整个存储并手动搜索它。
• 可以存储的存储量的限制

Web SQL Database:

网络 SQL 数据库：

• Meets the requirements.
• Fast to run a query on 250,000 rows (1-2secs)
• Can create complex queries, joins etc
• Supported by Safari, Android and Opera so will work on iOS and Android devices

• 符合要求。
• 快速在 250,000 行上运行查询（1-2 秒）
• 可以创建复杂的查询、连接等
• 受 Safari、Android 和 Opera 支持，因此适用于 iOS 和 Android 设备

Cons:

缺点：

• Deprecated as of November 2010
• Security flaw with cross-directory attacks. Not really an issue as we won't be on shared hosting

• 自 2010 年 11 月起弃用
• 跨目录攻击的安全漏洞。不是真正的问题，因为我们不会在共享主机上

IndexedDB:

索引数据库：

Key/value object store similar to local storage except with indexes.

键/值对象存储类似于本地存储，除了索引。

Cons:

缺点：

• Slow to run a query on 200,000 rows (15-18secs)
• Can't run complex queries
• Can't do joins with other tables
• Not supported by main phone or tablet devices e.g. iPad/Android
• Standard not complete

• 在 200,000 行上运行查询很慢（15-18 秒）
• 无法运行复杂查询
• 无法与其他表进行连接
• 不支持主要手机或平板设备，例如 iPad/Android
• 标准不完整

This leaves the only option of implementing the deprecated Web SQL method which may only work for another year or so. IndexedDB and local storage are unusable at present.

这留下了实现已弃用的 Web SQL 方法的唯一选择，该方法可能只能持续一年左右。IndexedDB 和本地存储目前无法使用。

I'm not sure how Mozilla and Microsoft got the Web SQL Database standard deprecated and why the W3C let it happen. Supposedly between them they have 77% of the desktop browser market. On advanced mobile devices Mozilla and Microsoft have nearly zero influence as Safari, Opera and Android have over 90% of the market share. How Mozilla & Microsoft can dictate which standard should be used in the mobile market which is where offline storage is most likely to be used doesn't make any sense.

我不确定 Mozilla 和 Microsoft 是如何弃用 Web SQL 数据库标准的，以及 W3C 为何允许它发生。据说他们之间拥有 77% 的桌面浏览器市场。在高级移动设备上，Mozilla 和 Microsoft 的影响几乎为零，因为Safari、Opera 和 Android 拥有超过 90% 的市场份额。Mozilla 和 Microsoft 如何规定在最有可能使用离线存储的移动市场中应该使用哪种标准没有任何意义。

In the comments from Mozillaabout why they wanted to go with IndexedDB instead are mainly about 'developer aesthetics' and they don't like the idea of running SQL in JavaScript. I'm not buying it.

在Mozilla关于他们为什么要使用 IndexedDB的评论中，主要是关于“开发人员美学”，他们不喜欢在 JavaScript 中运行 SQL 的想法。我不买。

1. Currently the proposed standard is inferior and an extremely basic NoSQL implementation that is slow and doesn't even support the advanced features people need in a database. There is a lot of boilerplate code to establish the database and get data out but they claim people will write some nice abstraction libraries over the top of it that will provide more advanced features. As of Oct 2011 they're nowhere to be seen.

2. They've deprecated the existing Web SQL standard which actually works and is implemented in the main mobile/tablet browsers. Whereas their 'new' and 'better' standard is not available in the major mobile browsers.

3. What are we as developers supposed to use for the next 3-5 years which is when the IndexedDB specification might get around to being standardised, have more features, implemented in the main mobile/tablet browsers and there's some nice libraries to make things easier?

1. 目前提议的标准很差，而且是一种非常基本的 NoSQL 实现，速度很慢，甚至不支持人们在数据库中需要的高级功能。有很多样板代码来建立数据库和获取数据，但他们声称人们会在它之上编写一些很好的抽象库，以提供更高级的功能。截至 2011 年 10 月，他们已无处可寻。

2. 他们已经弃用了现有的 Web SQL 标准，该标准在主要的移动/平板电脑浏览器中实际有效并实现。而他们的“新”和“更好”标准在主要的移动浏览器中不可用。

3. 我们作为开发人员应该在接下来的 3-5 年使用什么，那时 IndexedDB 规范可能会变得标准化，具有更多功能，在主要的移动/平板电脑浏览器中实现，并且有一些不错的库可以使事情变得更容易？

The W3C should keep the Web SQL Database standard running in parallel and just fix the issues. It already has support for the major mobile platforms and it works pretty well. The fact that Mozilla and Microsoft as the two players with the most desktop browser share were able to get this standard scrapped is pretty dubious and could be seen as an attempt to hinder progress on the mobile web platforms until they are able to catch up and offer competing solutions against iOS/Safari and Android.

W3C 应该保持 Web SQL 数据库标准并行运行并修复问题。它已经支持主要的移动平台，并且运行良好。Mozilla 和微软作为拥有最多桌面浏览器份额的两个玩家能够取消这个标准的事实非常可疑，可以被视为试图阻碍移动网络平台的进步，直到他们能够赶上并提供与 iOS/Safari 和 Android 竞争的解决方案。

In conclusion does anyone have a solution for my problem that will work for iOS/Android for phone/tablet devices. Maybe a nice wrapper API that can use multiple database implementations in the background with querying capability and it lets you choose which database has priority. I've seen things like lawnchairbut I'm pretty sure it only lets you use local storage by default and falls back to the to the others. I think I'd rather it used Web SQL (by default) then the slower options.

总之，是否有人对我的问题有解决方案，适用于手机/平板设备的 iOS/Android。也许是一个很好的包装器 API，它可以在后台使用多个具有查询功能的数据库实现，并且它可以让您选择哪个数据库具有优先级。我见过像lawnchair这样的东西，但我很确定它只允许你默认使用本地存储并回退到其他人。我想我宁愿它使用 Web SQL（默认情况下）而不是较慢的选项。

Any help for a solution much appreciated, thanks!

非常感谢任何对解决方案的帮助，谢谢！

采纳答案by Peter Aron Zentai

I would recommend checking out the JayDatalibrary, that actually has the exact purpose of creating a storage agnostic data access layer for mobile devices. JayData provides an abstraction layer with JavaScript Language Query (JSLQ)and JavaScript CRUD support and let's you work on the exact same way with different offline and online data store types. JayData supports dealing with complex entities and also entity relationships either locally or remotely.

我建议查看JayData库，它实际上具有为移动设备创建与存储无关的数据访问层的确切目的。JayData 提供了一个带有JavaScript 语言查询 (JSLQ)和 JavaScript CRUD 支持的抽象层，让您可以以完全相同的方式处理不同的离线和在线数据存储类型。JayData 支持在本地或远程处理复杂的实体和实体关系。

At the time of writing JayData supports the following stores or protocols: webSQL(sqLite)/IndexedDB/OData/YQL/FBQL.

在撰写本文时，JayData 支持以下存储或协议：webSQL(sqlite)/IndexedDB/OData/YQL/FBQL。

Your particular problem with different systems providing different storage engines can be easily addressed with the provider fallback feature of JayData: it will use whatever storage layer it can find while still provides the same API toward the consumer code.

使用 JayData 的提供者回退功能可以轻松解决不同系统提供不同存储引擎的特定问题：它将使用它可以找到的任何存储层，同时仍然为消费者代码提供相同的 API。

With regarding WebSQL being deprecated by 2012: at the time of writing it is WebSQL that still has a 95% device coverage including Samsung SmartTV and amazon Kindle. Check out kindle executing WebSQL unit tests with JayData.

关于 WebSQL 在 2012 年被弃用：在撰写本文时，WebSQL 仍然拥有 95% 的设备覆盖率，包括三星 SmartTV 和亚马逊 Kindle。查看使用 JayData 执行 WebSQL 单元测试的 Kindle。

回答by rwilliams

I would checkout CouchBase Lite. It's a near full featured implementation of CouchDBthat runs on Android and iOS.

我会检查 CouchBase Lite。它是一个近乎全功能的CouchDB实现，可在 Android 和 iOS 上运行。

iOS

IOS

Android

安卓

If you wrapped your App in something like PhoneGapyou could create native HTML 5 apps for both platforms and you'd only have to do a tiny bit of Android/iOS specific programming to implement CouchDB.

如果您将您的应用程序封装在PhoneGap 之类的东西中，您就可以为两个平台创建原生 HTML 5 应用程序，并且您只需要做一点 Android/iOS 特定的编程来实现 CouchDB。

Pros:

优点：

• Fast View engine for querying across many rows of data.
• Dirt simple and powerful replication support baked in.

• 用于跨多行数据查询的快速查看引擎。
• 简单而强大的复制支持已经融入其中。

Cons:

缺点：

• Key-Value Store - It'll take some time to get used to.

• 键值存储 - 需要一些时间来适应。

回答by KIR

I've made some more research while looking for a solution for my own project. It looks like this library is rather promising: http://nparashuram.com/IndexedDBShim/

在为我自己的项目寻找解决方案时，我进行了更多研究。看起来这个库相当有前途：http: //nparashuram.com/IndexedDBShim/

It allows to use IndexedDB API having WebSQL behind the scenes.

它允许在幕后使用具有 WebSQL 的 IndexedDB API。

It's tests pass on recent iPad, iPhone 5, Android 4.2.2.

它的测试在最近的 iPad、iPhone 5、Android 4.2.2 上通过。

Hope this helps someone.

希望这可以帮助某人。

回答by A.Quiroga

I would tell you to use Coronafor it . It's a private Platform used for crossed-mobile applications which has support to SQLite .

我会告诉你使用Corona。它是一个私有平台，用于支持 SQLite 的跨移动应用程序。

Pros

优点

• It's easy and has a big support for SQLite , and don't need to do strange things with Html5 storage

• 很简单，对SQLite有很大的支持，不需要用Html5存储做奇怪的事情

Cons

缺点

• you must pay for it if you wanna use it in the Android Market or the iOS Market.

• 如果您想在 Android Market 或 iOS Market 中使用它，则必须付费。

I paste here what they say about it:

我把他们说的贴在这里：

Corona includes support for SQLite databases on all platforms. This is based on the built-in sqlite support on the iPhone, and a compiled version of SQLite on Android. Note that this increases the size of the Android binary by 300K.

SQLite is available in all versions of Android, iPhone, and iPad, as well as in the Corona Simulator...

Corona 包括对所有平台上的 SQLite 数据库的支持。这是基于 iPhone 上的内置 sqlite 支持，以及 Android 上 SQLite 的编译版本。请注意，这会将 Android 二进制文件的大小增加 300K。

SQLite 适用于所有版本的 Android、iPhone 和 iPad，以及 Corona 模拟器...

回答by user1022475

"I've seen things like lawnchair but I'm pretty sure it only lets you use local storage by default and falls back to the to the others. I think I'd rather it used Web SQL (by default) then the slower options."

“我见过像 lawnchair 这样的东西，但我很确定它只允许你在默认情况下使用本地存储并回退到其他人。我想我宁愿它使用 Web SQL（默认情况下）而不是较慢的选项.”

This is configurable, each of the 'adapters' for storage engines is self contained, you can pass an adapter to the Lawnchair constructor, or, alternatively, change the order in which it falls back to other storage options by concatenating the javascript files differently when creating the library. e.g. for indexed-db then falling back to sqlite then gears sqlite:

这是可配置的，存储引擎的每个“适配器”都是自包含的，您可以将适配器传递给 Lawnchair 构造函数，或者，通过在以下情况下以不同方式连接 javascript 文件来更改它回退到其他存储选项的顺序创建库。例如对于 indexed-db 然后回退到 sqlite 然后齿轮 sqlite：

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

Of course, as the other answers suggest, you can wrap your html5 into an native app using phonegap etc. then you'll have plenty of options, but if you want to stick to web standards then this may be a good way to go until we've got wide adoption of IndexedDB.

当然，正如其他答案所建议的那样，您可以使用 phonegap 等将 html5 包装到本机应用程序中，然后您将有很多选择，但是如果您想坚持网络标准，那么这可能是一个好方法，直到我们已经广泛采用 IndexedDB。

回答by alexfernandez

Why not write a simple storage engine in javascript (which covers the "standards-based" part)? Apparently you don't need anything very fancy, so it should not take too much effort to have it working.

为什么不在 javascript 中编写一个简单的存储引擎（它涵盖了“基于标准”的部分）？显然你不需要任何非常花哨的东西，所以它不应该花太多精力让它工作。

I would do the following:

我会做以下事情：

• Store everything in bson or a similar binary format.
• Parse and create indexes in files, and read at startup.
• Query using javascript and read from the big file from your (offline obviously) web application.
• Store updated objects separately.

• 以 bson 或类似的二进制格式存储所有内容。
• 在文件中解析和创建索引，并在启动时读取。
• 使用 javascript 查询并从您的（显然是离线的）Web 应用程序中读取大文件。
• 单独存储更新的对象。

This solution is only feasible if the database is simple enough. But I think it might work -- javascript support is good on mobile devices.

这种解决方案只有在数据库足够简单的情况下才可行。但我认为它可能有效——javascript 支持在移动设备上很好。

For inspiration hereis a Btree+ implementation in javascript.

这里的灵感是在 javascript 中的 Btree+ 实现。

To read the local files you will need the file API, which can be used to access local files. It is supported in most modern browsers, even Safari 6. I have not been able to determine if current iPhone browsers support this API though.

要读取本地文件，您将需要文件 API，该API可用于访问本地文件。大多数现代浏览器都支持它，甚至Safari 6。不过，我无法确定当前的 iPhone 浏览器是否支持此 API。

回答by Kyaw Tun

It worths to check out my open source library https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

值得一看我的开源库https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

Javascript database module for Indexeddb, WebDatabase (WebSQL) and WebStorage (localStorage) storage mechanisms supporting version migration, advanced query and transaction.

用于支持版本迁移、高级查询和事务的 Indexeddb、WebDatabase (WebSQL) 和 WebStorage (localStorage) 存储机制的 Javascript 数据库模块。

Being NoSQL library, join is manual, but not impossible. There is already key joining algorithms build-in the library.

作为 NoSQL 库，join 是手动的，但并非不可能。库中已经内置了密钥连接算法。