HTML5 は ApplicationCache インターフェイスを使用してオフラインキャッシングテクノロジーを実装し、オフラインの問題を解決します

はじめに
Web ベースのアプリケーションにとって、オフラインアクセスの重要性はますます高まっています。すべてのブラウザにはキャッシュメカニズムが備わっていますが、信頼性が低く、常に期待どおりに動作するとは限りません。 HTML5 は、ApplicationCache インターフェイスを使用して、オフラインによって引き起こされる問題の一部を解決します。
キャッシュインターフェイスを使用すると、アプリケーションに次の 3 つの利点がもたらされます:
オフラインブラウジング – ユーザーはオフラインでも Web サイト全体を閲覧できます
速度 – キャッシュされたリソースはローカルリソースであるため、読み込み速度が速くなります。
サーバー負荷の軽減 – ブラウザーは、変更されたサーバーからのみリソースをダウンロードします。

アプリケーションキャッシュ (AppCache とも呼ばれます) を使用すると、開発者はオフラインユーザーのためにブラウザがどのファイルをキャッシュするかを指定できます。ユーザーがオフライン中に更新ボタンを押した場合でも、アプリは正常に読み込まれて実行されます。
キャッシュマニフェストファイル
キャッシュマニフェストファイルは、ブラウザがオフラインアクセスのためにキャッシュする必要があるリソースをリストした単純なテキストファイルです。
マニフェストファイルを参照してください
アプリケーションのアプリケーションキャッシュを有効にするには、ドキュメントの HTML タグにマニフェスト属性を追加します:

コードをコピー

コードは次のとおりです:

...

キャッシュする Web アプリケーションのすべてのページに、manifest 属性を追加する必要があります。 Web ページにマニフェスト属性が含まれていない場合、ブラウザはそのページをキャッシュしません (属性がマニフェストファイルに明示的にリストされている場合を除く)。これは、ユーザーが閲覧するマニフェストを含むすべての Web ページが暗黙的にアプリケーションキャッシュに追加されることを意味します。したがって、在庫内のすべてのページをリストする必要はありません。
マニフェスト属性は絶対 URL または相対パスを指すことができますが、絶対 URL は対応する Web アプリケーションと同じオリジンを持つ必要があります。マニフェストファイルには任意のファイル拡張子を使用できますが、正しい MIME タイプで提供する必要があります (下記を参照)。

コードをコピー

コードは次のとおりです:

...

