Rozdział 9. Aplikacje offline

> Dodaj do ulubionych

Do rzeczy

Co to jest aplikacja sieciowa offline? W pierwszej chwili wydaje się, że to sprzeczność. Strony internetowe przecież pobiera się z internetu i wyświetla w przeglądarce. Żeby coś pobrać z internetu, trzeba być z nim połączonym. Jak można coś pobrać nie mając połączenia z internetem? Oczywiście nie da sie. Ale można pobrać wszystko, co potrzeba będąc online. Taka jest właśnie zasada działania aplikacji offline HTML5.

Najprościej rzecz ujmując aplikacja sieciowa offline to lista adresów URL — plików HTML, CSS, JavaScript, obrazów i innych zasobów. Na stronie głównej takiej aplikacji znajduje się odnośnik do tej listy, zwanej plikiem manifestu będącym zwykłym plikiem tekstowym umieszczonym gdzieś na serwerze. Przeglądarka obsługująca aplikacje offline HTML5 odczyta tę listę adresów URL z manifestu, pobierze zasoby, zapisze je na lokalnym dysku i będzie automatycznie aktualizować dane, gdy coś się w nich zmieni. Gdy będziesz korzystać z aplikacji bez połączenia z internetem, przeglądarka automatycznie będzie serwować lokalne kopie plików.

Jak dokładnie to będzie wyglądać zależy od ciebie. W DOM jest dostępny znacznik informujący czy internet jest podłączony czy nie. Istnieją zdarzenia wyzwalane w reakcji na zmianę stanu połączenia (w jednej chwili jesteś podłączony, a w innej nuż nie i odwrotnie). I to w zasadzie wszystko. Jeżeli aplikacja utworzy jakieś dane albo zapisze jakiś stan, to twoim zadaniem jest zapisać te dane na lokalnym dysku gdy nie ma połączenia z internetem i synchronizacja ich z serwerem, gdy tylko takie połączenie się pojawi. Innymi słowy dzięki HTML5 aplikacje mogą działać offline. Sam decydujesz, co będziesz robić.

Obsługa technologii offline
IEFirefoxSafariChromeOperaiPhoneAndroid
·3.5+4.0+5.0+10.6+2.1+2.0+

Manifest bufora

Centralnym punktem aplikacji offline jest plik manifestu bufora. Czym jest plik manifestu? Jest to lista zasobów, których aplikacja może potrzebować po odłączeniu od internetu. Aby zainicjować proces ich pobierania i buforowania, należy wskazać ten plik za pomocą atrybutu manifest elementu <html>.

<!DOCTYPE html>
<html manifest="/cache.manifest">
<body>
...
</body>
</html>

Plik manifestu może znajdować się w dowolnym miejscu na serwerze, ważne aby był serwowany jako typ text/cache-manifest. Jeśli używasz serwera Apache, to możesz dodać dyrektywę AddType do znajdującego się w katalogu głównym pliku .htaccess:

AddType text/cache-manifest .manifest

Pamiętaj też, że plik manifestu musi mieć rozszerzenie .manifest. Jeśli używasz innego serwera albo masz inaczej skonfigurowany serwer Apache, to informacji na temat ustawiania nagłówka Content-Type poszukaj w dokumentacji.

Pytanie do profesora Kodeckiego

P: Moja aplikacja sieciowa obejmuje więcej niż jedną stronę. Czy atrybut manifest musi znajdować się na każdej stronie, czy wystarczy na głównej?

O: Atrybut manifest wskazujący plik manifestu musi znajdować się na każdej stronie aplikacji sieciowej.

Wszystkie strony twojej aplikacji mają już przypisany plik manifestu, który jest prawidłowo serwowany z nagłówkiem Content-Type. Ale co konkretnie wpisać w tym manifeście? To jest najciekawsza część całego zadania.

W pierwszym wierszu każdego manifestu zawsze wpisuje się poniższy kod:

CACHE MANIFEST

Później plik dzieli się na trzy części: „buforową”, „awaryjną” oraz „internetową”. Każda sekcja ma nagłówek występujący jako jedyny w wierszu. Jeśli w manifeście nie ma żadnego nagłówka, wszystkie zasoby należą do sekcji „buforowej”. Raczej nie próbuj zgłębiać dlaczego te nazwy są takie a nie inne, bo może cię rozboleć głowa.

Poniżej znajduje się przykład poprawnie zbudowanego pliku manifestu. Wymieniono w nim trzy zasoby: pliki CSS i JavaScript oraz obraz JPEG.

