Categorias
PWA - Progressive web apps WordPress

Transformando seu site WordPress em uma PWA

Nesse post iremos ver como utilizar o plugin oficial do Google para converter seu site WordPress em uma Progressive Web App, atualmente temos uma série de plugins para converter seu site em uma PWA, os 3 principais plugins são:

Plugin PWA Google

Nesse post vamos focar no plugin mantido pelo time do Google e XWP. Esse plugin foi criado com a intenção de fazer parte do core do WordPress aos poucos, no ano passado o plugin foi utilizado no tema do WordCamp Europe Berlin. Pelo fato que o plugin tem como objetivo fazer parte do core uma vez instalado o plugin não ativa nenhum painel mas quando realizamos auditoria com Lighthouse temos o seguinte resultado:

Lighthouse usa um checklist para fazer a validação se nosso site como uma PWA

Lighthouse olha para três categorias:

  • Rápido e estável: Rápido carregamento e suporte a offline.
  • Instalável: Uso de HTTPS e uso de web app manifest
  • Otimizado: Configurações para barra de navegação customizada, design responsivo, conteúdo disponível sem a execução de JavaScript, inclusão de configuração para apple-touch-icon

O plugin gera web app manifest através da REST API uma vez que o plugin é ativado você pode conferir o endereço /wp-json/wp/v2/web-app-manifest.

Meu blog por exemplo:

{ "name": "Blog Fellyph Cintra", "start_url": "https:\/\/blog.fellyph.com.br\/", "display": "minimal-ui", "dir": "ltr", "lang": "pt-BR", "background_color": "#fafafa", "theme_color": "#fafafa", "description": "Blog sobre WordPress, JavaScript, HTML, CSS, eventos e algo mais", "icons": [ { "src": "https:\/\/blog.fellyph.com.br\/wp-content\/uploads\/2018\/11\/cropped-1796698_795991100415208_12473649_n-192x192.jpg", "sizes": "192x192", "type": "image\/jpeg" }, { "src": "https:\/\/blog.fellyph.com.br\/wp-content\/uploads\/2018\/11\/cropped-1796698_795991100415208_12473649_n.jpg", "sizes": "512x512", "type": "image\/jpeg" } ] }

As propriedades são geradas da seguinte forma:

  • name: O título do site carregada pela função get_option(‘blogname’)
  • short_name: copia do site title com no máximo 12 caracteres
  • description: descrição do site get_option(‘blogdescription’)
  • lang: idioma do site get_bloginfo(‘language’)
  • start_url: home URL via get_home_url()
  • theme_color: background customizado via get_background_color()
  • background_color: também carregado pelo background customizado
  • display: por padrão é minimal-ui
  • icons: o ícone do site via get_site_icon_url()

Para a configuração completa sem modificação no código o título do site precisa ter menos de 12 caracteres, caso contrário precisamos customizar o nosso código, em outras palavras precisamos tocar no código. Weston criador do plugin PWA também criou um mini plugin para incluir essas informações sem código:

https://gist.github.com/westonruter/dec7d190060732e29a09751ab99cc549

A Primeira vez que rodei a auditoria tive dois problemas, o primeiro era o título do menu site era maior que 12 caracteres e o segundo o ícone do meu site era inferior a 512px.

Primeira auditoria com lighthouse

Para resolver o problema do short_name inclui o plugin do Weston, ele inclui um campo extra no meu painel de configuração

Atributo short name

Após corrigir o problema com o short name o segundo problema foi referente aos ícones para isso precisamos adicionar uma PNG com mais de 512px como ícone de nossa aplicação no menu Personalizar > Identidade do site:

Atualizando ícone do site

Com o manifest.json corrigido temos a possibilidade de instalar o nosso site WordPress como na imagem a seguir:

Banner de instalação

Personalizando manifest.json

Lembrando que a ideia que esse plugin faça parte do core, muita coisa ainda pode mudar na versão de Julho de 2020 caso queiramos personalizar informações do manifest.json precisamos adicionar filtros(codificar) em nossa aplicação via tema com function.php ou criando um plugin:

add_filter( 'web_app_manifest', function( $manifest ) { $manifest['short_name'] = 'Shortness'; return $manifest; } );

