Розробка рішення для офлайн-зберігання HTML5 для iOS / Android у 2011 році


74

Проблема:

Мені потрібне рішення для агностики пристроїв (наприклад, HTML5) для зберігання та запитів 250 000+ рядків даних в автономному режимі на пристрої типу телефону або планшета (наприклад, iOS / Android). Ідея полягає в тому, що у мене є люди, які працюють у віддалених районах без будь-якого стільникового зв'язку, і їм потрібно запускати запити щодо цих даних та редагувати їх в автономному режимі. Частково це буде базуватися на геолокації, тому, якщо в районі, де вони перебувають, є активи (використовує GPS), вони покажуть ці активи та дозволять їх редагувати. Повернувшись до офісу, вони можуть синхронізувати дані назад до офісного сервера.

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

Автономна база даних на пристрої повинна бути:

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

Варіанти:

Локальне сховище HTML5:

Прекрасно для невеликих обсягів даних <5000 ключів / значень, ви навіть можете зберігати в них масиви / об'єкти, якщо перетворюєте їх у JSON.

Мінуси:

  • Понад 10 000 рядків навіть на висококласній машині браузер сповільнюється до сканування.
  • Неможливо виконати складні запити щодо даних, щоб витягти потрібні дані, оскільки вам доводиться перебирати всю пам’ять і шукати їх вручну.
  • Обмеження обсягу пам’яті, яку можна зберегти

Веб-база даних SQL:

  • Відповідає вимогам.
  • Швидкий запуск запиту на 250 000 рядків (1-2 секунди)
  • Може створювати складні запити, об'єднання тощо
  • Підтримується Safari, Android та Opera, тому буде працювати на пристроях iOS та Android

Мінуси:

  • Заборонено станом на листопад 2010 року
  • Недолік безпеки при атаках між каталогами. Це насправді не проблема, оскільки ми не будемо брати участь у спільному хостингу

Проіндексовано:

Сховище об’єкта ключ / значення схоже на локальне сховище, за винятком індексів.

Мінуси:

  • Повільний запуск запиту на 200 000 рядків (15-18 секунд)
  • Не вдається запустити складні запити
  • Не вдається об’єднати з іншими таблицями
  • Не підтримується основними телефонними або планшетними пристроями, наприклад iPad / Android
  • Стандарт не повний

Це залишає єдиний варіант реалізації застарілого методу Web SQL, який може працювати лише близько року. Індексована база даних і локальне сховище в даний час непридатні для використання.

Я не впевнений, як Mozilla та Microsoft застаріли стандарт Web SQL Database і чому 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-обгортка, який може використовувати декілька реалізацій баз даних у фоновому режимі з можливістю запитів, і це дозволяє вибрати, яка база даних має пріоритет. Я бачив такі речі, як газонний стілець, але я впевнений, що це дозволяє вам використовувати лише локальне сховище за замовчуванням і повертається до інших. Я вважаю, що волію використовувати веб-SQL (за замовчуванням), а не повільніші варіанти.

Будь-яка допомога у вирішенні дуже вдячна, дякую!


5
Добре написана стаття! Це одна з тих ситуацій, коли рідні програми перемагають вручну аргумент проти рідної та веб-програми - але я знаю, що ви не хочете цього чути. У такому випадку веб-SQL є найкращим варіантом з моїх знань - я б також змусив користувача завантажувати рядки, що відповідають місцям, куди вони збиралися, на відміну від усієї бази даних - якщо ви вважаєте, що їм, можливо, доведеться десь оновити із жахливим з'єднання, не кажучи вже про збільшення швидкості пошуку через БД на 1/5 розміру (невпевнений у масштабі Вашої БД)
amcc

2
Вони не можуть "просто вирішити проблеми" з WebSQL, оскільки однією з вимог до стандарту, що переходить до статусу Рекомендації W3C, є наявність "незалежних та сумісних реалізацій". Оскільки специфікація в основному робить те, що робить SQLite, цього ніколи не станеться.
robertc