CACHE MANIFEST
/clock.css
/clock.js
/clock-face.jpg

W pliku tym nie ma żadnych nagłówków, a więc wszystkie zasoby należą do sekcji „explicit”. Zasoby znajdujące się w sekcji „explicit” są pobierane i zapisywane na dysku lokalnym oraz używane w miejsce internetowych odpowiedników, gdy nie ma połączenia z siecią. Jeśli więc użyjemy tego pliku manifestu, przeglądarka pobierze i zapisze na dysku pliki clock.css, clock.js oraz clock-face.jpg z katalogu głównego serwera. Gdy odłączysz sieć i odświeżysz stronę w przeglądarce, zasoby te nadal będą dostępne, tylko że już z dysku lokalnego.

Pytanie do profesora Kodeckiego

P: Czy muszę wymieniać na liście manifestu strony HTML?
O: Tak i nie. Jeśli cała aplikacja mieści się na jednej stronie internetowej, to wystarczy że będzie miała dołączony plik manifestu przy użyciu atrybutu manifest. Strona HTML mająca atrybut manifest jest uważana za część aplikacji sieciowej i jeśli użytkownik ją otworzy, to nie ma potrzeby jej wymieniać w manifeście. Jeżeli jednak aplikacja składa się z kilku stron, należy je wszystkie wymienić w manifeście, ponieważ inaczej przeglądarka nie będzie wiedziała, że w ogóle są jeszcze jakieś inne strony HTML, które należy pobrać i zapisać w buforze.

Sekcje sieciowe

Oto nieco bardziej skomplikowany przykład. Przypuśćmy, że mamy aplikację zegarową i chcemy, aby śledziła odwiedzających przy użyciu skryptu tracking.cgi ładowanego dynamicznie za pomocą atrybutu <img src>. Zapisanie tego zasobu w buforze mijałoby się z celem, a więc należy zaznaczyć, że nigdy nie powinien być pobierany ani dostępny offline. Oto odpowiedni manifest:

CACHE MANIFEST
NETWORK:
/tracking.cgi
CACHE:
/clock.css
/clock.js
/clock-face.jpg

W tym pliku znajdują się nagłówki sekcji. W wierszu NETWORK: zaczyna się sekcja „internetowa”. Zasoby w niej wymienione nie są buforowane ani dostępne offline. (Próba załadowania ich bez połączenia internetowego spowoduje błąd.) W wierszu CACHE: zaczyna się sekcja „buforowa”. Pozostała część manifestu jest taka sama, jak wcześniej. Wszystkie trzy wymienione zasoby zostaną pobrane i zapisane w buforze.

Sekcje awaryjne

W plikach manifestu może znajdować się jeszcze jeden rodzaj sekcji: sekcja awaryjna. Definiuje się w niej składniki zastępcze dla zasobów internetowych, które nie zostały zbuforowane albo których nie udało się poprawnie zbuforować. W specyfikacji HTML5 podano sprytny przykład wykorzystania tej sekcji:

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*

O co w tym chodzi? Najpierw wyobraź sobie portal zawierający miliony stron, taki jak np. Wikipedia. Nie da sie pobrać takiej witryny w całości i zapewne nikt by nie chciał tego robić. Ale wyobraźmy sobie, że jej część możemy udostępnić offline. Jak zdecydować które strony powinny zostać pobrane? Może tak: pobierzemy każdą stronę z portalu, którą kiedykolwiek oglądaliśmy. Wliczałyby się w to wszystkie przeczytane artykuły encyklopedii, strony dyskusji (na których dyskutuje się o poszczególnych artykułach) oraz strony edycji (na których zmienia się treść artykułów).

O to właśnie chodzi w tym manifeście. Przypuśćmy, że każda strona HTML (artykułu, dyskusyjna, edycji, historii) Wikipedii ma dołączony ten manifest. Gdy otwierana jest strona z jakimkolwiek manifestem, przeglądarka wie, że strona ta jest składnikiem aplikacji sieciowej i sprawdza czy już ją zna. Jeśli do tej pory jeszcze nie pobrała tego konkretnego pliku manifestu, tworzy nowy bufor aplikacji offline, pobiera wszystkie zasoby wymienione w tym manifeście oraz dodaje do tego bieżącą stronę. Jeżeli przeglądarka zna już ten plik manifestu, to tylko dodaje bieżącą stronę do już istniejącego bufora. W obu przypadkach odwiedzona strona trafia do bufora. To bardzo ważne. Oznacza to, że można utworzyć aplikację sieciową „leniwie” dodającą strony do bufora, gdy są otwierane. Nie trzeba wymieniać na liście każdej strony HTML, którą chce się buforować.