Caso o seu tema não suporte ícones ou background personalizado precisamos incluir a informação, por exemplo, o theme_color:

add_filter( 'web_app_manifest', function( $manifest ) { $manifest['theme_color'] = '#0073AA'; return $manifest; } );

Versão Offline

Um dos recursos do plugin é a inclusão de template para usuários offline Erro 500, caso queira enviar uma mensagem personalizada para o usuário você pode incluir uma template com seguinte nome offline.php, 500.php ou error.php para uma mensagem mais genérica.

Versão offline padrão

Caso queira testar seu template você pode acessar o seguinte endereços:

  • https://your-site-name.com/?wp_error_template=offline;
  • https://your-site-name.com/?wp_error_template=500

Comentários Offline

Outro recurso do plugin é a possibilidade de comentários offline, o plugin utiliza Background Sync API para enviar os comentários quando o usuário recuperar a conexão.

Estratégias de Cache

O plugin utiliza WorkBox integrado com PHP para realizar abstração da implementação das estratégias de cache, para isso precisamos indicar extensões e rotas e quais estratégias serão implementadas:

  • Cache first
  • Stale while revalidate
  • Cache only
  • Network only

Para implementar estratégias de cache precisamos utilizar hooks e adiciona-los em nosso function.php

add_action( 'wp_front_service_worker', function( \WP_Service_Worker_Scripts $scripts ) { $scripts->caching_routes()->register( '/wp-content/.*\.(?:png|gif|jpg|jpeg|svg|webp)(\?.*)?$', array( 'strategy' => WP_Service_Worker_Caching_Routes::STRATEGY_CACHE_FIRST, 'cacheName' => 'images', 'plugins' => array( 'expiration' => array( 'maxEntries' => 60, 'maxAgeSeconds' => 60 * 60 * 24, ), ), ) ); } );

No código acima adicionamos uma estratégia cache first a todas as imagens dentro da pasta \wp-content\.

add_action( 'wp_front_service_worker', function( \WP_Service_Worker_Scripts $scripts ) { $scripts->precaching_routes()->register( 'https://example.com/wp-content/themes/my-theme/my-theme-image.png', array( 'revision' => get_bloginfo( 'version' ), ) ); } );

No segundo exemplo acima realizamos precaching de uma image específica em nosso tema e vinculamos uma versão para manter em cache até o plugin atualizar a versão, mais informações na página do github plugin.

Conclusão

Caso faça parte do core do WordPress isso será uma grande adição para o core do WordPress, o uso de bibliotecas externas como Workbox pode adicionar mais complexidade na incorporação desse plugin, mas o plugin é uma alternativa rápida para implementação de recursos de uma Progressive web app em nossos sites WordPres.

Vantagens

  • Fácil integração com outros plugins do Google como AMP para WordPress e Site Kit.
  • Inclusão de template para versão offline.
  • Possiblidade de comentários offline
  • API para implementação de estratégias de cache
  • Geração automática de Web App Manifest

Desvantagens

  • Necessidade de codificação para alguns recursos
  • Ausência de um painel de personalização para determinadas informações
  • Nenhuma integração para service worker

Após as configurações adicionadas corretamente temos nosso site WordPress atingindo as três metas: Rápido, estável, instalável e otimizado.

Auditoria final

Para mais posts sobre PWA acesse a página da categoria.

Categorias
PWA - Progressive web apps Tutoriais

Geolocation API

Vamos falar sobre geolocation esse post servirá como base para o conteúdo do curso de PWA que estou rodando no meu canal. Na versão 2020 do curso iremos abordar Web APIs disponíveis para iOS e nesse primeiro posts iremos abordar a Geolocation web API.

Umas das primeiras web APIs lançadas junto com o HTML5, para termos noção esse recurso estava disponível na versão 5 do Chrome e Safari em 2010. A Geolocation API possui uma série de funções e eventos que permitem a localização do usuário através doso dados: latitude e longitude.

Relatório do “can I use”

Suporte

Esse recurso é totalmente dependente do device do usuário vimos que o recurso é presente 94% dos browsers que suporte alto. Mas a sua precisão depende que o device que possua GPS, caso contrário essa informação será gerada através de cruzamento de dados, por exemplo, rede e endereço IP. Isso significa se o device não possuir suporte essa informações não serão tão precisas.