マニフェストファイルは text/cache-manifest MIME タイプとして提供する必要があります。カスタムファイルタイプを Web サーバーまたは .htaccess 構成に追加する必要がある場合があります。
たとえば、この MIME タイプを Apache で提供するには、次の行を構成ファイルに追加します。
AddType text/cache-manifest .appcache これを Google App Engine の app.yaml ファイルで提供するには、MIME タイプを追加します。以下:
- URL: /mystaticdir/(.*.appcache)
static_files: mystaticdir/1
mime_type: text/cache-manifest
upload: mystaticdir/(.*.appcache) マニフェストファイル構造体
単純なマニフェストの形式は次のとおりです。
CACHE MANIFEST
index.html
stylesheet.css
images/logo.png
scripts/main.js この例では 4 つをキャッシュします。このマニフェストファイルを指定する Web ページ上のファイル。
次の点に注意する必要があります:
CACHE MANIFEST 文字列は最初の行にある必要があり、必須です。
Web サイトのキャッシュデータサイズは 5 MB を超えてはなりません。ただし、Chrome ウェブストア用のアプリを作成している場合は、unlimitedStorage を使用してこの制限を解除できます。
マニフェストファイルまたはマニフェストファイルに指定されているリソースをダウンロードできない場合、キャッシュ更新プロセス全体が続行されません。この場合、ブラウザは元のアプリケーションキャッシュを引き続き使用します。
より複雑な例を見てみましょう:
CACHE MANIFEST
# 2010-06-18:v2
# 明示的にキャッシュされた 'マスターエントリ'
CACHE:
/favicon.ico
index.html
stylesheet.css
images/logo.png
scripts/main.js
# ユーザーがオンラインである必要があるリソース
ネットワーク:
login.php
/myapi
http://api.twitter.com
# main.py にアクセスできない場合は static.html が提供されます
# offline.jpg は、images/large/ 内のすべての画像の代わりに提供されます
# offline.html は、他のすべての .html ファイルの代わりに提供されます
FALLBACK:
/ main.py /static.html
images/large/images/offline.jpg
*.html /offline.html 「#」で始まる行はコメント行ですが、他の目的にも使用できます。アプリのキャッシュは、マニフェストファイルが変更された場合にのみ更新されます。たとえば、画像リソースを変更したり、JavaScript 関数を変更した場合、それらの変更は再キャッシュされません。ブラウザがキャッシュファイルを更新できるようにするには、マニフェストファイル自体を変更する必要があります。生成されたバージョン番号、ファイルハッシュ、またはタイムスタンプを含むコメント行を作成すると、ユーザーはソフトウェアの最新バージョンを確実に入手できます。「キャッシュの更新」セクションで説明されているように、新しいバージョンが利用可能になったときに、プログラムでキャッシュを更新することもできます。
マニフェストには、CACHE、NETWORK、FALLBACK の 3 つの異なるセクションを含めることができます。
CACHE:
これはエントリのデフォルトの部分です。このヘッダーの下にリストされているファイル (または CACHE MANIFEST の直後のファイル) は、初めてダウンロードされるときに明示的にキャッシュされます。
ネットワーク:
このセクションにリストされているファイルは、サーバーに接続する必要があるホワイトリストに登録されたリソースです。これらのリソースに対するすべてのリクエストは、ユーザーがオフラインであるかどうかに関係なく、キャッシュをバイパスします。ワイルドカード文字を使用できます。
FALLBACK:
このセクションはオプションであり、リソースにアクセスできない場合にフォールバックページを指定するために使用されます。最初の URI はリソースを表し、2 番目の URI はフォールバック Web ページを表します。両方の URI は関連している必要があり、マニフェストファイルと同じ生成元を持つ必要があります。ワイルドカード文字を使用できます。
注意: これらのセクションは任意の順序で配置でき、各セクションは同じリスト内に繰り返し表示できます。
次のリストは、ユーザーがオフラインでサイトのルートにアクセスしようとしたときに表示される「総合」ページ (offline.html) を定義します。また、他のすべてのリソース (リモートサイト上のリソースなど) には、インターネット接続。
CACHE MANIFEST
# 2010-06-18:v3
# 明示的にキャッシュされたエントリ
index.html
css/style.css
# offline.html は、ユーザーが次の場合に表示されます。オフラインです
FALLBACK:
/ /offline.html
# 他のすべてのリソース (サイトなど) では、ユーザーがオンラインである必要があります。
NETWORK:
*
# キャッシュする追加のリソース
キャッシュ:
images/logo1.png
images/logo2.png
images/logo3.png 注意: マニフェストファイルを参照する HTML ファイルは自動的にキャッシュされます。したがって、リストに追加する必要はありませんが、追加することをお勧めします。
注意事項: SSL 経由で提供されるページに設定されている HTTP キャッシュヘッダーとキャッシュ制限は、キャッシュマニフェストに置き換えられます。したがって、https 経由で提供される Web ページはオフラインで実行できます。

キャッシュの更新
次のいずれかが発生しない限り、アプリはオフラインでもキャッシュされたままになります:
ユーザーが Web サイトのブラウザーのデータストレージをクリアします。
マニフェストファイルが変更されました。注: マニフェストにリストされているファイルを更新しても、ブラウザがリソースを再キャッシュするわけではありません。マニフェストファイル自体を変更する必要があります。
アプリのキャッシュはプログラムによって更新されます。

キャッシュステータス
window.applicationCache オブジェクトは、ブラウザのアプリケーションキャッシュへのプログラムによるアクセスを提供します。その status 属性を使用して、キャッシュの現在のステータスを表示できます:

コードをコピーします

コードは次のとおりです。

