development

2011 년 iOS / Android 용 HTML5 오프라인 스토리지 솔루션 개발

big-blog 2020. 10. 22. 08:18
반응형

2011 년 iOS / Android 용 HTML5 오프라인 스토리지 솔루션 개발


문제 :

휴대폰 또는 태블릿 유형 장치 (예 : iOS / Android)에서 오프라인으로 250,000 개 이상의 데이터 행을 저장하고 쿼리하기위한 장치에 구애받지 않는 (예 : HTML5) 솔루션이 필요합니다. 셀룰러 데이터 연결없이 원격 지역에서 일하는 사람들이이 데이터에 대해 쿼리를 실행하고 오프라인 상태에서 편집해야한다는 생각입니다. 부분적으로는 지리적 위치 기반이므로 해당 영역에 자산이 있으면 (GPS 사용) 해당 자산을 표시하고 편집 할 수 있습니다. 사무실로 돌아 오면 데이터를 사무실 서버에 다시 동기화 할 수 있습니다.

웹 표준 관점에서 접근하는 이유는 기본적으로 HTML5로 한 번 작성하여 비용과 시간을 절약 한 다음 Objective C와 Java로 두 번 작성하는 대신 여러 플랫폼에서 작동하기 때문입니다. 또한 플랫폼에 구애받지 않는 무언가를 작성하면 모든 사람이 새로운 것으로 이동할 때 함선에 갇히지 않고 함선과 함께 내려 가지 않습니다. Windows Mobile 5 용으로 작성된 유사한 앱이 있었지만 이제는 그 플랫폼이 죽었 기 때문에 쓸모가 없습니다.

장치의 오프라인 데이터베이스는 다음과 같아야합니다.

  • 빠름 (2 초 미만 응답)
  • 잠재적으로 조인을 수행하고 데이터베이스를 쿼리 할 수있는 다른 테이블과의 관계를 갖습니다.
  • 특정 범위 또는 기준 내에서 데이터를 선택합니다 (예 : GPS 판독 값에 따라 x 및 y 좌표).

옵션 :

HTML5 로컬 저장소 :

키 / 값이 5,000 미만인 소량의 데이터에 적합하며 JSON으로 변환하면 배열 / 객체를 저장할 수도 있습니다.

단점 :

  • 최고급 시스템에서도 10,000 개 이상의 행에 대해 브라우저는 크롤링 속도를 느리게합니다.
  • 전체 저장소를 반복하고 수동으로 검색해야하므로 원하는 데이터를 추출하기 위해 데이터에 대해 복잡한 쿼리를 수행 할 수 없습니다.
  • 저장할 수있는 저장 용량의 제한

웹 SQL 데이터베이스 :

  • 요구 사항을 충족합니다.
  • 250,000 행 (1-2 초)에 대한 빠른 쿼리 실행
  • 복잡한 쿼리, 조인 등을 만들 수 있습니다.
  • Safari, Android 및 Opera에서 지원하므로 iOS 및 Android 장치에서 작동합니다.

단점 :

  • 2010 년 11 월부터 사용 중단됨
  • 디렉터리 간 공격으로 인한 보안 결함. 우리는 공유 호스팅에 있지 않기 때문에 실제로 문제가 아닙니다.

IndexedDB :

인덱스를 제외하고 로컬 저장소와 유사한 키 / 값 개체 저장소입니다.

단점 :

  • 200,000 행 (15-18 초)에 대한 쿼리 실행 속도가 느립니다.
  • 복잡한 쿼리를 실행할 수 없습니다.
  • 다른 테이블과 조인 할 수 없음
  • 주요 전화 또는 태블릿 장치 (예 : iPad / Android)에서 지원되지 않음
  • 표준이 완전하지 않음

이렇게하면 향후 1 년 정도만 작동 할 수있는 사용되지 않는 웹 SQL 메서드를 구현하는 유일한 옵션이 남습니다. IndexedDB 및 로컬 저장소는 현재 사용할 수 없습니다.

Mozilla와 Microsoft가 웹 SQL 데이터베이스 표준을 폐기 한 방법과 W3C가이를 허용 한 이유를 잘 모르겠습니다. 아마도 그들 사이에는 데스크톱 브라우저 시장의 77 %가 있습니다. 고급 모바일 장치에서 Mozilla와 Microsoft는 Safari, Opera 및 Android가 시장 점유율의 90 % 이상을 차지 하므로 거의 영향을 미치지 않습니다. Mozilla와 Microsoft가 오프라인 스토리지가 가장 많이 사용되는 모바일 시장에서 사용해야하는 표준을 지정하는 방법은 의미가 없습니다.

왜 IndexedDB를 사용하기를 원하는지에 대한 Mozilla의견 은 주로 '개발자 미학'에 관한 것이며 JavaScript에서 SQL을 실행하는 것을 좋아하지 않습니다. 나는 그것을 사지 않는다.

  1. 현재 제안 된 표준은 열등하고 매우 기본적인 NoSQL 구현으로 느리고 사람들이 데이터베이스에서 필요로하는 고급 기능도 지원하지 않습니다. 데이터베이스를 설정하고 데이터를 가져 오기위한 많은 상용구 코드가 있지만 그들은 사람들이 더 고급 기능을 제공하는 멋진 추상화 라이브러리를 작성할 것이라고 주장합니다. 2011 년 10 월 현재는 볼 수 없습니다.

  2. 그들은 실제로 작동하고 주요 모바일 / 태블릿 브라우저에서 구현되는 기존 Web SQL 표준을 폐기했습니다. '새롭고 더 나은'표준은 주요 모바일 브라우저에서 사용할 수 없습니다.

  3. IndexedDB 사양이 표준화되고, 더 많은 기능을 갖고, 주요 모바일 / 태블릿 브라우저에서 구현되고, 일을 더 쉽게 만들어주는 멋진 라이브러리가있는 향후 3-5 년 동안 개발자로서 우리는 무엇을 사용해야할까요?

W3C는 웹 SQL 데이터베이스 표준을 병렬로 실행하고 문제를 해결해야합니다. 이미 주요 모바일 플랫폼을 지원하고 있으며 꽤 잘 작동합니다. 데스크톱 브라우저를 가장 많이 공유하는 두 플레이어 인 Mozilla와 Microsoft가이 표준을 폐기 할 수 있었다는 사실은 매우 모호하며 모바일 웹 플랫폼이 따라 잡고 제공 할 수있을 때까지 진행을 방해하려는 시도로 볼 수 있습니다. iOS / Safari 및 Android에 대한 경쟁 솔루션.

결론적으로 누구나 iOS / Android for Phone / Tablet 장치에서 작동하는 내 문제에 대한 해결책이 있습니까? 쿼리 기능과 함께 백그라운드에서 여러 데이터베이스 구현을 사용할 수 있고 우선 순위가있는 데이터베이스를 선택할 수있는 멋진 래퍼 API 일 수 있습니다. 나는 잔디 의자 와 같은 것을 보았지만 기본적으로 로컬 저장소를 사용할 수만 있고 다른 저장소로 돌아갈 수 있다고 확신합니다. 나는 차라리 웹 SQL (기본적으로)을 사용하고 느린 옵션을 사용하는 것이 좋습니다.

솔루션에 대한 모든 도움을 주셔서 감사합니다.


실제로 모바일 장치 용 스토리지에 구애받지 않는 데이터 액세스 레이어를 만드는 정확한 목적을 가진 JayData 라이브러리를 확인하는 것이 좋습니다 . JayData는 JSLQ (JavaScript Language Query) 및 JavaScript CRUD 지원과 함께 추상화 계층을 제공하며 다양한 오프라인 및 온라인 데이터 저장소 유형을 사용하여 똑같은 방식으로 작업 할 수 있습니다. JayData는 복잡한 엔티티 및 엔티티 관계를 로컬 또는 원격으로 처리하는 것을 지원합니다.

작성 당시 JayData는 webSQL (sqLite) / IndexedDB / OData / YQL / FBQL과 같은 저장소 또는 프로토콜을 지원합니다.

서로 다른 스토리지 엔진을 제공하는 서로 다른 시스템의 특정 문제는 JayData의 공급자 폴백 기능으로 쉽게 해결할 수 있습니다. 소비자 코드에 대해 동일한 API를 제공하면서 찾을 수있는 모든 스토리지 계층을 사용합니다.

2012 년까지 WebSQL이 더 이상 사용되지 않는 것과 관련하여 : 작성 당시에는 Samsung SmartTV 및 amazon Kindle을 포함하여 여전히 95 % 장치 범위를 유지하는 WebSQL입니다. JayData로 WebSQL 단위 테스트를 실행하는 kindle을 확인하십시오 .


CouchBase Lite를 확인하겠습니다. Android 및 iOS에서 실행 되는 거의 모든 기능을 갖춘 CouchDB 구현입니다 .

iOS

기계적 인조 인간

If you wrapped your App in something like PhoneGap you 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.

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.

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/

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

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

Hope this helps someone.


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

Pros

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

Cons

  • you must pay for it if you wanna use it in the Android Market or the 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...


"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."

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:

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.


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.

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.

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

For inspiration here is a Btree+ implementation in javascript.

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.


It worths to check out my open source library 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.

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

참고URL : https://stackoverflow.com/questions/7734371/developing-a-html5-offline-storage-solution-for-ios-android-in-2011

반응형