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

はじめに
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);

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