O que é um Progressive Web App (PWA)?

Progressive Web Apps (PWAs) são sites que usam uma coleção de tecnologias modernas da web para fornecer experiências de usuário semelhantes a aplicativos. Os recursos típicos do PWA incluem suporte offline, sincronização em segundo plano e a capacidade de “ instalar ” o site como um aplicativo móvel.

PWA é um termo geral usado para fazer referência a várias tecnologias. Um PWA geralmente inclui um Manifesto de Aplicativo da Web e um Service Worker. O Web App Manifest fornece dados usados ​​para registrar o site na lista de aplicativos de um sistema operacional. O Service Worker pode ser usado para adicionar recursos que permanecem ativos depois que as guias do navegador do site são fechadas.

Nem todo site usará todos os recursos possíveis. Alguns incluirão um Manifesto de Aplicativo da Web, mas nenhum Service Worker; outros terão um Service Worker, mas nenhum suporte para instalação de aplicativos. Não há um padrão específico que defina como um PWA deve se comportar. Um PWA é qualquer site que usa algumas dessas tecnologias para oferecer algum nível de paridade de recursos com aplicativos nativos.

Compreendendo o “ Progressivo ” Aprimoramento

O método “ progressivo ” parte dos Progressive Web Apps deriva do uso esperado de aprimoramento progressivo. Os recursos do PWA ainda são bastante novos e podem não ser suportados em todos os navegadores. Um PWA deve continuar a fornecer sua experiência principal baseada na web, mesmo se APIs de navegador, como service workers, não estiverem disponíveis.

Recursos como notificações push não devem ser uma parte obrigatória da sua experiência. Se o seu site não se registrar para notificações push, o resto do site deve continuar a funcionar normalmente. Quando o navegador oferece suporte a tecnologias modernas, seu site deve tratá-las como um aprimoramento que oferece conveniência extra ao usuário.

Disponibilidade de recursos

Os recursos do PWA fornecem uma integração mais profunda entre o seu site e o dispositivo do usuário. Consequentemente, as APIs usadas para criá-los são restritas a conexões HTTPS. Isso ajuda a garantir que o conteúdo não seja adulterado para a instalação persistente de aplicativos nefastos no seu dispositivo.

Recursos individuais são protegidos por permissões da web voltadas para o usuário. Recursos como notificações push podem ser usados ​​para bombardear o usuário com conteúdo indesejado. Os usuários precisam reconhecer um prompt de permissão que concede ao seu site a capacidade de usar recursos potencialmente intrusivos.

Essas condições significam que você precisa usar a detecção de recursos antes de tentar usar a maioria das APIs relevantes. Um recurso pode não estar disponível porque o navegador não oferece suporte para ele. No entanto, ele também pode ser desativado devido a uma conexão insegura ou porque o usuário negou um prompt de permissão. Você não pode antecipar o último cenário; o usuário pode mudar de ideia a qualquer momento.

Traços de PWA

Embora não haja um padrão para PWAs, a maioria dos sites que oferecem uma experiência semelhante à de um aplicativo tem as seguintes características:

• Instalável – Em plataformas suportadas, o site pode ser “ instalado ” como um aplicativo móvel. Os efeitos variam de acordo com o sistema operacional e o navegador.
• Funciona off-line – Os Service Workers são scripts que continuam em execução mesmo quando o seu site não está aberto. Eles também podem interceptar solicitações de rede, permitindo que você atenda a ativos essenciais de um cache. Isso permite que seu site continue funcionando quando o usuário estiver off-line.
• IU semelhante a um aplicativo – Embora não seja um requisito, é provável que os PWAs dêem mais ênfase ao uso de controles de IU modernos que se integram bem com estilos de aplicativos nativos. Os PWAs precisarão responder a diferentes tamanhos de tela.

Além dessas características básicas, os PWAs individuais criarão camadas de recursos adicionais para criar a experiência do usuário de que precisam. Esses recursos podem incluir notificações push, uploads em segundo plano e buscas periódicas de dados em segundo plano. Esses recursos opcionais permitem que você reconecte o usuário e antecipe suas necessidades.

Manifesto do aplicativo da web

Manifestos de aplicativos da web são arquivos JSON que definem informações importantes sobre o seu site. Isso inclui detalhes como nome do site, cor de destaque e localização dos arquivos de ícones.

Navegadores e sistemas operacionais usam as informações para criar entradas de aplicativo no nível do sistema quando você “ instala ” seu site. É assim que seu site obtém um ícone de gaveta de aplicativo no Android ou um link do menu Iniciar no Windows.

