アプリケーションキャッシュの初期使用ガイド

オフラインアクセスは、ネットワークベースのアプリケーションにとってますます重要になります.すべてのブラウザにキャッシュメカニズムがありますが、信頼性が高くなく、必ずしも期待される役割を果たすとは限りません.HTML 5は、ApplicationCacheインタフェースを使用してオフラインによる一部の難題を解決しています.
キャッシュ・インタフェースを使用すると、アプリケーションに次の3つのメリットがあります.

オフラインブラウズ-ユーザーは、オフライン時に完全なWebサイト

をブラウズできます.

速度-キャッシュリソースはローカルリソースであるため、ロード速度が速い.

サーバの負荷が少ない-ブラウザは変更されたサーバからリソースをダウンロードするだけです.

アプリケーションキャッシュ(AppCacheとも呼ばれる)を使用すると、開発者はブラウザがオフラインユーザーにアクセスするためにどのファイルをキャッシュすべきかを指定できます.ユーザーがオフラインでリフレッシュボタンを押しても、アプリケーションは正常にロードおよび実行されます.
キャッシュ・インベントリ・ファイル
キャッシュ・インベントリ・ファイルは、ブラウザがオフラインでアクセスするためにキャッシュすべきリソースをリストした簡単なテキスト・ファイルです.
参照リストファイル
アプリケーションのアプリケーションキャッシュを有効にするには、ドキュメントのhtmlタグにmanifestプロパティを追加します.

<htmlmanifest="example.appcache">
  ...
</html>

キャッシュするネットワークアプリケーションの各ページにmanifestプロパティを追加します.ページにmanifestのプロパティが含まれていない場合、ブラウザはそのプロパティをリストファイルに明示的にリストされていない限り、ページをキャッシュしません.これは、ユーザが閲覧するmanifestを含む各ページが、アプリケーションキャッシュに暗黙的に追加されることを意味する.したがって、各ページをリストにリストする必要はありません.manifest属性は、絶対ウェブサイトまたは相対パスを指すことができるが、絶対ウェブサイトは、対応するネットワークアプリケーションと同源でなければならない.インベントリファイルは、任意のファイル拡張子を使用できますが、正しいMIMEタイプで指定する必要があります(以下を参照).

<htmlmanifest="http://www.example.com/example.mf">
  ...
</html>

インベントリファイルはtext/cache-manifest MIMEタイプで提供する必要があります.ネットワーク・サーバまたは.htaccess構成にカスタム・ファイル・タイプを追加する必要がある場合があります.
たとえば、ApacheでこのMIMEタイプを指定するには、プロファイルに次の行を追加します.

AddType text/cache-manifest .appcache

Google App Engineのアプリで.このMIMEタイプをyamlファイルに指定すると、次の内容が追加されます.

- 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

この例では、このインベントリファイルを指定したWebページに4つのファイルをキャッシュします.
次の点に注意してください.

CACHE MANIFEST文字列は、最初の行にあり、少なくはありません.

サイトのキャッシュデータ量は5 MBを超えてはならない.ただし、Chromeのオンラインアプリケーションストア向けのアプリケーションを作成する場合は、unlimitedStorageを使用して制限を解除します.

インベントリファイルまたは指定されたリソースがダウンロードできない場合は、キャッシュ更新プロセス全体を実行できません.この場合、ブラウザは元のアプリケーションキャッシュを使用し続けます.

さらに複雑な例を見てみましょう.

CACHE MANIFEST
# 2010-06-18:v2# Explicitly cached 'master entries'.
CACHE:/favicon.ico
index.html
stylesheet.css
images/logo.png
scripts/main.js

# Resources that require the user to be online.
NETWORK:
login.php
/myapi
http://api.twitter.com# static.html will be served if main.py is inaccessible# offline.jpg will be served in place of all images in images/large/# offline.html will be served in place of all other .html files
FALLBACK:/main.py /static.html
images/large/ images/offline.jpg
*.html /offline.html

「#」で始まる行はコメント行ですが、他の用途にも使用できます.アプリケーション・キャッシュは、インベントリ・ファイルが変更された場合にのみ更新されます.たとえば、画像リソースを変更したり、JavaScript関数を変更したりした場合、これらの変更は再キャッシュされません.ブラウザがキャッシュファイルをリフレッシュするには、インベントリファイル自体を変更する必要があります.生成されたバージョン番号、ファイルハッシュ値、またはタイムスタンプを使用してコメント行を作成し、ユーザーがソフトウェアの最新版を取得できるようにします.また、「キャッシュの更新」セクションで説明したように、新しいバージョンが表示された後に、キャッシュをプログラミングで更新することもできます.
明細書は、CACHE、NETWORK、およびFALLBACKの3つの異なる部分を含むことができる.CACHE :
これはエントリのデフォルトです.このヘッダーの下にあるファイルが最初にダウンロードされます(または、CACHE MANIFEST以降のファイル)は、これらのファイルを明示的にキャッシュします.NETWORK :
このセクションの次のファイルは、サーバに接続する必要があるホワイトリストリソースです.ユーザーがオフラインであるかどうかにかかわらず、これらのリソースに対するすべてのリクエストはキャッシュを迂回します.ワイルドカードを使用できます.FALLBACK :
このセクションはオプションで、リソースにアクセスできない場合のバックアップページを指定します.1番目のURIはリソースを表し、2番目はバックアップページを表します.2つのURIは関連付けられ、インベントリファイルと同じソースでなければなりません.ワイルドカードを使用できます.
これらのセクションは任意の順序で並べられ、各セクションは同じリストで繰り返し表示されます.
次のリストでは、ユーザーがWebサイトのルートにオフラインでアクセスしようとしたときに表示される「総合的」なWebページ(offline.html)を定義し、リモート・Webサイトのリソースなど、他のすべてのリソースにインターネット接続が必要であることを示します.