var appCache = window.applicationCache; >switch ( appCache.status) {
case appCache.UNCACHED: // UNCACHED == 0
return 'UNCACHED';
case appCache.IDLE: // IDLE == 1
return 'IDLE';
case appCache.CHECKING: // CHECKING == 2
return 'CHECKING';
case appCache.DOWNLOADING: // == 3
return 'DOWNLOADING';
break;
case appCache.UPDATEREADY == 4
return 'UPDATEREADY';
break; : // OBSOLETE == 5
return 'OBSOLETE'
default:
return 'UKNOWN CACHE STATUS'

プログラムでキャッシュを更新するには、まず applicationCache.update() を呼び出します。この操作では、ユーザーのキャッシュの更新が試行されます (マニフェストファイルが変更されている場合)。最後に、applicationCache.status が UPDATEREADY 状態の場合、applicationCache.swapCache() を呼び出して、元のキャッシュを新しいキャッシュに置き換えます。

コードをコピーします

コードは次のとおりです:

var appCache = window.applicationCache ;

appCache.update(); // ユーザーのキャッシュを更新しようとします。... if (appCache.status == window.applicationCache.UPDATEREADY) { appCache.swapCache() ; // フェッチは成功しました。新しいキャッシュにスワップします。

注意してください
: この方法で update() と swapCache() を使用すると、ユーザーリソースを更新しました。このプロセスでは、ブラウザーが新しいマニフェストを確認し、指定された更新をダウンロードし、アプリのキャッシュを再設定するだけです。したがって、ユーザーに新しいコンテンツを提供するには、Web ページを 2 回リロードする必要があります。1 回目は新しいアプリケーションキャッシュを取得し、2 回目は Web ページコンテンツを更新します。
幸いなことに、2 回リロードする手間を省くことができます。ユーザーを Web サイトの最新バージョンに更新するには、Web ページのロード時に updateready イベントをリッスンするリスナーを設定できます:

コードをコピー
コードは次のとおりです。

// ページの読み込み時に新しいキャッシュが利用可能かどうかを確認します。

window.addEventListener('load', function( e) {

window.applicationCache.addEventListener('updateready', function(e) { if (window.applicationCache.status == window.applicationCache.UPDATEREADY) { // ブラウザが新しいアプリをダウンロードしました// スワップしてページをリロードして、新しいホットネスを取得します。 if (confirm('このサイトの新しいバージョンが利用可能です。ロードしてください) ?')) {

window.reload();

}

} else {
// サーバーには何も変更されていません。 , false);
}, false );

APPCACHE EVENTS

ご想像のとおり、キャッシュのステータスを監視するために追加のイベントが使用されます。ブラウザーは、ダウンロードの進行状況、アプリケーションキャッシュの更新、エラーステータスなどに対応するイベントをトリガーします。次のコードスニペットは、キャッシュイベントタイプごとにイベントリスナーを設定します。

コードをコピーします

コードは次のとおりです。

function handleCacheEvent(e) {
//...
}
function handleCacheError(e) {
alert('エラー: キャッシュの更新に失敗しました!');
};
// マニフェストの最初のキャッシュの後に起動されます。
appCache.addEventListener('cached', handleCacheEvent, false);
// アップデートをチェックしています。常にシーケンス内で最初のイベントが発生します。
appCache.addEventListener('checking', handleCacheEvent, false);
// アップデートが見つかりました。ブラウザがリソースを取得しています。
appCache.addEventListener('ダウンロード中', handleCacheEvent, false);
// マニフェストが 404 または 410 を返した、ダウンロードが失敗した、
// またはダウンロードの進行中にマニフェストが変更された。
appCache.addEventListener('error', handleCacheError, false);
// マニフェストの最初のダウンロード後に起動されます。
appCache.addEventListener('noupdate', handleCacheEvent, false);
// マニフェストファイルが 404 または 410 を返した場合に発生します。
// これにより、アプリケーションキャッシュが削除されます。
appCache.addEventListener('obsolete', handleCacheEvent, false);
// フェッチされるときに、マニフェストにリストされているリソースごとに起動されます。
appCache.addEventListener('progress', handleCacheEvent, false);
// マニフェストリソースが新たに再ダウンロードされたときに発生します。
appCache.addEventListener('updateready', handleCacheEvent, false);

ファイルまたはその中で指定されたソースがダウンロードされない場合、更新はすべて失われます。