Разработка решения для автономного хранения HTML5 для iOS / Android в 2011 году

Question

Проблема:

Мне нужно решение, не зависящее от устройства (например, HTML5), для хранения и запроса более 250 000 строк данных в автономном режиме на устройстве типа телефона или планшета (например, iOS / Android). Идея заключается в том, что у меня есть люди, работающие в удаленных районах без подключения к сотовой сети, и им нужно выполнять запросы к этим данным и редактировать их в автономном режиме. Частично это будет основано на географическом местоположении, поэтому, если в области, в которой они находятся (есть GPS), есть активы, то они отобразят эти ресурсы и позволят их редактировать. Вернувшись в офис, они могут синхронизировать данные с офисным сервером.

Причина, по которой я подхожу к этому с точки зрения веб-стандартов, заключается в том, чтобы в основном сэкономить деньги и время, написав один раз в HTML5, а затем он работает на нескольких платформах, а не дважды в Objective C и Java. Кроме того, если вы пишете что-то, что не зависит от платформы, то вы не заперты и не сходите с корабля, когда все переходят на новый. У нас было похожее приложение, написанное для Windows Mobile 5, теперь оно бесполезно, так как эта платформа мертва.

Автономная база данных на устройстве должна быть:

• быстро (ответы до 2 секунд)
• потенциально может выполнять соединения и иметь отношения с другими таблицами, способными запрашивать базу данных
• выбор данных в определенном диапазоне или критериях, например, по координате x & y на основе показаний GPS.

Опции:

локальное хранилище HTML5:

Штраф для небольших объемов данных <5000 ключ / значение, вы даже можете хранить массивы / объекты в нем, если вы преобразуете его в JSON. </p>

Минусы:

• Более 10000 строк даже на старшей машине браузер медленно ползти.
• Невозможно выполнить сложные запросы к данным, чтобы извлечь нужные данные, так как вам приходится перебирать все хранилище и искать его вручную.
• Ограничения по объему хранилища, которое может быть сохранено

База данных Web SQL:

• Соответствует требованиям.
• Быстрый запуск запроса на 250 000 строк (1-2 сек.)
• Может создавать сложные запросы, объединения и т. Д.
• Поддерживается Safari, Android и Opera, поэтому будет работать на устройствах iOS и Android

Минусы:

• устарело по состоянию на ноябрь 2010 года
• Недостаток безопасности при атаках между каталогами. На самом деле это не проблема, так как мы не будем на виртуальном хостинге

IndexedDB:

Хранилище ключей / значений аналогично локальному хранилищу, за исключением индексов.

Минусы:

• Медленно, чтобы выполнить запрос на 200 000 строк (15-18 сек)
• Невозможно выполнить сложные запросы
• Невозможно объединить с другими таблицами
• Не поддерживается основным телефоном или планшетным устройством, например IPad / Android
• Стандарт не завершен

Это оставляет единственный вариант реализации устаревшего метода Web SQL, который может работать только в течение еще одного года или около того. IndexedDB и локальное хранилище в настоящее время непригодны.

Я не уверен, как Mozilla и Microsoft признали устаревшей стандарт базы данных Web SQL и почему W3C позволил этому случиться. Предположительно, между ними 77% рынка настольных браузеров. На продвинутых мобильных устройствах Mozilla и Microsoft почти не влияют, так как Safari, Opera и Android занимают более 90% рынка . То, как Mozilla и Microsoft могут диктовать, какой стандарт следует использовать на рынке мобильной связи, где наиболее вероятно использование автономного хранилища, не имеет никакого смысла.

В комментариях от Mozilla о том, почему вместо этого они хотели использовать IndexedDB, в основном говорится об «эстетике разработчика», и им не нравится идея запуска SQL в JavaScript. Я не покупаю это.

1. В настоящее время предлагаемый стандарт является худшим и является чрезвычайно базовой реализацией NoSQL, которая является медленной и даже не поддерживает расширенные функции, необходимые людям в базе данных.Существует много стандартного кода для создания базы данных и получения данных, но они утверждают, что люди напишут несколько хороших библиотек абстракций поверх них, которые обеспечат более продвинутые функции.По состоянию на октябрь 2011 года их нигде не было видно.

2. Они устарели в существующем стандарте Web SQL, который фактически работает и реализован в основных браузерах для мобильных устройств и планшетов.Принимая во внимание, что их «новый» и «лучший» стандарт недоступен в основных мобильных браузерах.

3. Что мы, как разработчики, должны использовать в течение следующих 3-5 лет, когдаСпецификация IndexedDB может дойти до стандартизации, иметь больше функций, реализованных в основных браузерах для мобильных устройств / планшетов, и есть несколько хороших библиотек, чтобы упростить задачу?

W3C должен поддерживать Web SQLБаза данных стандартно работает параллельно и просто исправляет проблемы.У него уже есть поддержка основных мобильных платформ, и он работает довольно хорошо.Тот факт, что Mozilla и Microsoft как два игрока с наибольшим количеством настольных браузеров смогли отказаться от этого стандарта, довольно сомнителен и может рассматриваться как попытка помешать прогрессу на мобильных веб-платформах, пока они не смогут догнать и предложитьконкурирующие решения против iOS / Safari и Android.

