2011年のiOS / Android向けHTML5オフラインストレージソリューションの開発
問題：
携帯電話またはタブレット型のデバイス（iOS/Androidなど）で250,000行以上のデータをオフラインで保存およびクエリするために、デバイスに依存しない（HTML5など）ソリューションが必要です。私が考えているのは、セルラーデータ接続なしで遠隔地で働く人々がいて、このデータに対してクエリを実行し、オフラインで編集する必要があるということです。一部はジオロケーションベースであるため、資産が存在するエリアにある場合（GPSを使用）、それらの資産が表示され、編集できるようになります。オフィスに戻ったら、データをオフィスサーバーに同期できます。
私がウェブ標準の観点からこれにアプローチしている理由は、基本的にHTML5で1回記述することでお金と時間を節約し、Objective CとJavaで2回記述するのではなく、複数のプラットフォームで機能するためです。また、プラットフォームにとらわれない何かを書く場合、誰もが新しいものに移動するときに、閉じ込められず、船に降りて行くことはありません。 Windows Mobile 5用に作成された同様のアプリがありましたが、今ではそのプラットフォームは死んでいるので役に立たなくなりました。
デバイス上のオフラインデータベースは次のとおりである必要があります。
- 高速（2秒未満の応答）
- 潜在的に結合を実行し、データベースを照会できる他のテーブルとの関係を持っている
- 特定の範囲または基準内のデータを選択します。 GPS読み取り値に基づくxおよびy座標による。
オプション：
HTML5ローカルストレージ：
キー/値が5,000未満の少量のデータには問題ありません。JSONに変換する場合は、配列/オブジェクトを格納することもできます。
短所：
- ハイエンドマシンでも10,000行を超えると、ブラウザのクロールが遅くなります。
- ストレージ全体を反復処理して手動で検索する必要があるため、データに対して複雑なクエリを実行して必要なデータを引き出すことはできません。
- 保管できるストレージの量に関する制限
Web SQL Database：
- 要件を満たします。
- 250,000行でクエリを高速に実行（1〜2秒）
- 複雑なクエリ、結合などを作成できます
- SafariでサポートされているAndroidおよびOpera iOSで動作するため、Androidデバイス
短所：
- 2010年11月の時点で非推奨
- クロスディレクトリ攻撃によるセキュリティの欠陥。共有ホスティングではないので、実際には問題ではありません
IndexedDB：
キー/値オブジェクトストアは、インデックスを除いてローカルストレージに似ています。
短所：
- 200,000行（15〜18秒）でのクエリの実行が遅い
- 複雑なクエリを実行できません
- 他のテーブルとの結合はできません
- メインの電話またはタブレットデバイスではサポートされていません。 iPad/Android
- 標準が完全ではありません
これにより、非推奨のWeb SQLメソッドを実装する唯一のオプションが残り、これは1年程度しか機能しない可能性があります。 IndexedDBとローカルストレージは現在使用できません。
MozillaとMicrosoftがWeb SQL Database標準を非推奨にした理由と、W3Cがそれを実現させた理由はわかりません。おそらくそれらの間で、彼らはデスクトップブラウザ市場の77％を持っています。高度なモバイルデバイスでは、MozillaおよびMicrosoftは Safari、OperaおよびAndroid市場シェアの90％を超える 。オフラインストレージが使用される可能性が最も高いモバイル市場で、MozillaとMicrosoftがどの標準を使用すべきかを指示する方法は意味がありません。
Mozillaからのコメント では、なぜIndexedDBを使用したかったのかについては、主に「開発者の美学」についてであり、JavaScriptでSQLを実行するという考えは好きではありません。私はそれを買っていません。
現在、提案されている標準は劣っており、非常に基本的なNoSQL実装であり、低速であり、データベースに必要な高度な機能もサポートしていません。データベースを確立してデータを取得するための定型的なコードがたくさんありますが、彼らは人々がより高度な機能を提供するニースの抽象化ライブラリをその上に書くと主張しています。 2011年10月の時点で、彼らはどこにも見当たりません。
彼らは、実際に動作し、メインのモバイル/タブレットブラウザに実装されている既存のWeb SQL標準を廃止しました。一方、それらの「新しい」および「より良い」標準は、主要なモバイルブラウザでは使用できません。
開発者が今後3〜5年間使用することになっているのは、IndexedDB仕様が標準化され、より多くの機能を備え、メインのモバイル/タブレットブラウザーに実装され、作業を簡単にするニースのライブラリがあるためです。
W3Cは、Web SQL Database標準を並行して実行し続け、問題を修正するだけです。すでに主要なモバイルプラットフォームをサポートしており、かなりうまく機能しています。最も多くのデスクトップブラウザーを共有する2つのプレーヤーであるMozillaとMicrosoftがこの標準を廃止できたという事実はかなり疑わしく、追いついて提供できるようになるまでモバイルWebプラットフォームの進歩を妨げる試みと見ることができます。 iOS/SafariおよびAndroidに対する競合ソリューション。
結論として、誰もが私の問題の解決策を持っていますか？それは、携帯電話/タブレットデバイスのiOS/Androidで動作します。おそらく、クエリ機能を備えたバックグラウンドで複数のデータベース実装を使用でき、どのデータベースに優先度があるかを選択できるニースラッパーAPIです。 lawnchair のようなものを見てきましたが、デフォルトではローカルストレージのみを使用でき、他のものにフォールバックすることは間違いありません。遅いオプションよりもWeb SQL（デフォルト）を使用した方がいいと思います。
ソリューションのヘルプは大歓迎です、ありがとう！
JayData ライブラリをチェックアウトすることをお勧めします。実際には、モバイルデバイス用のストレージに依存しないデータアクセスレイヤーを作成するという正確な目的があります。 JayDataは、 JavaScript Language Query（JSLQ） およびJavaScript CRUDサポートを備えた抽象化レイヤーを提供し、異なるオフラインおよびオンラインデータストアタイプでまったく同じ方法で作業できるようにします。 JayDataは、ローカルまたはリモートでの複雑なエンティティとエンティティの関係の処理をサポートしています。
執筆時点で、JayDataはwebSQL（sqLite）/ IndexedDB/OData/YQL/FBQLのストアまたはプロトコルをサポートしています。
異なるストレージエンジンを提供する異なるシステムの特定の問題は、JayDataのプロバイダーフォールバック機能で簡単に対処できます。JayDataは、消費者コードに対して同じAPIを提供しながら、検出可能なストレージレイヤーを使用します。
WebSQLは2012年までに非推奨になります。執筆時点では、Samsung SmartTVやAmazon Kindleなど、95％のデバイスをカバーしているのはWebSQLです。 JayDataでWebSQL単体テストを実行しているKindleをチェックしてください 。
私は自分のプロジェクトの解決策を探している間に、さらに調査を行いました。このライブラリはかなり有望なようです： http://nparashuram.com/IndexedDBShim/
WebSQLをバックグラウンドで持つIndexedDB APIを使用できます。
最近のiPad、iPhone 5、Android 4.2.2。
これが誰かを助けることを願っています。
「lawnchairのようなものを見てきましたが、デフォルトではローカルストレージのみを使用し、他のものにフォールバックすることを確信しています。WebSQL（デフォルト）を使用し、より遅いオプションを使用したいと思います。 」
これは構成可能です。ストレージエンジンの各「アダプター」は自己完結型であり、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
もちろん、他の回答が示唆するように、phonegapなどを使用してhtml5をネイティブアプリにラップすることができます。その後、多くのオプションがありますが、Web標準に固執したい場合は、これが良い方法ですIndexedDBが広く採用されています。
Corona を使用するように指示します。これは、SQLiteをサポートするクロスモバイルアプリケーションに使用されるプライベートプラットフォームです。
長所
- それは簡単で、SQLiteの大きなサポートがあり、Html5ストレージで奇妙なことをする必要はありません。
短所
- AndroidマーケットまたはiOSマーケットで使用する場合は、料金を支払う必要があります。
私は彼らがそれについて言うことをここに貼り付けます：
Coronaには、すべてのプラットフォームでのSQLiteデータベースのサポートが含まれています。これは、iPhoneの組み込みsqliteサポート、およびAndroidのSQLiteのコンパイル済みバージョンに基づいています。これにより、Androidバイナリのサイズが300K増加します。
SQLiteは、Android、iPhone、iPadのすべてのバージョンとCorona Simulatorで利用可能です...
私のオープンソースライブラリをチェックアウトする価値があります https://bitbucket.org/ytkyaw/ydn-db/wiki/Home
バージョン移行、高度なクエリ、トランザクションをサポートするIndexeddb、WebDatabase（WebSQL）、WebStorage（localStorage）ストレージメカニズム用のJavascriptデータベースモジュール。
NoSQLライブラリであるため、結合は手動ですが、不可能ではありません。ライブラリには、すでにキー結合アルゴリズムが組み込まれています。
Javascript（「標準ベース」の部分をカバーする）で単純なストレージエンジンを作成してみませんか？どうやら非常に派手なものは必要ないので、動作させるのにそれほど労力をかけるべきではありません。
私は次のことをします：
- すべてをbsonまたは同様のバイナリ形式で保存します。
- ファイル内のインデックスを解析および作成し、起動時に読み取ります。
- JavaScriptを使用してクエリを実行し、（明らかにオフラインの）Webアプリケーションから大きなファイルを読み取ります。
- 更新されたオブジェクトを個別に保存します。
このソリューションは、データベースが十分に単純な場合にのみ実行可能です。しかし、私はそれがうまくいくかもしれないと思う-javascriptのサポートはモバイルデバイス上で良いです。
インスピレーションのため here はjavascriptのBtree +実装です。
ローカルファイルを読み取るには、 ファイルAPI が必要です。これは ローカルファイルへのアクセス に使用できます。 Safari 6 であっても、ほとんどの最新ブラウザーでサポートされています。しかし、現在のiPhoneブラウザーがこのAPIをサポートしているかどうかを判断できませんでした。