2
Ей, ви щойно описали мій підсумковий іспитовий проект :) Як я бачу, є 2 варіанти, якщо вам потрібні виступи в режимі офлайн та спуску; 1. Використовуйте локальне сховище та зніміть дані до абсолютного рівня. або 2. Створіть власний додаток (із масштабованим інтерфейсом?), а потім клонуйте його на іншу платформу (ви вже встановили специфікації i для першої, тож швидше розробити її знову для інших платформ. мінусом є те, що вам доведеться утримувати більше одного)
Michael Olesen

2
Тому що раніше вони вимагали, щоб те, що ми мали, було Рекомендаціями W3C, які жоден браузер насправді не реалізовував. Усі три браузери використовують SQLite. Немає специфікації SQLite, це одна з причин, чому це не є хорошою основою для стандарту.
robertc

1
@robertc Як це означає, що немає специфікацій? Він заснований на стандарті SQL92 з декількома незначними недоліками . Я знайшов цю сторінку, яка здається специфікацією. Також як щодо всієї іншої документації на веб-сайті SQLite, це фактично є частиною специфікації, чи не так? Що ще потрібно, щоб бути дійсним?
zuallauz

Відповіді:


18

Я б рекомендував перевірити бібліотеку 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 .


Я погоджуюсь, що підтримка мовних запитів JavaScript та модель постачальника робить бібліотеку JayData хорошим варіантом для рішення для офлайн-зберігання HTML5.

Оновлення: JayData тепер також підтримує HTML5 localStorage. Бібліотека JayData виконує роботу з обробкою / аналізом JSON і обслуговує чистий, уніфікований API управління та концепції управління даними.
Робеш,

1
Я був би радий дати Вашу відповідь як прийняту, оскільки звучить саме те, що потрібно, але чи є у Вас якісь показники ефективності для великої бази даних, наприклад, 250 000 рядків? Мені було б цікаво побачити, чи може він обробляти таку кількість рядків, використовуючи як IndexedDB, так і WebSQL, що лежить в основі сховища (залежно від пристрою), а потім час, скільки часу потрібно, щоб зробити базовий запит типу "де", щоб знайти один із рядків на основі деяких критеріїв .
zuallauz

2
@zuallauz Я щойно зробив такий орієнтир. Отримання 5-10 предметів із 250 тис. Предметів зайняло 60 мс на websql за допомогою Android nexus 2, а на Lumia 920 із Windows Phone - 25 мс. (IndexedDB, безумовно, швидший).
Пітер Арон Зентай,

1
@zuallauz Ви дуже праві в цьому, і ми будемо. IndexedDB, як правило, набагато швидший у всіх аспектах - за винятком складних багатопольових запитів. Однак вставка даних може бути повільною в WebSQL. Транзакція, відкрита для письма, може коштувати дорого (60-120 мс).
Пітер Арон Зентай,

13

Я б замовив CouchBase Lite. Це майже повнофункціональна реалізація CouchDB, яка працює на Android та iOS.

iOS

Android

Якщо ви обгорнули свій додаток чимось на зразок PhoneGap, ви могли б створити власні програми HTML 5 для обох платформ, і вам потрібно було б лише виконати невелике програмування для Android / iOS, щоб реалізувати CouchDB.

Плюси:

  • Механізм швидкого перегляду для запитів у багатьох рядках даних.
  • Бруд проста і потужна підтримка реплікації запечена в.

Мінуси:

  • Магазин Key-Value - Це займе деякий час, щоб звикнути.

Дякую, здається, це може спрацювати, однак вам потрібна система Mac, яку я вважаю розробити для неї та виготовити ключі тощо? У нас немає Mac.
zuallauz

CouchDB є досить цікавим, але я не впевнений, що його модель створення індексу ("подання") оновлюється ледаче (викликається запитом або пакетним процесом) насправді добре працює. Більшість програм, які я бачив, припускають, що як тільки ви додасте деякі дані, їх можна буде ефективно запитувати, і більшість інших баз даних NoSQL підштовхують більше роботи до транзакцій запису, щоб транзакції читання були швидшими.
RichVel

