4
オフラインWebアプリケーションの画像データの保存（クライアント側のストレージデータベース）
appcachingを使用したオフラインWebアプリケーションがあります。主にPNG画像ファイルで構成される（クライアント側で）保存する約10MB-20MBのデータを提供する必要があります。操作は次のとおりです。 Webアプリケーションをダウンロードしてappcacheにインストール（マニフェストを使用） サーバーPNGデータファイルからのWebアプリリクエスト（方法？-以下の代替案を参照） 時々、Webアプリがサーバーと再同期し、PNGデータベースへの小さな部分的な更新/削除/追加を行います 参考：サーバーはJSON RESTサーバーであり、ピックアップのためにwwwrootにファイルを配置できます これが、バイナリBLOBストレージを処理するクライアントベースの「データベース」の私の現在の分析です 下の更新を見る AppCache（マニフェストを介してすべてのPNGを追加し、オンデマンドで更新します） CON：PNGデータベースアイテムの変更は、マニフェスト内のすべてのアイテムの完全なダウンロードを意味します（本当に悪いニュースです！） WebStorage CON：JSONストレージ用に設計 CON：base64エンコーディングを介してのみblobを格納できます（デエンコーディングのコストのため、おそらく致命的な欠陥） CON：webStorageの5MBのハード制限http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html PhoneGapとSQLLite CON：スポンサーは、認定を必要とするネイティブアプリとしてそれを拒否します ZIPファイル サーバーはzipファイルを作成してwwwrootに配置し、クライアントに通知します ユーザーは手動で解凍し（少なくともそれが私の見方です）、クライアントファイルシステムに保存する必要があります WebアプリはFileSystem APIを使用してファイルを参照します CON：ZIPが大きすぎる（zip64？）、作成に時間がかかる CON：FileSystem APIが常にサンドボックスから読み込めるかどうかわからない（そう思います） USBまたはSDカード（石器時代に戻る...） ユーザーはオフラインになる前にサーバーに対してローカルになります SDカードを挿入し、サーバーにPNGファイルを挿入させます。 次に、ユーザーはそれをラップトップ、タブレットに接続します WebアプリはFileSystem APIを使用してファイルを読み取ります CON：FileSystem APIが常にサンドボックスから読み込めるかどうかわからない（そう思います） WebSQL CON：w3cがそれを放棄した（かなり悪い） IndexedDBとWebSQLをフォールバックとして使用するJavaScriptラッパーを検討するかもしれません FileSystem API Chromeはblobの読み取り/書き込みをサポートします CON：IEとFireFoxについて明確でない（IE10、非標準のmsSaveがある） caniuse.comはIOSとAndroidのサポートを報告しています（ただし、これはJSONのr / wだけですか、それとも書き込み用の完全なblob APIが含まれていますか？ CON：FireFoxの人々はFileSystem APIを嫌い、ブロブの保存をサポートしているかどうかは不明です：https : //hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/ PRO：jsperf http://jsperf.com/indexeddb-vs-localstorage/15（ページ2）によると、BlobのIndexedDBよりはるかに高速 IndexedDB …