Aqui está um exemplo de manifesto:

{" nome & quot ;: " Exemplo de aplicativo & quot ;, " exibição & quot ;: " autônomo & quot ;, " cor de fundo & quot ;: " # fff & quot ;, " descrição & quot ;: " Meu aplicativo & quot ;, " start_url " ;: " / & quot ;, " ícones & quot ;: [{" src & quot ;: " /icon. png" ;, " tamanhos & quot ;: " 512x512 & quot ;, " tipo & quot ;: " imagem / png " }]}

A propriedade display declara que o site deve ser iniciado em sua própria janela autônoma ao ser aberto em uma gaveta do aplicativo. A propriedade start_url define o URL inicial para navegar após o lançamento.

Seu site deve anunciar seu Web App Manifest usando uma tag de link em seu HTML:

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

Os navegadores tentarão recuperar o manifesto. Se for válido, o usuário pode ser sugerido para “ instalar ” a aplicação. No Chrome para Android, isso aparece como “ Adicionar à tela inicial ” bar. Não é garantido que a barra apareça – O Chrome usa heurísticas, como a frequência com que você visita o site, para determinar se uma dica de instalação deve ser mostrada.

Service Worker

Trabalhadores de serviço são criados usando JavaScript. Eles se diferenciam do JavaScript principal do seu site. Um service worker é registrado a partir de seu script principal. O navegador mantém o service worker em execução quando a guia é fechada. Isso permite que você execute operações em segundo plano que podem durar mais que a visita do usuário ao seu site.

Veja como você registra um prestador de serviço:

se & # 40; " serviceWorker " no navegador & # 41; & # 123; navigator. serviceWorker. register & # 40; " /service-worker. js" & # 41 ;; & # 125;

O script service-worker. js será baixado e ativado como um service worker. Um service worker não oferece nenhuma funcionalidade útil por conta própria. Você precisa usar APIs como caches, sincronização em segundo plano ou notificações push no seu service worker.

Aqui está um exemplo básico que armazena em cache todos os ativos associados ao nosso aplicativo:

self. addEventListener & # 40; " instalar & quot ;, e = > & # 123; e. waitUntil & # 40; async & # 40; & # 41; = > & # 123; const cache = await caches. open & # 40; " my-app-cache " & # 41 ;; await cache. addAll & # 40; & # 91; " /index. html", " /my-css. css", " /my-js. js", " /assets/icon. png", & quot ; /assets/my-header-image. png" & # 93; & # 41 ;; & # 125; & # 41 ;; & # 125; & # 41 ;;   self. addEventListener & # 40; " fetch & quot ;, e = > & # 123; e. respondWith & # 40; async & # 40; & # 41; = > & # 123;   const cached = await catches. match & # 40; e. request & # 41 ;; if & # 40; cached & # 41; return cached;   resposta const = aguarda busca & # 40; e. request & # 41 ;; resposta de retorno;   & # 125; & # 41; & # 125; & # 41 ;;

Isso usa o evento de ciclo de vida do trabalhador de serviço de instalação para baixar todos os ativos críticos. Eles serão adicionados a um cache dedicado que é controlado pelo service worker.

O service worker também ouve o evento fetch. Isso ocorre sempre que uma solicitação de rede é feita. O objeto de evento inclui uma propriedade de solicitação que é um objeto de solicitação aceito pela API fetch ().

O código primeiro verifica se a solicitação já existe no cache. Se for um URL que foi armazenado em cache anteriormente, a verificação será aprovada e a resposta armazenada em cache será retornada. Caso contrário, a solicitação é encaminhada para a API fetch (). O ativo será carregado pela rede normalmente.

Este exemplo exibe apenas uma dica do que os prestadores de serviço podem oferecer. Em um aplicativo real, você frequentemente desejará um armazenamento em cache mais avançado, recursos extras em segundo plano e eventos de ciclo de vida adicionais (para controlar como seu service worker substitui e é substituído por outras versões).

Resumo

Progressive Web Apps são aplicativos da web que usam um conjunto de APIs de navegador relacionadas para oferecer uma experiência semelhante à de um aplicativo. Você provavelmente já usou PWAs no passado, mesmo que não estivesse consciente disso.

A experiência do PWA baseia-se no aprimoramento progressivo e na escolha do usuário. Você precisa fornecer consentimento antes que cada site possa ativar seus recursos de PWA. Caso contrário, o site deve fornecer sua experiência principal baseada em navegador, sem os recursos extras fornecidos pelas tecnologias PWA.