@RichVel: На моєму досвіді оновлення подання ніколи не створювали проблем для мобільних пристроїв. Це говорить про те, що однією з найбільших причин використання CouchDB або TouchDB є надзвичайно потужна, але проста у використанні реплікація.
rwilliams

1
Я почав розглядати CouchDB для реплікації на мобільний телефон, але мені не дуже хотілося виставляти серверну БД на мобільний телефон або мені потрібно було використовувати CouchDB на сервері для отримання реплікації. Отже, я зараз переглядаю хмарну службу синхронізації даних під назвою Simperium, див. Simperium.com та simperium
RichVel

6

Я зробив ще кілька досліджень, шукаючи рішення для власного проекту. Схоже, ця бібліотека досить перспективна: http://nparashuram.com/IndexedDBShim/

Це дозволяє використовувати API IndexedDB, який має WebSQL за кадром.

Це тести, які проходять нещодавно iPad, iPhone 5, Android 4.2.2.

Сподіваюся, це комусь допомагає.


Пізно на вечірку, але я також рекомендую indexeddbshim.js. Це працює досить добре в середовищі Cordova / PhoneGap, щоб забезпечити єдине рішення для IOS та Android.
Дуглас Тіммс,

2

Я б сказав вам використовувати для цього Корону . Це приватна платформа, що використовується для мобільних додатків, що підтримує SQLite.

Плюси

  • Це просто і має велику підтримку SQLite, і не потрібно робити дивні речі із сховищем Html5

Мінуси

  • ви повинні заплатити за це, якщо хочете використовувати його на Android Market або iOS Market.

Тут я вставляю те, що вони про це говорять:

Corona включає підтримку баз даних SQLite на всіх платформах. Це базується на вбудованій підтримці sqlite на iPhone та компільованій версії SQLite на Android. Зверніть увагу, що це збільшує розмір бінарного файлу Android на 300 КБ.

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


2

"Я бачив такі речі, як газон, але я впевнений, що це дозволяє вам використовувати лише локальне сховище за замовчуванням і повертається до інших. Я вважаю, що я б скоріше використовував 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.


1

Чому б не написати простий механізм зберігання в javascript (який охоплює частину, засновану на стандартах)? Очевидно, вам не потрібно нічого дуже вигадливого, тому не потрібно надто багато зусиль, щоб це спрацювало.

Я б зробив наступне:

  • Зберігайте все у форматі bson або подібному двійковому форматі.
  • Проаналізуйте та створіть індекси у файлах та читайте під час запуску.
  • Запитуйте за допомогою javascript та читайте з великого файлу з вашого (очевидно, офлайн) веб-додатку.
  • Зберігайте оновлені об’єкти окремо.

Це рішення можливо лише в тому випадку, якщо база даних досить проста. Але я думаю, що це може спрацювати - підтримка javascript хороша на мобільних пристроях.

Для натхнення тут є реалізація Btree + у javascript.

Для читання локальних файлів вам знадобиться API файлу , який можна використовувати для доступу до локальних файлів . Він підтримується в більшості сучасних браузерів, навіть у Safari 6 . Я не зміг визначити, чи підтримують цей API поточні браузери iPhone.


Як JavaScript на телефоні має доступ для читання / запису у / з файлової системи на пристроях?
zuallauz

1
Влучне зауваження. Очевидно, що API файлів не так далеко, як здається, але моя відповідь може бути занадто оптимістичною. CouchBase виглядає як більш безпечна ставка.
alexfernandez

1

Варто перевірити мою бібліотеку з відкритим кодом https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

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

Будучи бібліотекою NoSQL, приєднання є ручним, але не неможливим. У бібліотеці вже є вбудовані алгоритми об’єднання ключів.


Якщо в коді мені потрібно зробити запит SQL для отримання деяких даних та їх сортування, але на моєму пристрої встановлено IndexedDB, чи може ваша бібліотека перетворити цей запит SQL, який отримає дані з бази даних IndexedDB?
zuallauz

Ні. Підтримка SQL у моїй бібліотеці є дуже базовою. Будь ласка, подивіться тут, що це може dev.yathit.com/ydn-db/sql-query.html
Tun
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.