Teraz spójrz na sekcję awaryjną. W tym manifeście zawiera ona tylko jeden wiersz kodu. Pierwsza część (przed spacją) to nie adres URL. Jest to wzór adresu URL. Ten jeden znak (/) oznacza każdą stronę witryny, nie tylko do stronę główną. Gdy spróbujesz otworzyć stronę będąc offline, przeglądarka najpierw poszuka jej w buforze. Jeśli ją tam znajdzie (ponieważ wcześniej już ją czytałeś i została automatycznie zapisana), to wyświetli jej lokalną kopię. Jeśli strony nie będzie w buforze, to zamiast powiadomienia o błędzie przeglądarka wyświetli stronę /offline.html, która została podana w drugiej części wiersza sekcji awaryjnej.

Na koniec przyjrzymy się jeszcze sekcji sieciowej. W tym manifeście sekcja sieciowa ma tylko jeden wiersz kodu zawierający znak *. Ma on w tym miejscu specjalne znaczenie. Jest to tzw. „znak wieloznaczny listy sieciowej”. Mówiąc prościej w ten sposób informujemy, że chcemy aby przeglądarka pobrała pod oryginalnym adresem wszystko czego nie ma w buforze, jeśli jest połączenie z internetem. Jest to ważne dla „otwartych” aplikacji sieciowych. Jeśli będziemy przeglądać strony naszej hipotetycznej Wikipedii online, przeglądarka będzie pobierać obrazy, filmy i inne osadzone składniki w normalny sposób, nawet jeśli będą znajdowały się pod inną domeną. (W dużych portalach, nawet nie mających nic wspólnego z aplikacjami sieciowymi offline, często wykorzystuje się tzw. sieci CDN. Polega to na tym, że strony HTML są generowane i serwowane lokalnie, a obrazy i filmy są serwowane z sieci dostarczania treści (CDN) znajdującej się pod inną domeną.) Bez tego symbolu wieloznacznego nasza Wikipedia zachowywałaby się bardzo dziwnie podczas przeglądania stron online — nie ładowałaby obrazów i filmów z zewnętrznych domen!

Czy ten przykład jest kompletny? Nie. Wikipedia nie składa się tylko z plików HTML. Na każdej jej stronie używane są także wspólne pliki CSS, JavaScript i obrazy. Każdy z tych zasobów należałoby wymienić na liście w sekcji CACHE: manifestu, aby strony prezentowały i zachowywały się poprawnie także offline. Sekcja awaryjna umożliwia tworzenie „otwartych” aplikacji sieciowych pozwalając rozszerzyć listę zasobów poza te, które zostaną bezpośrednio wymienione w części buforowej manifestu.

Przepływ zdarzeń

Od początku rozdziału piszę o aplikacjach sieciowych offline, manifestach oraz buforze offline aplikacji, ale nie podaję żadnych konkretów. Pliki się pobierają, przeglądarki podejmują decyzje i wszystko po prostu działa. Ale ty wiesz swoje, prawda? To znaczy, przecież mówimy o programowaniu sieciowym. A tu nic nigdy tak po prostu sobie nie działa.

Dla tego najpierw omówię przepływ zdarzeń. A dokładniej mówiąc, przepływ zdarzeń DOM. Gdy otworzysz stronę mającą dołączony plik manifestu, przeglądarka uruchamia serię zdarzeń na obiekcie window.applicationCache. Wiem że to jest skomplikowane, ale uwierz mi, że to jest i tak najprostsza wersja, jaką udało mi się wymyślić bez pomijania ważnych informacji.

  1. Gdy przeglądarka odkryje atrybut manifest w elemencie <html>, uruchamia zdarzenie checking. (Wszystkie opisywane tu zdarzenia dotyczą obiektu window.applicationCache.) Zdarzenie checking jest uruchamiane zawsze, niezależnie od tego czy ta konkretna strona albo jakakolwiek inna wskazująca ten manifest była już odwiedzana.
  2. Jeśli przeglądarka nigdy wcześniej nie pobrała tego pliku manifestu:
    • Uruchomi zdarzenie downloading, a później rozpocznie pobieranie zasobów wymienionych na liście manifestu.
    • Podczas pobierania zasobów przeglądarka od czasu do czasu uruchomi zdarzenie progress zawierające informacje o liczbie pobranych plików oraz ile zostało jeszcze do pobrania.
    • Po pobraniu wszystkich zasobów z listy manifestu przeglądarka uruchamia ostatnie zdarzenie o nazwie cached. Jest to sygnał, że cała aplikacja została pobrana do bufora i można jej używać offline. To wszystko.
  3. Jeśli jednak ta lub inna strona wskazująca ten sam manifest była już wcześniej odwiedzona, to przeglądarka zna już ten plik manifestu. To znaczy, że niektóre zasoby mogą już znajdować się w buforze. W istocie zbuforowana może być już cała aplikacja. Powstaje więc pytanie co zmieniło się w manifecie od ostatniego pobrania go przez przeglądarkę?
    • Jeśli nic, następuje uruchomienie zdarzenia noupdate. To wszystko.
    • Jeśli coś się zmieniło, przeglądarka uruchamia zdarzenie downloading i rozpoczyna pobieranie wszystkich wymienionych na liście manifestu zasobów.
    • Podczas pobierania zasobów przeglądarka od czasu do czasu uruchomi zdarzenie progress zawierające informacje o liczbie pobranych plików oraz ile zostało jeszcze do pobrania.
    • Po ponownym pobraniu wszystkich zasobów z listy manifestu przeglądarka uruchamia ostatnie zdarzenie o nazwie updateready. Jest to sygnał, że nowa wersja aplikacji została pobrana do bufora i można jej używać offline. Nowa wersja nie jest jeszcze używana. Aby zastąpić starą wersję nową bez zmuszania użytkownika do odświeżenia strony, można ręcznie wywołać funkcję window.applicationCache.swapCache().

Jeśli w którymkolwiek momencie procesu coś się nie uda, przeglądarka zgłosi zdarzenie error i wstrzyma wszystko. Oto krótka lista potencjalnych problemów:

  • Manifest zwrócił błąd HTTP 404 (nie znaleziono strony) lub 410 (usunięty na zawsze).
  • Manifest został znaleziony i nie zmienił się, ale wskazująca go strona HTML nie została poprawnie pobrana.
  • Manifest zmienił się w trakcie trwania aktualizacji.
  • Manifest został znaleziony i nie zmienił się, ale przeglądarce nie udało się pobrać jednego z wymienionych w nim zasobów.

Sztuka usuwania błędów, czyli „Zabij mnie! Zabij mnie natychmiast!”

W tej części chcę zwrócić uwagę na dwie ważne kwestie. O pierwszej już przed chwilą pisałem, ale na pewno nie zapadło ci to w pamięć, więc powtarzam: jeśli nie uda sie pobrać choćby jednego zasobu wymienionego w manifeście, w łeb weźmie cały proces buforowania aplikacji. Przeglądarka uruchomi zdarzenie error, ale nie będzie w nim wskazówki informującej,co się nie udało. Z tego powodu usuwanie błędów z aplikacji offline może być trudniejsze niż innych.

Druga ważna rzecz to coś, co może nie wydawać się błędem tylko poważną usterką przeglądarki, dopóki nie uświadomisz sobie o co tak naprawdę chodzi. Ma to związek ze sposobem sprawdzania przez przeglądarkę czy zmienił się plik manifestu. Jest to proces trzyetapowy. Nudne to, ale ważne, więc czytaj uważnie.

  1. Normalnie protokół HTTP nakazuje przeglądarce sprawdzenie czy plik manifestu nie wygasł. Serwer do manifestu, podobnie jak do każdego innego typu pliku wysyłanego przy użyciu protokołu HTTP, dołącza metainformacje w nagłówkach odpowiedzi HTTP. Niektóre z tych nagłówków (Expires i Cache-Control) informują przeglądarkę w jaki sposób może buforować plik bez pytania serwera o zmiany. Ten rodzaj buforowania nie ma nic wspólnego z aplikacjami sieciowymi offline. Dotyczy ono każdego pliku HTML, CSS, JavaScript, obrazu itd.
  2. Jeśli manifest wygaśnie (według jego nagłówków HTTP), przeglądarka spyta serwer, czy jest nowa wersja i jeśli tak, to pobierze go ponownie. W tym celu przeglądarka wyśle żądanie HTTP zawierające datę ostatniej modyfikacji pliku manifestu, którą serwer dodał do nagłówków odpowiedzi HTTP ostatnim razem, gdy przeglądarka pobierała manifest. Jeśli serwer stwierdzi, że manifest nie zmienił się od tego czasu, zwróci stan 304 (Not Modified). To nie ma nic wspólnego ze specyfiką aplikacji offline. Działania te są wykonywane praktycznie dla wszystkich zasobów sieciowych.
  3. Jeżeli serwer uzna, że manifest się zmienił, zwróci kod stanu HTTP 200 (OK) i treść nowego pliku wraz z nowym nagłówkiem Cache-Control i datą ostatniej modyfikacji, dzięki czemu czynności 1 i 2 zostaną poprawnie wykonane następnym razem. (Protokół HTTP jest fajowski, bo serwery mogą robić plany na przyszłość. Jeśli serwer musi wysłać plik, zrobi wszystko, aby nie trzeba było go wysyłać dwa razy bez powodu. Po pobraniu nowego manifestu przeglądarka porówna jego zawartość z treścią pobranej poprzednio kopii. Jeżeli zawartość manifestu będzie taka sama, jak wcześniej, przeglądarka nie pobierze żadnego z wymienionych plików.

Na każdym z wymienionych etapów można się wyłożyć podczas tworzenia i testowania aplikacji offline. Wyobraź sobie na przykład, że tworzysz plik manifestu, a za 10 minut przypominasz sobie, że trzeba do niego dodać jeszcze jeden zasób. Nic trudnego, prawda? Wystarczy dopisać jedną linijkę kodu i gotowe. A tu Zonk: odświeżasz stronę, przeglądarka wykrywa atrybut manifest, uruchamia zdarzenie checking i… nic. Przeglądarka uparcie twierdzi, że manifest się nie zmienił. Dlaczego? Ponieważ domyślnie serwer nakazuje przeglądarkom buforowanie statycznych plików przez kilka godzin (poprzez użycie nagłówka Cache-Control protokołu HTTP). To znaczy, że przeglądarka nie wyjdzie poza pierwszy krok trzyetapowego procesu. Oczywiście serwer będzie wiedział, że plik się zmienił, ale przeglądarka go o to nawet nie spyta. Dlaczego? Ponieważ ostatnim razem gdy pobrała manifest, serwer nakazał jej zachować go w buforze przez kilka godzin (poprzez użycie nagłówka Cache-Control protokołu HTTP). I teraz po 10 minutach przeglądarka posłusznie wykonuje polecenie serwera.

Dla jasności dodam, że to nie jest błąd tylko funkcja. Wszystko działa dokładnie tak, jak powinno. Gdyby serwery nie nakazywały przeglądarkom (i pośrednikom) buforowania plików, to sieć uległaby przeciążeniu w ciągu kilku godzin. Ale to dla ciebie małe pocieszenie po kilku godzinach dociekania dlaczego przeglądarka uparła się nie wczytywać zmienionego manifestu. (Co ciekawsze, jeśli poczekasz trochę dłużej,to jakimś cudem plik manifestu wkradnie się w łaski przeglądarki! Będzie to spowodowane wygaśnięciem bufora HTTP! Dokładnie tak, jak powinno być! Zabij mnie! Zabij mnie natychmiast!)

Oto, co powinieneś zrobić: zmień konfigurację serwera tak, aby plik manifestu nie podlegał buforowaniu HTTP. Użytkownicy serwera Apache mogą dodać poniższe dwa wiersze kodu do pliku .htaccess:

ExpiresActive On
ExpiresDefault "access"

Dyrektywy te wyłączają buforowanie całego katalogu i wszystkich jego podkatalogów. Jednak w środowisku produkcyjnym nie należy tego robić, dlatego powinno się dodać dyrektywę <Files>, aby zaznaczyć że reguła dotyczy tylko manifestu albo utworzyć podkatalog zawierający tylko plik .htaccess i manifest. Oczywiście na innych serwerach konfiguracja wygląda nieco inaczej i należy poszukać w dokumentacji informacji na temat ustawiania nagłówków HTTP buforowania.

Po wyłączeniu buforowania HTTP manifestu i tak może się zdarzyć, że zmienisz jeden z zasobów w buforze aplikacji, a i tak będzie on widoczny pod tym samym adresem URL na serwerze. W tym przypadku uziemi cię drugi krok trzyetapowego procesu. Jeśli plik manifestu się nie zmieni, przeglądarka nie zauważy że zmienił się jeden z już zbuforowanych zasobów. Rozważmy poniższy przykład:

CACHE MANIFEST
# rev 42
clock.js
clock.css

Jeśli zmienisz plik clock.css i wyślesz go na serwer, zmiany nie zostaną uwzględnione, ponieważ nic nie zmieniło się w pliku manifestu. Za każdym razem gdy coś zmienisz w zasobach aplikacji offline, musisz też coś zmienić w manifeście. Może wystarczyć zmiana jednej litery. Najprostszym sposobem, jaki udało mi się wynaleźć jest dodanie komentarza z numerem wersji. Jeśli zmienisz numer wersji w komentarzu, serwer zwróci zmieniony manifest, przeglądarka zauważy, że coś się zmieniło i rozpocznie proces ponownego pobierania wszystkich zasobów.

CACHE MANIFEST
# rev 43
clock.js
clock.css

Budujemy aplikację sieciową offline!

Pamiętasz grę Halma, którą poznałeś w rozdziale o elemencie canvas i którą udoskonaliliśmy w rozdziale o zapisywaniu danych w lokalnych magazynach? Teraz umożliwimy granie w nią offline.

Do tego potrzebny nam będzie manifest z listą wszystkich potrzebnych w grze zasobów. Należą do nich główna strona HTML, jeden plik JavaScript zawierający cały kod gry i… koniec. Nie ma żadnych obrazów, ponieważ wszystkie rysunki są wykonane programowo przy użyciu API canvas. Wszystkie style CSS znajdują się w elemencie <style> na początku strony HTML. Oto w takim razie treść naszego manifestu:

CACHE MANIFEST
halma.html
../halma-localstorage.js

Kilka słów o ścieżkach. W katalogu examples/ utworzyłem podkatalog offline/, w którym znajduje się plik manifestu. Jako że strona HTML potrzebuje jeszcze drobnego dodatku do działania offline (zaraz o nim napiszę), utworzyłem osobną kopię tego pliku HTML, która również znajduje się w podkatalogu offline/. Ponieważ plik JavaScript nie wymaga żadnych zmian, bo dodaliśmy obsługę magazynu lokalnego, używam dokładnie tego samego pliku .js, który znajduje się w katalogu nadrzędnym (examples/). Ścieżki do wszystkich plików wyglądają tak:

/examples/localstorage-halma.html
/examples/halma-localstorage.js
/examples/offline/halma.manifest
/examples/offline/halma.html

W manifeście (/examples/offline/halma.manifest) wskazujemy dwa pliki. Pierwszy z nich to wersja offline pliku HTML (/examples/offline/halma.html). Jako że te dwa pliki znajdują się w tym samym folderze, ścieżka do niego nie ma żadnego przedrostka. Po drugie dołączamy plik JavaScript znajdujący się w katalogu nadrzędnym (/examples/halma-localstorage.js). Wskazujemy go przy użyciu względnej ścieżki URL: ../halma-localstorage.js. Składnia jest taka sama, jak przy wstawianiu obrazów na stronę przy użyciu elementu <img src>. Jak zobaczysz w następnym przykładzie, można też używać ścieżek bezwzględnych (rozpoczynających się od katalogu głównego domeny), a nawet mogą być bezwzględnymi adresami URL (wskazującymi zasoby pod innymi domenami).

Teraz w pliku HTML musimy dodać atrybut manifest wskazujący plik manifestu.

<!doctype html>
<html lang="en" manifest="halma.manifest">

To wszystko! Gdy przeglądarka obsługująca aplikacje offline wczyta tę stronę HTML aplikacji offline, pobierze dołączony manifest i rozpocznie pobieranie wszystkich wymienionych w nim zasobów oraz zapisze je w buforze. Od tej pory przy każdej kolejnej wizycie na stronie jej wyświetlaniem będzie zarządzać algorytm obsługi aplikacji offline. Możesz grać w grę offline, a dodatkowo dzięki zapisywaniu stanu możesz ją przerwać w dowolnym momencie i wrócić do gry później.

Lektura uzupełniająca

Standardy:

Dokumentacje przeglądarek:

Kursy i dema:

Narzędzia aplikacji offline HTML5:

Autor: Mark Pilgrim

Źródło: http://diveintohtml5.info/

Tłumaczenie: Łukasz Piwko

Treść tej strony jest dostępna na zasadach licencji CC BY 3.0