CACHE MANIFEST
# 2010-06-18:v3# Explicitly cached entries
index.html
css/style.css

# offline.html will be displayed if the user is offline
FALLBACK:/ /offline.html

# All other resources (e.g. sites) require the user to be online. 
NETWORK:*# Additional resources to cache
CACHE:
images/logo1.png
images/logo2.png
images/logo3.png

注意:インベントリファイルを参照するHTMLファイルが自動的にキャッシュされます.したがって、リストに追加する必要はありませんが、これをお勧めします.
HTTPキャッシュヘッダおよびSSLによって提供されるウェブページに設定されたキャッシュ制限は、キャッシュリストに置き換えられることに注意してください.従って、httpsが提供するウェブページを介してオフライン運転を実現することができる.
キャッシュの更新
次の場合を除き、オフラインで適用するとキャッシュ状態が維持されます.

ユーザーは、ブラウザからWebサイトへのデータストレージを消去しました.

インベントリファイルが変更されました.注意:リストにリストされているファイルを更新すると、ブラウザがリソースを再キャッシュするわけではありません.インベントリファイル自体を変更する必要があります.

アプリケーションキャッシュは、プログラミングによって更新される.

キャッシュステータスwindow.applicationCacheオブジェクトは、ブラウザのアプリケーションキャッシュへのプログラミングアクセス方式である.statusプロパティは、キャッシュの現在のステータスを表示するために使用できます.

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

キャッシュをプログラミングで更新するには、applicationCache.update()を呼び出します.この操作では、インベントリファイルが変更された場合にユーザーのキャッシュを更新しようとします.最後に、applicationCache.statusがUPDATEREADYの状態にある場合、applicationCache.swapCache()を呼び出して元のキャッシュを新しいキャッシュに置き換えることができる.

var appCache = window.applicationCache;

appCache.update();// Attempt to update the user's cache....if(appCache.status == window.applicationCache.UPDATEREADY){
  appCache.swapCache();// The fetch was successful, swap in the new cache.}

このようにupdate()およびswapCache()を使用しても、更新されたリソースはユーザに提供されないことに注意してください.このプロセスは、ブラウザに新しいリストがあるかどうかを確認し、指定した更新内容をダウンロードし、アプリケーションキャッシュを再入力させるだけです.したがって、ユーザーに新しいコンテンツを提供するには、Webページを2回再ロードする必要があります.1回目は新しいアプリケーションキャッシュを取得し、2回目はWebコンテンツをリフレッシュします.
幸いなことに、2回再ロードする手間を避けることができます.ユーザーを最新のWebサイトに更新するには、Webロード時のupdatereadyイベントをリスニングするリスナーを設定します.

// Check if a new cache is available on page load.
window.addEventListener('load',function(e){

  window.applicationCache.addEventListener('updateready',function(e){if(window.applicationCache.status == window.applicationCache.UPDATEREADY){// Browser downloaded a new app cache.// Swap it in and reload the page to get the new hotness.
      window.applicationCache.swapCache();if(confirm('A new version of this site is available. Load it?')){
        window.location.reload();}}else{// Manifest didn't changed. Nothing new to server.}},false);},false);

AppCacheイベント
予想通り、追加のイベントはキャッシュのステータスをリスニングするために使用されます.ブラウザは、ダウンロードの進行状況、キャッシュ更新の適用、エラーステータスなどの状況で対応するイベントをトリガーします.次のコード・セグメントは、キャッシュ・イベント・タイプごとにイベント・リスナーを設定します.

function handleCacheEvent(e){//...}function handleCacheError(e){
  alert('Error: Cache failed to update!');};// Fired after the first cache of the manifest.
appCache.addEventListener('cached', handleCacheEvent,false);// Checking for an update. Always the first event fired in the sequence.
appCache.addEventListener('checking', handleCacheEvent,false);// An update was found. The browser is fetching resources.
appCache.addEventListener('downloading', handleCacheEvent,false);// The manifest returns 404 or 410, the download failed,// or the manifest changed while the download was in progress.
appCache.addEventListener('error', handleCacheError,false);// Fired after the first download of the manifest.
appCache.addEventListener('noupdate', handleCacheEvent,false);// Fired if the manifest file returns a 404 or 410.// This results in the application cache being deleted.
appCache.addEventListener('obsolete', handleCacheEvent,false);// Fired for each resource listed in the manifest as it is being fetched.
appCache.addEventListener('progress', handleCacheEvent,false);// Fired when the manifest resources have been newly redownloaded.
appCache.addEventListener('updateready', handleCacheEvent,false);

インベントリファイルまたは指定したリソースがダウンロードできない場合は、更新全体が失敗します.この場合、ブラウザは元のアプリケーションキャッシュを使用し続けます.