В заключение, у кого-нибудь есть решение для моей проблемы, которое будет работать для iOS / Android для телефонов / планшетов.Может быть, хороший API-оболочка, который может использовать несколько реализаций базы данных в фоновом режиме с возможностью запроса и позволяет вам выбирать, какая база данных имеет приоритет.Я видел такие вещи, как шезлонг , но я уверен, что он позволяет использовать только локальное хранилище по умолчанию и переключается на другие.Я думаю, что я предпочел бы, чтобы он использовал Web SQL (по умолчанию), а не более медленные варианты.

Любая помощь для решения очень ценится, спасибо!

Answer 1

Я бы порекомендовал проверить библиотеку JayData , которая фактически предназначена именно для создания слоя доступа к данным, не зависящего от хранилища, для мобильных устройств.JayData обеспечивает уровень абстракции с поддержкой JavaScript Language Query (JSLQ) и JavaScript CRUD и позволяет вам работать точно так же с различными типами автономного и онлайн-хранилища данных.JayData поддерживает работу со сложными объектами, а также отношениями объектов локально или удаленно.

На момент написания JayData поддерживает следующие хранилища или протоколы: webSQL (sqLite) / IndexedDB / OData / YQL / FBQL.

Ваша конкретная проблема с различными системами, предоставляющими разные механизмы хранения, может быть легко решена с помощью резервной функции провайдера JayData: она будет использовать любой уровень хранилища, который сможет найти, но при этом предоставит тот же API для кода потребителя.

Что касается устаревания WebSQL к 2012 году: на момент написания статьи это WebSQL, который все еще имеет 95% покрытия устройств, включая Samsung SmartTV и Amazon Kindle. Проверьте, выполняйте ли модульные тесты WebSQL с JayData .

Answer 2

Я хотел бы оформить CouchBase Lite. Это почти полнофункциональная реализация CouchDB , которая работает на Android и iOS.

IOS

Android

Если вы обернули свое приложение в что-то вроде PhoneGap , вы могли бы создавать собственные приложения HTML 5 для обеих платформ, и вам нужно было бы всего лишь чуть-чуть программировать под Android / iOS для реализации CouchDB. 1015 *

Плюсы:

• Быстрый просмотр движка для запросов ко многим строкам данных.
• Грязная и мощная поддержка репликации.

Минусы:

• Key-Value Store - потребуется некоторое время, чтобы привыкнуть.

Answer 3

Я провел еще несколько исследований, пока искал решение для своего собственного проекта. Похоже, эта библиотека довольно многообещающая: http://nparashuram.com/IndexedDBShim/

Позволяет использовать IndexedDB API с WebSQL за кулисами.

Тесты пройдены на последних iPad, iPhone 5, Android 4.2.2.

Надеюсь, это кому-нибудь поможет.

Answer 4

"Я видел такие вещи, как газон, но я почти уверен, что он позволяет использовать только локальное хранилище по умолчанию и возвращается к другим. Я думаю, что я бы предпочел использовать Web SQL (по умолчанию), а затем более медленные варианты. "

Это настраивается, каждый из «адаптеров» для механизмов хранения самодостаточен, вы можете передать адаптер конструктору 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

Конечно, как и в других ответах, вы можете превратить ваш html5 в собственное приложение, используя phonegap и т. Д., Тогда у вас будет много вариантов, но если вы хотите придерживаться веб-стандартов, то это может быть хорошим способом идти, пока мы не получим широкое распространение IndexedDB.

Answer 5

Я бы посоветовал вам использовать Корона .Это частная платформа, используемая для скрещенных мобильных приложений, которая поддерживает SQLite.

Pros

• Это просто и имеет большую поддержку SQLite, и не нужно делать странныевещи с хранилищем Html5

Минусы

• вы должны заплатить за него, если хотите использовать его в Android Market или iOS Market.

Я вставляю здесь, что они говорят об этом:

Corona включает поддержку баз данных SQLite на всех платформах.Это основано на встроенной поддержке sqlite на iPhone и скомпилированной версии SQLite на Android.Обратите внимание, что это увеличивает размер двоичного файла Android на 300K.

SQLite доступен во всех версиях Android, iPhone и iPad, а также в имитаторе Corona ...

Answer 6

Стоит проверить мою библиотеку с открытым исходным кодом https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

Модуль базы данных Javascript для механизмов хранения Indexeddb, WebDatabase (WebSQL) и WebStorage (localStorage), поддерживающих миграцию версий, расширенный запрос и транзакцию.

Будучи библиотекой NoSQL, объединение выполняется вручную, но не невозможно.В библиотеку уже встроены ключевые алгоритмы присоединения.

Answer 7

Почему бы не написать простой механизм хранения в javascript (который охватывает «основанную на стандартах» часть)? Очевидно, вам не нужно ничего очень причудливого, поэтому не нужно слишком много усилий, чтобы это работало.

Я бы сделал следующее:

• Храните все в формате bson или аналогичном двоичном формате.
• Анализировать и создавать индексы в файлах и читать при запуске.
• Запрос с использованием JavaScript и чтение из большого файла из вашего (очевидно, в автономном режиме) веб-приложения.
• Хранить обновленные объекты отдельно.

Это решение возможно только в том случае, если база данных достаточно проста. Но я думаю, что это может сработать - поддержка javascript хороша для мобильных устройств.

Для вдохновения здесь - это реализация Btree + в javascript.

Для чтения локальных файлов вам понадобится file API , который можно использовать для доступа к локальным файлам . Он поддерживается в большинстве современных браузеров, даже Safari 6 . Однако я не смог определить, поддерживают ли этот браузер текущие браузеры iPhone.