HTML 5 – Parte 7 – Suporte para offline

Posted on 20/10/2010

2


Olá pessoal, tudo certin?

Nossa, quanta novidade bacana na especificação do HTML5! Se você chegou agora e quiser ver o que já escrevi sobre HTML5, consulte os posts anteriores dessa série:

Mas … como quem vive de passado é museu, vamos tratar, direto, sem enrolação, do assunto de hoje: html5 offline. Isso mesmo! A nova especificação prevê que nossos aplicativos web poderão funcionar, mesmo quando o “cliente” não tiver conexão contínua com a Internet. Parte do milagre ocorre graças as novas APIs de persistência (Parte 6 e Parte 5). Outra parte está relacionada ao novo modelo de caching (assunto de hoje).

Não sei você, mas eu frequentemente acabo em lugares onde não tenho acesso estável para internet. Já cansei de tentar acessar internet com um modenzinho 3G… e nada!

Em um mundo cada vez mais móvel, fica mais difícil aceitar que aplicativos não funcionem sem algum tipo de conexão e esse é um mal sério de aplicativos para Web.  É lamenável quando abro meu agregador de notícias, descarrego todas as notícias, on-line, e, mais tarde, não consigo acessar esses dados. Mais que isso, nem a interface do meu agregador é carregada (e olha que eu sei que grande parte da informação necessária está lá!)

A especificação do HTML5 permite que nossas “aplicãções on-line” fiquem em cache, gerenciados pelos browsers, e, com isso, elas passem a funcionar, posteriormente, com, ou sem, conexão com a Internet.

Vamos ver como a coisa funciona!

Smiley piscando

Idéia geral por trás do conceito de aplicações HTML5 offline

Para trabalhar offline, um aplicativo precisa apenas ter um manifesto dizendo para o browser o que precisa ser armazenado em cache local (Só isso!). Esse manisfesto é uma simples lista de arquivos. Os arquivos tratadaos podem ser de qualquer tipo, como: CSS, javascript, imagens, etc.

Além de informar o browser sobre o que fazer cache, podemos também informar o que não deverá ser mantido, garantindo que esse recurso seja sempre requisitado via Web (com falha [erro] caso não esteja disponível).

Finalmente, HTML5 nos dá uma possibilidade de indicar um conteúdo alternativo para o caso de haver falha para obtenção de dados (download) para determinados recursos.

Descrevendo comportamento offline: cache manifest

O manifesto é o artefato de uma aplicação que informa o browser o quê deverá ocorrer quando um recurso da internet não estiver disponível. Uma vez que o manifesto seja carregado ou atualizado, dispara uma atualização do objeto applicationCache.

Indicar que uma “aplicação html5” tem um manifesto é muito simples: basta adicionar o atributo manifest ao elemento <html>, apontando para o arquivo (recurso) contendo o manifesto para a aplicação. Observe:


              
1 doctype html> 2 <html manifest="myapp.manifest"> 3 <ul> 4 5 <li> 6 <a href="./page1.html">Page 1 (avaliable offline)a> 7 li> 8 9 <li> 10 <a href="./page2.html"> 11 Page 2 (w/ alternative offline version) 12 a> 13 li> 14 15 <li> 16 <a href="./page3.html">Page 3 (not avaliable offline)a> 17 li> 18 19 ul> 20 html>

              

Repare a linha 2. O atributo manifest avisa o browser de que há um manifesto associado a essa aplicação. Como cada browser irá reagir dependerá de como esse foi implementado; O firefox, por exemplo, questiona o usuário sobre permissão para armazenar o conteúdo do aplicativo.

No nosso exemplo, temos, essencialmente, os seguintes artefatos (aqui, arquivos):

  • a página principal (index.html) – que gostaríamos que ficasse em cache;
  • page1.html  – que gostaríamos que ficasse em cache; 
  • page2.html  – que gostaríamos que recebesse uma versão alternativa quando offline;
  • fallback-page2.html – versão “offline” para page2;
  • page3.html – somente disponível on-line

Só esses (poderiam ser outros e de outros tipos)!

O arquivo fallback-page2.html é uma versão alternativa para page2 que deverá ser carregada quando a aplicação estiver rodando offline. Para explicar melhor como um manifesto funciona, eis o conteúdo de nosso manifesto:


              
1 CACHE MANIFEST 2 CACHE: 3 index.html 4 page1.html 5 6 FALLBACK: 7 page2.html fallback-page2.html 8 9 NETWORK: 10 * 11 12 # VERSION 1

              

Como está organizado o arquivo manifest

Um arquivo .manifest é muito simples. Basicamente, tem na primeira linha a string (obrigatória e fixa) CACHE MANIFEST. Além disso, pode possuir três sessões: CACHE, FALLBACK e NETWORK.

  • Na seção CACHE, relacionamos diretamente todos os arquivos que desejamos manter em cache para acesso offline;
  • A seção FALLBACK serve para que possamos aponter versões alternativas para nossos recursos quando estivermos offline. Para ficar claro, no nosso exemplo está indicado que, quando offline, se for requisitado pela aplicação o recurso page2.html, deverá ser utilizado o recurso (em cache) fallback-page2.html;
  • Por fim, a seção NETWORK indica explicitamente quais recursos não deverão ser mantidos, sob nenhuma forma, em cache. Repare que utilizei a máscara todos (*). Isso faz com que todos os arquivos que não pertençam a seção CACHE ou FALLBACK sejam considerados NETWORK.

Por fim, observe a linha que começa com um sharp (#). Essa linha é um comentário.

Atualização do cache para aplicativos com cache manifest

Aparentemente, sempre que um aplicativo possuir um cache manifest, terá seu cache atualizado apenas quando o arquivo de manifesto for atualizado. Por isso, recomendo a linha de comentário. Ou seja, mesmo que o conjunto de arquivos não se modifique, ao alterar um arquivo, deveremos, pelo menos atualizar o comentário para forçar atualização de caches.

Mime-type para o arquivo descritivo para o cache manifest

Para que todos os browser entendam o arquivo manifest adequadamente, será necessário marcar, explicitamente a extensão .manifest com o mime-type correto. O mime-type a ser utilizado é:


              
1 text/cache-manifest

              

E é só isso!

Imagine todo o potencial de combinar as novas APIs de persistência com o novo formato para caching.

Definindo HTML5

Como prometido, durante essa série, na medida em que vamos conhecendo mais detalhes do HTML5, vou tentar ir criando uma definição para a linguagem. A definição que tinhamos até esse artigo era:

HTML5 é a sucessora oficial para o HTML 4.01, que está sendo desenvolvida paralelamente pelo W3C e pelo WHATWG, que dá ênfase maior para a semântica do que para a sintaxe. Incorporou mais significado aos documentos mediante novas TAGs de indicação ao conteúdo. Além disso, simplificou drasticamente a criação de formulários e players de áudio/vídeo reduzindo muito a necessidade da escrita de código JavaScript ou plugins. Define também duas novas API de persistência bem superiores ao mecanismo de cookies, sendo que uma delas é um banco de dados com suporte para SQL.

Para uma definição, acho que ela estava ficando meio grandinha, então (promovendo uma revisão) e acrescentando o que vimos hoje:

HTML5 é a nova versão do HTML (anterior era 4.01) – uma linguagem para desenvolvimento de aplicações web online e offline – que está sendo desenvolvida pelo W3C e pelo WHATWG. Dá mais ênfase para o significado do conteúdo que para como que escrevemos documentos. Além disso, simplifica a criação de formulários e players de áudio/vídeo reduzindo a necessidade de código JavaScript ou plugins. Define duas novas API de persistência, superiores ao  cookies, sendo que uma delas é um banco de dados SQL.

O que vocês acharam?

Por enquanto, é o que temos. Vamos avançar mais nos estudos para poder complementar essa definição!

Por hoje, era isso …

Smiley piscando

Etiquetado:
Posted in: Sem categoria