GPS

Outro ponto importante é o consumo de bateria, para o os dispositivos móveis o acesso ao GPS causa um custo maior de processamento assim aumenta o consumo de bateria, então é importante fazer o uso consciente desse recurso.

Privacidade

Na maioria dos devices esse recurso é dependente de uma conexão HTTPS, também antes do acesso a esse recurso o browser irá requisitar permissão de acesso a Geolocalização do usuário. Como podemos ver na imagem a seguir:

Exemplo pop up de permissão da apple

Ideal caso armazene ou monitore a movimentação do usuário deixe claro o uso desse recurso. Esse recurso também só será acessado em uma aplicação que estiver rodando em um servidor web.

Código

Depois de uma introdução sobre a API agora vamos ver como utiliza-la em nossa aplicação:

navigator.geolocation.getCurrentPosition(geoSuccess, geoError); const geoSuccess = (position) => { console.log(position.coords.latitude, position.coords.longitude); }; const geoError = (error) => { console.log('Error occurred. Error code: ' + error.code); };

No código acima fazem a chamada da api dentro de navigator, podemos conferir se o browser tem suporte a geolocation verificando se o atribulo é nulo mas em 2020 a api está presente na maioria dos browsers então não vou me preocupar como esse ponto.

Chamamos a função get position responsável por requisitar a latitude e longitude do usuário. Ela recebe como parâmetro duas funções uma parar executar caso sucesso ou falha de acesso ao recurso.

Se a requisição for bem sucedida teremos a chamada da função geoSuccess com o retorno da latitude(position.coords.latitude) e longitude(position.coords.longitude). Em caso de erro teremos a chamada da função geoError com os possíveis códigos:

  • 0: erro desconhecido
  • 1: permissão negada
  • 2: erro na resposta da fonte da informação
  • 3: timed out

Essa é uma introdução ao assunto em breve estarei postando um vídeo sobre o assunto em meu canal. Qualquer dúvida deixe um comentário ou continue lendo mais tutoriais na página da categoria.

Referência: MDN Geolocation API

Veja também as aulas sobre o assunto no curso de PWA

Categorias
Web

PWAs em 2020

Todos os anos temos uma compilação dos últimas features referentes a PWA no Google I/O o congresso anual do Google para desenvolvedores. No último ano 2019 confesso que não fiquei muito empolgado com os lançamentos relacionados a PWA no Google I/O, mas analisando por um outro lado é o resultado de uma maturidade do conceito PWA.

Progressive web apps em si, já tem sua base, com Service Workers e Web manifest não temos muito o que mudar. Saber dos valores de criar apps rápidos, seguros e que cativem o usuário, por fim, temos a evolução das Web APIs esse é um ponto que ainda terá uma evolução, as Web APIs nos permitem implementar recursos antes só possíveis com aplicações nativas esse ponto irei falar mais pra frente.

Por conta da situação que estamos passando as principais conferências no mundo foram canceladas e o Google I/O também está incluso nessa lista então não teremos um evento principal com anúncio de novas features relacionadas a PWAs, mas esse ano acredito que teremos lançamentos menores com seguindo as versões do Chrome e numa previsão otimista teremos um Chrome Summit online.

Releases do Chrome

Com toda a situação com o covid-19 o calendário de lançamentos do Chrome foi alterado, tivemos na última semana a versão 81 sendo lançada com suporte em versão de teste a NFC e suporte total a badging api, mas Google anunciou que irá pular a versão 82 atrasando o anuncio de alguns novos recursos em 6 semanas, mas o Google irá trabalhar apenas em bugs e correções de segurança durante esse período e somente lançar a versão 83. Se a situação se normalizar eles voltarão ao ciclo de 6 semanas.

Projeto Fugu

Apresentação do Projeto Fugu no I/O 2019

Projeto Fugu, é um projeto que visa habilitar na plataforma web recursos que eram somente possíveis com apps nativos uma série de empresas estão envolvidas nesse processo. Mas Claro que os releases do Chrome influenciam na implementação de recursos PWA eles são responsáveis pelos browsers Android e recentemente é o motor por trás do Microsoft Edge.

Com a adoção do Edge ao Chromium aumentou a quantidade de desenvolvedores, assim dando um fôlego maior ao Projeto Fugu na implementação de novas web APIs. Não só apenas Google e Microsoft contribuem com o Projeto Fugu, mas temos empresas como Intel e Samsung como contribuidores.

Google compartilhar uma lista pública de quando as funcionalidades serão implementadas no Chrome, que você confere aqui: https://docs.google.com/spreadsheets/d/1de0ZYDOcafNXXwMcg4EZhT0346QM-QFvZfoD8ZffHeA/edit#gid=557099940

O legal dessa lista é atualizada a cada release do chrome, outro ponto importante você também pode contribuir com sugestões de features: https://developers.google.com/web/updates/capabilities

Recursos para PWAs já lançados em 2020(Abril)

  • Web Share API target
  • Contact Picker API
  • Periodic Background Sync
  • Web OTP API – Screen Lock
  • Clipboard para imagens
  • Launch keyboard Map API

Recursos da Web API previstas para 2020

  • Web NFC
  • Content Index API
  • Screen enumeration API
  • File Handling API
  • getInstalledRelatedApps
  • Native File system API
  • WakeLock API – Screen Lock
  • Shape detection API

iOS

Quase contra-mão o Webkit trabalha de forma isolada, tratando de recursos que a Apple acha prioridade para o safari, por exemplo, na última versão do safari 13.1 tivemos a inclusão de recursos como:

  • Async Clipboard API
  • Picture-in-Picture API
  • Remote Playback API

Muitas empresas já viram o benefício de se investir em PWAs, mas a Apple evita de mencionar o termo PWA por conta de ser um termo vindo do Google para definir o conceito. Segundo acredito no ponto de vista relacionado ao business atual da empresa que a Apple Store, como ela irá encaixar PWAs com apps nativos.

Particularmente acredito que a Apple continuará implementando novos recursos da Web API quando é de seu interesse e a tentará uma implementação da formula diferente da apresentada pelo Google. Mas 2020 ainda não será o ano que teremos full suporte pela Apple. Para saber mais sobre PWA confira a página do curso de Progressive web Apps.

Categorias
AMP Accelerated mobile pages

Convertendo uma aplicação AMP em uma PWA

Agora chegou o momento de conectar os meus dois assuntos favoritos, Progressive Web Apps(PWA) e AMP. Se você ainda não sabe o que é uma PWA podemos definir conjunto de tecnologias que nos permitem criar aplicações web com recursos que antes só possíveis em aplicações nativas se quiser saber mais sobre PWA tenho um curso dedicado em meu canal.

As PWA possui uma série de diferentes API que podem ser aplicadas a diferentes soluções, mas para o caso de nossa aplicação AMP vamos abordar dois items:

  1. Tonar nossa aplicação instalável
  2. Adicionar suporte a versão offline.

Criando um web app manifest para nossa PWA

Primeiro passo vamos criar um web app manifest arquivo json que permite que dispositivos que reconheçam que nossa aplicação pode se instalável. Para isso vamos adicionar em nosso projeto um arquivo chamado manifest.json e nele vamos adicionar o seguinte código:

{ "short_name": "Caipirinha", "name": "How to prepare the best caipirinha", "icons": [ { "src": "./images/capi_icon_192.png", "type": "image/png", "sizes": "192x192" }, { "src": "./images/capi_icon_512.png", "type": "image/png", "sizes": "512x512" } ], "start_url": "/index.html", "background_color": "#00d1c3", "display": "standalone", "scope": "/", "theme_color": "#00d1c3" }

O código acima descreve as informações que iremos exibir para o usuário quando ele instalar nossa aplicação, que são elas:

  • short_name: o nome que sera exibido na tela inicial do nosso usuário.
  • icons: com uma lista de ícones que iremos exibir em diferentes plataformas.
  • start_url: o endereço nossa aplicação irá carregar quando acessada através do ícone na tela inicial do usuário.
  • background_color: a cor do background da splash screen do nosso app.
  • display: o modo em que nossa PWA será exibida
  • theme_color: as cor do tema da nossa aplicação, por exemplo, barra de controle.

Depois que criarmos nosso arquivo manifest.json temos adicionar uma referência dentro da tag head de nosso index.html ao arquivo de configuração, como podemos ver no código abaixo:

<link rel="manifest" href="/manifest.json">

Adicionando suporte a versão off-line

Agora que já definimos como nosso app será instalado é hora de adicionar a versão off-line de nossa aplicação para isso vamos trabalhar com service workers.

Service Worker um script que é executando por nosso browser em background, separado de nosso DOM onde funciona como proxy acompanhando as requisições no nosso app.

Caso queira saber mais sobre o assunto confira o post sobre service worker.

Mas com esse recurso conseguimos controlar quando nosso app faz requisições a rede e definir estratégias de cache e suporte a versão offline utilizando em conjunto com a cache API.

Atualmente existem bibliotecas que facilitam a implementação desses recursos, por exemplo, Workbox onde também tenho um post mais detalhado sobre o assunto aqui.

Mas AMP vai um passo além do Workbox e abstrai uma série de passos na configuração de um service worker para implantação de estratégias de cache e versão off-line. Isso tudo utilizando AMP Service Worker ele armazena automaticamente os scripts e os documentos de nossa aplicação.

Como criar um service worker com AMP?

Passo 1 – criar o arquivo que irá importar o AMP Service Worker e incializa-lo, para isso vamos criar um arquivo JavaScript chamado sw.js e adicionar os seguinte código:

importScripts('https://cdn.ampproject.org/sw/amp-sw.js'); AMP_SW.init();

Passo 2 – Incluímos o script que irá instalar o AMP Service Worker próximos as scripts que você já carrega em sua aplicação AMP.

<script async custom-element="amp-install-serviceworker" src="https://cdn.ampproject.org/v0/amp-install-serviceworker-0.1.js"></script>

Passo 3 – Adicionamos dentro do corpo da nossa página HTML o componente amp-install-servieworker:

<amp-install-serviceworker src="/sw.js" data-iframe-src="install-sw.html" layout="nodisplay"> </amp-install-serviceworker>

O componente amp-install-serviceworker irá registrar um service worker definido na propriedade src, dois pontos importante sobre o service worker:

  • Precisa estar na pasta raiz da aplicação
  • Precisa ser servido via HTTPS.

A segunda propriedade é o data-iframe-src é um atributo opicional que será responsável por verificar se o browser possui suporte a service worker e instalar-lo em caso possua.

Passo 4 – o último passo vamos criar o arquivo definida pela propriedade data-iframe-src:

<!doctype html> <title>installing service worker</title> <script type='text/javascript'> if('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw.js'); }; </script>

Com esse 4 passos temos nossa primeira versao offline, o AMP Service Worker nos permite definir estratégias de cache para arquivos especificos. Caso queira saber mais sobre estrategias de cache eu escrevi um post aqui.

Vou criar mais um post de como modificar estratégias de cache e exibir uma página específica parar quando os usuários estiverem off-line.

Categorias
JavaScript PWA - Progressive web apps

Introdução a Workbox

Workbox é um conjunto de bibliotecas e módulos do node que simplifica o processo de cache de assets em nossa aplicação, assim agilizando o nosso trabalho na criação de uma Progressive Web Apps. Este tutorial será baseado na versão 4 da biblioteca. Workbox trabalha dois conceitos importantes sobre PWAs:

Performance: não espere por todos os arquivos de sua aplicação virem da internet, crie estratégias de cache para servir arquivos do armazenados em seu device.

Resiliência: Conexões móveis ou em regiões com fraca infra estrutura podem afetar a experiência do usuário, habilite sua aplicação administrar situações que a conectividade é limitada

Porquê Workbox?

Workbox é uma biblioteca reune as melhores práticas e toda a complexidade de trabalhar com service workers com por exemplo:

  • Precaching
  • Runtime caching
  • Estratégias de cache
  • Requisição de rotas
  • Background Sync
  • Ajuda no debug da aplicação

Opções de utilização

Para trabalhar com Workbox temos as seguintes alternativas:

  • Workbox CLI
  • node.js
  • webpack plugin

Lembrando que essas alternativas são independentes você deve escolher somente uma, então escolha a alternativa que melhor se adequa ao seu caso.

Workbox CLI

CLI nada mais é que uma acrônimo para Command line Interface(Interface de linha de comando) tem como objetivo trazer um grupo de comandos no terminal para possibilitar realizar uma terminada ação, seja criar novos projetos ou administrar recursos existentes. Mas tendo como foco principal reduzir o trabalho e a complexidade ao item aplicado.

Primeiro passo quando trabalhamos com um CLI é fazer sua instalação workbox-cli depende do node.js para funcionar, antes de rodar qualquer comando para o CLI precisamos instalar a versão mais recente do node.js, após a instalação do node rodamos os seguinte comando em nosso terminal:

npm install workbox-cli --global

Se tudo ocorrer bem seremos capazes de testar com o seguinte comando:

workbox --help

Se o terminal reconheceu o comando workbox sinaliza que a instalação foi bem sucedida, agora é hora de utilizar o comando:

workbox wizard

Ele irá nos dar um passo-a-passo para a configuração de nosso projeto com as seguintes perguntas:

  1. Qual é a pasta do nosso app onde se encontra a pasta em que iremos exportar nossa aplicação?
  2. Quais os tipos de arquivos em que gostaríamos de realizar o preache?
    1. svg, jpg, png, html, css, js, json
  3. Onde preferimos salvar o nosso service worker?
  4. Onde gostariamos de salvar nosso arquivo de configuração

Como podemos ver na imagem abaixo, no meu caso estou rodando a versão 4.3.1 do Workbox, versões anteriores ou futuras esse passos podem mudar um pouco mas o core sempre será quais arquivos queremos fazer o cache e qual será o nosso service worker.

Por fim ele exibe o comando necessário para gerar nosso service worker:

workbox generateSW workbox-config.js

Quando rodamos esse comando ele irá ler o arquivo de configuração gerado pelo wizard:

module.exports = { "globDirectory": "dist/", "globPatterns": [ "**/*.{svg,jpg,png,html,css,js,json}" ], "swDest": "dist/sw.js" };

Varrer e criar um cache para todos os arquivos com as extensões especificadas anteriormente. Você terá um retorno parecido com a mensagem a seguir.

The service worker was written to dist/sw.js 22 files will be precached, totalling 84.2 kB.

Esse comando será necessário toda a vezes em que alteramos os arquivos dentro de nossa aplicação, para agilizar esse processo podemos fazer uma integração com gulp ou webpack.

Gulp + workbox

Como mencionamos anteriormente podemos agilizar o processo de criação de service worker utilizando ferramentas de automatização de tarefas, basicamente vamos assistir as mudanças realizadas em nosso projeto quando algum arquivo for alterado o Gulp será responsável por gerar o nosso service worker

Instalação:

npm install workbox-build --save-dev

Exemplo

const workboxBuild = require('workbox-build'); // NOTE: Esse comando deve ser executado depois que os assets forem gerados const buildSW = () => { // assim retornamos generateSW que retorna uma Promisse return workboxBuild.generateSW({ globDirectory: 'build', globPatterns: [ '**\/*.{html,json,js,css}', ], swDest: 'build/sw.js', }); }

webpack + workbox

Para webpack também temos um plugin especifico para trabalhar com workbox ele tem suporte precaching e runtime caching. Caso ainda não conheça webpack tenho um post de introdução aqui.

Para instalação do plugin na pasta de nosso projeto onde ficar o nosso arquico package.json executamos o seguinte comando em nosso terminal:

npm install workbox-webpack-plugin --save-dev

Depois de instalado precisamos configurar o nosso webpack, dentro do arquivo de configuração do webpack adicionamos o Plugin para workbox:

// dentro do webpack.config.js: const WorkboxPlugin = require('workbox-webpack-plugin'); module.exports = {   // Outras configurações...   plugins: [     // Outros plugins...     new WorkboxPlugin.GenerateSW()   ] };

Após tudo configurado precisamos registrar nosso service worker:

<script> // verificamos se o browser suporta service worker if ('serviceWorker' in navigator) { // usamos o evento load para registrar nosso service worker window.addEventListener('load', () => { navigator.serviceWorker.register('/service-worker.js'); }); } </script>

Caso queira saber mais sobre service worker tenho um post de introdução a service worker também estou rodando um curso gratuito sobre PWA em meu canal no youtube. Qualquer dúvida só deixar um comentário e até o próximo post.