O cache de aplicativos HTML5 deveria possibilitar a criação de aplicativos da Web compatíveis com off-line. Na prática, sua natureza implacável faz com que seja muito difícil usá-lo, o que lhe confere um reputação exclusivamente negativa entre os desenvolvedores de front-end.
Espera-se que os aplicativos continuem a funcionar off-line – a maioria dos usuários não se importa com os detalhes da implementação, desde que sua tarefa não seja interrompida. Essa experiência pode ser a mesma para aplicativos criados usando tecnologias da Web, em um navegador ou em uma visualização da Web usando o PhoneGap/Cordova.
Aplicativos off-line primeiro têm o benefício adicional de serem mais rápidos, fornecendo informações disponíveis de forma eficaz, mesmo quando não há uma conexão de rede disponível.
Não são apenas os aplicativos que se beneficiam do suporte off-line: os aplicativos baseados na Web estruturas de slides precisam ser executadas quando o Wifi do centro de conferências inevitavelmente cair. Da mesma forma, os viajantes com conexões irregulares apreciarão (ou, com sorte, não perceberão) quando os artigos ou a documentação que eles esperavam ter acesso continuarem funcionando.
O futuro do suporte off-line
Como os desenvolvedores front-end realmente fazem para criar aplicativos com suporte off-line? O futuro parece ser o ServiceWorker, mas, como Lyza Danger Gardner aponta, o ServiceWorker é apenas,
parcialmente implementada em cerca de 45% dos navegadores do mundo – os novos navegadores Chrome, Android e Opera. Isso parece substancial; no entanto, há nenhuma informação oficial de que o Safari o implementará.
Lyza Danger Gardner, Como vamos fazer isso agora?
Lyza aponta três maneiras possíveis de superar esse desafio técnico, todas menos que ideais:
- Usar somente o ServiceWorker, o que significa que o suporte off-line não funcionará na maioria dos navegadores, inclusive no iOS
- Use o cache de aplicativos HTML5 e reescreva o suporte off-line usando o ServiceWorker também
- Use somente o cache de aplicativo HTML5
Embora a primeira opção funcione para alguns aplicativos e públicos específicos, a maioria dos desenvolvedores precisará escolher uma das alternativas de maior alcance. Infelizmente, quando uma decisão como essa precisa ser tomada, outra opção parece ainda mais atraente:
- Não fazer nada e continuar a ignorar o suporte off-line.
Infelizmente, é uma conclusão razoável, dadas essas opções. Muitas vezes, as tecnologias da Web são escolhidas precisamente por sua capacidade de oferecer uma experiência multiplataforma com uma única base de código, mas são necessárias duas abordagens para oferecer uma abordagem de amplo alcance, mas também com visão de futuro, para o suporte off-line.
O retorno ao cache de aplicativos requer a geração de um .appcache e fazer referência a ele no arquivo html . Criar um link para ele é fácil; gerar o arquivo corretamente é complexo.
ApathyCache
Acreditamos que uma maneira de melhorar o suporte off-line na Web é fazer com que o algoincluindo suporte off-line básico – mais fácil por padrão. O suporte off-line deve ser acessível, mesmo que o cache de aplicativos HTML5 esteja longe de ser uma solução perfeita. Com isso em mente, adicionamos um auto.appcache a cada projeto publicado no Surto, publicação estática na Web para desenvolvedores front-end.
Hoje, para cada projeto no Surge, criamos automaticamente um .appcache apropriado, sempre que o senhor publicar seu site estático ou aplicativo Web do lado do cliente. Para usá-lo, basta optar por fazer referência a ele em seu html tag:
<html manifest="/auto.appcache">
Isso dá aos desenvolvedores front-end a opção de ignorar as partes desafiadoras do uso do manifesto do AppCache e, em vez disso, ganhar tempo para trabalhar nas partes satisfatórias: fazer com que seu aplicativo ou site estático seja executado off-line e trabalhar com tecnologias mais recentes, como o ServiceWorker.
Publicações em alta
Para instalar e publicar um site no Surge, primeiro instale-o por meio do npm:
npm install --global surge
Em seguida, execute o comando surge e insira o diretório dos arquivos estáticos que deseja publicar na Web:
surge /path/to/my-project
Este pode ser o compilado _site compilado de um projeto Jekyll, o diretório build de um projeto React, ou uma pasta com um index.html dentro dela. Ou, simplesmente, execute o comando surge por si só, dentro da pasta que o senhor deseja publicar.
De qualquer forma, o senhor terá a opção de usar um subdomínio gerado aleatoriamente ou especificar o seu próprio:
Depois disso, seu projeto será publicado e estará disponível na Web. (O senhor também pode adicionar um domínio personalizado, se o senhor quiser).
Visite seu auto.appcache arquivo
Este exemplo foi publicado no example-autoappcache.surge.sh. O auto.appcache estará sempre na raiz do projeto: example-autoappcache.surge.sh/auto.appcache.
O arquivo de manifesto do Automatic AppCache criado no Surge é apenas um arquivo de manifesto do AppCache formatado e mantido automaticamente. Ele começa de forma bastante simples, com uma declaração simples que é, de fato, um arquivo de manifesto:
CACHE MANIFEST
A partir daqui, no entanto, as coisas começam a se tornar mais complexas.
A seção de cache
Na primeira seção, cada arquivo estático do seu projeto é automaticamente listado com dois tipos de hashes. Esses hashes mudam quando o conteúdo do arquivo é alterado – quando o senhor publica versões atualizadas – mas, caso contrário, o cache do aplicativo continuará a servir a versão antiga.
CACHE: /about.html # b6bdb311c874fa38b7e6e57a24f875ee 1233 /css/main.css # c7823b8fcc98bdf437ca00d7fefe3b3a 103 /index.html # 1ef88ed5ba3b2645b6efad32530a4681 3009 /newsletter.html # 4122172c8cfea3014425f322c82bc17a 980
Normalmente, esse é um dos aspectos mais complicados do AppCache, e manter esse arquivo manualmente é totalmente impraticável. Existem algumas ferramentas, como este plug-in Gulpque facilita muito a manutenção desse arquivo localmente, mas isso depende do conjunto de ferramentas que o senhor usa para criar o site estático e o aplicativo do site do cliente.
Quando o senhor publica seu site no Surge, já fazemos essas verificações para saber se o senhor atualizou um arquivo e se devemos propagá-lo pela CDN do Surge ou se ele permaneceu inalterado desde sua última implantação. Podemos reutilizar essas informações como parte do arquivo de manifesto para determinar definitivamente se uma versão mais recente desse recurso está disponível ou não.
A seção de rede
Após a CACHE está a seção de rede. Isso combate uma parte contra-intuitiva do funcionamento do AppCache: por padrão, somente o conteúdo da seção de cache está disponível, on-line e off-line. Os recursos externos são reativados com essa seção do arquivo de manifesto do Auto AppCache:
NETWORK: *
A seção de fallback
Uma parte do Surge da qual estamos particularmente orgulhosos são os URLs limpos incorporadose descobrimos uma maneira de manter esse comportamento por meio do FALLBACK do arquivo de manifesto do AppCache. Isso também é gerado automaticamente para o senhor no arquivo de manifesto do Surge. auto.appcache do Surge, fornecendo ao senhor URLs limpos por padrão:
FALLBACK: /about /about.html / /index.html /newsletter /newsletter.html
Optando pelo suporte off-line
Embora esse arquivo seja gerado para cada projeto publicado no Surge, os desenvolvedores ainda podem decidir se desejam ou não optar por usá-lo.
Para armazenar automaticamente em cache seu aplicativo ou site estático usando o auto.appcache faça referência a ele no arquivo manifest no atributo <html> tag:
<html manifest="/auto.appcache">
Ao omitir o URL completo, o arquivo será 404 quando o senhor estiver desenvolvendo o projeto localmente, evitando qualquer cache potencialmente confuso.
Suporte ao ServiceWorker em camadas
O arquivo AppCache gerado automaticamente não funcionará para todos os projetos; como o Jake Archibald aponta, o senhor não pode colocar todo um site do tamanho da Wikipédia em um .appcache por exemplo. O que o auto.appcache arquivo faz é tornar significativamente mais fácil para as pessoas com aplicativos da Web, blogs, sites de documentação ou aplicativos do lado do cliente que estão sendo envolvidos no Cordova optarem facilmente pelo suporte off-line básico.
Esperamos que isso dê aos desenvolvedores o tempo necessário para que eles se concentrem em tecnologias mais versáteis e voltadas para o futuro, como o ServiceWorker, com a certeza de que eles têm um recurso alternativo com um suporte muito mais amplo para navegadores.
Leitura adicional
- Um exemplo baseado nesse artigo é o seguinte disponível no GitHub
- Gregor Martynus’s AppCache Nanny adiciona mais atualizações automáticas no lado do cliente para os primeiros aplicativos off-line e fornece controle do localizador sobre como o cache é usado
- Henrik Joreteg e Arthur Stolyar estão experimentando de forma independente a geração de arquivos de manifesto do AppCache como fallbacks para o ServiceWorker
- Jake Archibald’s Livro de receitas off-line é um ótimo recurso sobre o ServiceWorker
- UpUp é um wrapper relativamente novo, mas com aparência promissora, em torno do ServiceWorker
- O ServiceWorker exige um certificado SSL válido, que todos os projetos publicados no surge.sh recebem subdomínios gratuitamente. O Surge também oferece suporte a SSL para domínios personalizados.
