Skip to content

Instantly share code, notes, and snippets.

@diegoeis
Last active August 29, 2015 14:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save diegoeis/4d45c9446a76ddbfb334 to your computer and use it in GitHub Desktop.
Save diegoeis/4d45c9446a76ddbfb334 to your computer and use it in GitHub Desktop.
Renato Mangini - Service Workers

Palestra Renato Mangini

Service Workers

BrazilJS 21/08/2014

  • Existem alguns problemas entre apps nativos e web apps.
  • Várias desses problemas são contornáveis, mas o maior deles, sem dúvida, é trabalhar com algo offline.
  • Um dos problemas do AppCache o controle do que você cacheia.
  • O Renato, junto com uma galera do Google, fizeram uma aplicação modelo, para mostrar o que funciona bem em um App nativo e o que talvez não funcionaria tão bem em uma web app.
  • Aplicação web = shell + dados / AppCache
  • O AppCache não é adequado para dados dinâmicos e para sistemas grandes.
  • A alternativa é usar XHR (XmlHttpRequest) + LocalStorage.
  • Funciona, mas não é o ideal. Você está fazendo uma alternativa não convencional para solucionar este problema.
  • O ServiceWorkers tenta resolver o problema do Offline de uma forma natural para Web.
  • Imagina uma abstração além das páginas web. O ServiceWorkers é parecido com o WebWorker (que ninguém usa)... O ServiceWorker tem a função que prove serviços para sua página, porque a web limita por questões de segurança etc.
  • É um código JavaScript, onde você registra um ServiceWorker e o browser executa em momentos adequados.
  • O ServiceWorker também prove um cache, que é bastante previsível e nunca expira. Quando a App é executada, os dados que você já definiu, estarão lá.
  • Quando o usuário faz uma requisição, o browser vai na rede, pega a página, e instancia o contexto daquela página. Logo essa página solicita recursos, como imagens, js, css, e depois o browser mostra essa página para o usuário.
  • A primeira vez que o usuário acessa página, se aquela página estiver usando um ServiceWorker, ao instanciar a página, o browser vai solicitar a instalação do ServiceWorker, pelo comando Register. Enquanto o serviceWorker é instalado no primeiro request, o browser ainda continua na rede pegando o que ele precisa para mostrar a página.
  • No primeiro acesso, mesmo que tenha um registro de serviceworker, a página não executa o SW, te obrigando a pensar como sua app funcionará sem serviceworker. É uma camada de segurança. Vai que o usuário acessa com um browser ou dispositivo que não reconhece SW...
  • você só pode instalar o serviceworker no domínio de execução. Segurança em primeiro lugar, baby.
  • As três regras do ServiceWorkers
    1. Documents live out their whole lives using the ServiceWorker they start with.
    2. A ServiceWorker may be killed at any time.
    3. ...
  • index.html navigator.serviceWorker.register("worker.js")
  • oninstall e o onfetch
  • Os ServiceWorkers faz background sync, permitindo com que sua app seja ativada de tempos em tempos para sincronizar a sua webapp.
  • Push messages também se torna possível, onde seu servidor avisa uma plataforma que controla os devices cadastrados e manda a mensagem para os usuários.
  • Geofencing. Controle de localização de curta distância.
  • Controle de Bluetooth.
  • http://github.com/slightlyoff/ServiceWorker/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment