Главная » Полезные статьи » Разное » Запуск веб-приложений в оффлайн с помощью HTML5 AppCache
Распечатать статью

Запуск веб-приложений в оффлайн с помощью HTML5 AppCache

Веб-приложения стали частью жизни для многих людей, так что многие из нас используют их постоянно. А что если бы их можно было использовать и в оффлайн-режиме? До недавнего времени не было ни одного практического способа этого сделать — однако, с внедрением рабочей группой W3C функции кэширования приложений в HTML5, стало возможным запускать веб-приложения в режиме оффлайн так же как и в онлайн.

Зачем запускать веб-приложения в режиме оффлайн?

Веб-приложения становятся каждый день все более сложными и мощными. Существует множество примеров веб-приложений, способных полностью заменить десктоп-приложения в различных областях (вспомним хотя бы Google Docs, Picasa и другие). Однако большим недостатком таких приложений является невозможность работы в отсутствие Интернета.

Именно эту проблему и разрешает оффлайн-хранилище HTML5. Этот недостаток устраняется с помощью хранения файлов в кэше, и когда пользователь работает в оффлайн-режиме, браузер всё ещё имеет доступ к необходимым файлам. Этими файлами могут быть страницы HTML, каскадные таблицы стилей CSS, скрипты JavaScript, или любые другие ресурсы, необходимые веб-приложению для работы.

Сохранение файлов для оффлайн-использования с помощью кэша приложения

В HTML5 существуют функции для веб-приложений, позволяющих работать в оффлайн. Набор таких функций именуется AppCache. Файлы, сохраненные в AppCache, доступны приложению, даже когда пользователь находится в оффлайн. Файлы для хранения в AppCache можно указать с помощью файла описания (manifest file).

Чем кэш приложения отличается от обычного кэша браузера?

Существует несколько отличий AppCache от обычного кэша браузеров. Прежде всего AppCache предназначен для полноценных веб-приложений, в то время как кэш браузера — чаще всего для обычных веб-страниц. В обычный кэш браузера добавляются любые страницы, в то время как в AppCache попадают только страницы, указанные в manifest-файле. Кроме того, обычный кэш ненадежен, так как мы не можем быть уверены в том, какие страницы (и ресурсы, связанные с ними) будут доступны в конкретное время.

AppCache действительно полезен, потому что теперь разработчик имеет значительно больший программный контроль над кэшем, что увеличивает надежность работы веб-приложений, в том числе и в автономном оффлайн-режиме. Стоит заметить, что вы можете хранить несколько страниц в одном AppCache. Кроме того, с помощью AppCache вы можете использовать API для определения состояния AppCache и его обновления по необходимости.

manifest-файл

Этот файл размещается на сервере и определяет файлы, которые необходимо хранить в AppCache браузера клиента и использовать в случае перехода в автономный режим.

Вы можете придумать для manifest-файла любое имя, но лучше дать ему расширение .manifest. Каждый manifest-файл должен начинаться с фразы CACHE MANIFEST, после которой необходимо перечислить файлы, которые вы хотите сохранить в кэше. В файле можно оставлять комментарии с помощью добавления символа # в начало строки. Пример простого manifest-файла:

CACHE MANIFEST
#Комментарий

style.css
script.js
index.htm

manifest-файл должен иметь правильный MIME-тип — text/cache-manifest. Чтобы это обеспечить, можно добавить расширение .manifest к manifest-файлу и написать следующую инструкцию в файл .htaccess на сервере:

AddType text/cache-manifest .manifest

Добавление ссылки на manifest-файл в HTML-файле

Теперь после создания manifest-файла необходимо сделать ссылку на этот файл в HTML. Это можно сделать с помощью атрибута manifest тега <html>. Например:

1 <html manifest="demo.manifest">

Если веб-приложение состоит из нескольких HTML-страниц, необходимо сделать такую ссылку в каждой странице.

Использование разделов AppCache

С помощью разделов мы можем точно указать, какие файлы необходимо кэшировать, а какие нет.

Явное указание кэшируемых файлов

Вы можете использовать раздел CACHE:, чтобы явно указать, какие файлы необходимо кэшировать. Например, файл из предыдущего примера может быть записан так:

CACHE MANIFEST

CACHE:
style.css
script.js
index.htm

Важно отметить, что путь к кэшируемым файлам должен быть указан относительно manifest-файла. В примерах выше мы предполагаем, что кэшируемые файлы находятся в той же директории, что и manifest-файл. Можно использовать как относительные, так и абсолютные пути к файлам.

Файлы, указанные после заголовка CACHE: будут загружены из кэша AppCache (не с сервера), даже если пользовате, provided that there is no change in the manifest file. Однако, если браузер обнаружит обновленный manifest-файл, тогда новый кэш будет создан согласно данным из новой версии manifest-файла. Так что AppCache может быть бесполезен для часто обновляемых сайтов, например, блогов, но очень полезен для веб-приложений, которым необходимо поддерживать работу в оффлайн-режиме (например, календарям).

Сброс кэша и прямая загрузка с сервера

Если странице назначен manifest-файл, то указанные в нем файлы будут загружаться из кеша и в онлайн, и в оффлайн-режиме. Однако, могут возникнуть ситуации, когда необходимо сбросить кэш отдельных файлов и загрузить их с сервера.

Вообще браузер пытается загрузить файлы, указанные в manifest-файле, из кэша, если же он их не обнаруживает, то возникает ошибка загрузки файлов. Раздел NETWORK: создает исключения из этого правила. Вы можете использовать раздел NETWORK: для указания файлов, которые запрещено кэшировать. Указанные в этом разделе файлы всегда будут загружаться с сервера и никогда не будут частью кэша приложения. Однако, как и любые другие файлы, не указанные в manifest-файле, файлы из раздела NETWORK: могут попадать в обычный кэш браузера.

CACHE MANIFEST

CACHE:
style.css
script.js
index.htm

NETWORK:
style2.css

В этом примере файл style2.css будет всегда загружаться с сервера. Указывать множество файлов в разделе NETWORK: может быть неудобным, в таком случае можно воспользоваться символом * (звездочка), указав его в качестве URL в разделе NETWORK:, что приведет к сбросу кэша приложения у всех файлов.

Providing fallback content

Раздел FALLBACK: служит для указания замен для файлов в случае невозможности их загрузки:

CACHE MANIFEST

CACHE:
style.css
script.js
index.htm

NETWORK:
style2.css

FALLBACK:
main_image.jpg backup_image.jpg
/images notavailable.jpg

Предполагается, что заменяющий контент загружается в кэш и будет использоваться только в том случае, когда основной контент недоступен. В примере выше backup_image.jpg сохраняется в кэше приложения, так что если невозможно загружить main_image.jpg, то файл backup_image.jpg будет использован вместо этого.

Второй строкой в разделе FALLBACK: заменяющая картинка notavailable.jpg, оповещающая пользователя о недоступности изображения, используется для замены всех файлов из директории /images.

Использование API и событий для обновления кэша

Одной из замечательных возможностей кэша приложений является то, что программист может напрямую управлять кэшем. Можно получить доступ к событиям, которые дадут сведения о текущем состоянии кэша приложения, а с помощью функций изменить это состояние. Например, вы можете использовать window.applicationCache для того, чтобы определить поддерживает ли браузер AppCache.

Статусы

Вы можете проверить текущий статус кэша приложения, используя функцию window.applicationCache.status, которая возвращает код статуса:

0 — UNCACHED
Если страница не связана с кэшем приложения. Также AppCache имеет статус 0 во время загрузки кэша.
1 — IDLE
Когда браузер имеет последнюю версию кэша приложения и нет обновленных версий кэша для загрузки, тогда кэш переходит в статус 1.
2 — CHECKING
Во время проверки manifest-файла на обновление кэш переходит в статус 2.
3 — DOWNLOADING
Во время загрузки нового кэша (если обнаружен обновленный manifest-файл) кэш переходит в статус 4.
4 — UPDATEREADY
В тот момент когда браузер заканчивает загрузку нового кэша, то кэш уже готов к использованию (но фактически не используется). Именно в течение этого времени статус равен 4.
5 — OBSOLETE
В случае если manifest-файл не найден, статус становится равным 5 и кэш приложения удаляется. Важно отметить, что в этом случае manifest-файл (или любой файл, указанный в manifest-файле, не имеющим раздела FALLBACK:) не может быть загружен, это трактуется как ошибка, и приложение будет использовать старый кэш.

События

Определенные события возникают в зависимости от состояния AppCache.

checking
Это событие запускается, когда браузер пытается загрузить manifest-файл в первый раз или проверяет обновления manifest-файла.
noupdate
Если на сервере не обнаружено обновленной версии manifest-файла, то срабатывает это событие.
downloading
Это событие срабатывает во время загрузки кэша приложения браузером.
progress
This is fired for each and every file which is downloaded as part of the AppCache.
cached
Это событие срабатывает, когда весь кэш загружен с сервера.
updateready
Это событие срабатывает после загрузки обновленной версии кэша. После того как оно произошло, можно использовать swapCache() (эта функция описана дальше в статье) для использования загруженного кэша браузером.
obsolete
Это событие запускается, если manifest-файл не может быть найден (ошибка 404 или 410).
error
Это событие может происходить по нескольким причинам. Оно происходит, если браузер не может найти manifest-файл или файлы, указанные в нем. Также ошибка может возникать, если manifest-файл обновляется во время его загрузки браузером.

В API кэша приложений можно отметить следующие функции:

  • window.applicationCache.update(): Эта функция запускает процесс загрузки кэша, что по сути аналогично перезагрузке страницы. При этом проверяется, обновился ли manifest-файл, и если он обновился, то происходит загрузка и обновление кэша (согласно разделам manifest-файла). Обратите внимание на то, что хотя новый кэш может быть создан с помощью этой функции, страница будет использовать старый кэш. Чтобы заставить страницу использовать новый кэш, нужно запустить функцию swapCache().
  • window.applicationCache.swapCache(): Эта функция сообщает браузеру о необходимости использования нового кэша, если он доступен.

В обычной ситуации нет необходимости использовать функцию update(), так как браузер должен делать аналогичное действие при перезагрузке страницы. Чаще всего функция swapCache() будет использоваться в сочетание с событием onupdateready.

В следующем примере если вы измените manifest-файл и перезагрузите страницу, браузер загрузит новые файлы в кэш, после чего включит новый кэш (так как будет вызвана функция swapCache):

01 <html manifest="demo.manifest">
02 <head>
03 <script type="text/javascript">
04 addEventListener('onupdateready', function(){
05 window.applicationCache.swapCache();
06 }, false);
07 </script>
08 </head>
09 <body>
10 ...
11 </body>
12 </html>

Если предполагается, что страница не будет часто перезагружаться пользователем, то вам следует периодически вызывать функцию update() для проверки изменений в manifest-файле, а при появлении изменений вызывать функцию swapCache() при возникновении события updateready, что приведет к загрузке и включению нового кэша:

1 setInterval(function () { window.applicationCache.update(); }, 3600000); // Check for an updated manifest file every 60 minutes. If it's updated, download a new cache as defined by the new manifest file.
2 addEventListener('onupdateready', function(){ // when an updated cache is downloaded and ready to be used
3 window.applicationCache.swapCache(); //swap to the newest version of the cache
4 }, false);

В этом примере каждые 60 минут проверяется обновление manifest-файла. Если будет обнаружена новая версия manifest-файла, то указанные в нем файлы будут загружены браузером. Как только это произойдет, будет запущено событие updateready, что означает окончание загрузки нового кэша и готовность его использования. После этого мы можем запустить функцию swapCache(), чтобы заменить старый кэш на новый.

Таким образом мы можем обеспечить актуальность кэша в браузере пользователя.

Заключение

Кэш приложений, описанный в спецификации W3C HTML5, предоставляет совершенно новые возможности для веб-разработчиков. Теперь веб-приложения могут быть кэшированы для оффлайн-использования и стать тем самым еще более мощными и полезными чем прежде.

Источник:   w3pro.ru

Вы можете оставить комментарий, или обратную ссылку на Ваш сайт.

Оставить комментарий

Похожие статьи