Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Progressive Web Applications

Progressive Web Applications

@ BAFrontend (2016)

Dan Zajdband

July 19, 2016
Tweet

More Decks by Dan Zajdband

Other Decks in Technology

Transcript

  1. Quién soy • Knight-Mozilla fellow (o Nait Morcilla fellow según

    @alevizio) • Coral Project (Mozilla / New York Times / Washington Post) • Herramientas para medios y experimentos con WebVR
  2. Moebius (1966) “Un topólogo investiga la misteriosa desaparición de un

    tren subterráneo junto a sus 30 pasajeros.” - IMDB
  3. El/la Zombie del subte • Está usando un teléfono •

    Intenta navegar con Firefox • Tiene algo de señal pero cuando entra a un sitio solo ve la barra de carga y una página en blanco • Cree que las página son lentas porque se queda cargando. Si ve la página advirtiendo que está offline culpa a Movistar
  4. Pensemos en el usuario. Siempre. • Qué problema queremos resolverle?

    • Qué le falta? • Cómo podemos ayudarlo a que complete sus tareas? • Hasta qué punto está bloqueado por sus limitaciones?
  5. Progressive Web Applications Conjunto de tecnologías “abiertas” que intentan resolver

    problemas intrínsecos de la plataforma web para competir en el mundo móvil. Dan Zajdband - Poeta
  6. PWA y Progressive enhancement Para utilizar estas tecnologías los navegadores

    tienen que poder: • Interpretar un manifest.json • Instanciar un service worker • https -> (letsencrypt FTW!) Si el chequeo nos dice que no se puede simplemente no enriquecemos nuestros sitios
  7. manifest.json { "name": "Muddy", "short_name": "Muddy", "start_url": "/", "scope": "/",

    "display": "standalone", "background_color": "#D32F2F", "icons": [ { "src": "logo.png", "sizes": "256x256" } ] }
  8. Registrando un service worker: La entrada a Narnia // Progressive

    Enhancement: Si podemos usar esta tecnología la aprovechamos, sino seguimos con la nuestra if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') }
  9. Features asociadas a PWAs • Offline y caches • Home

    screen icon + splash screen • Push notifications • Background sync + Background jobs
  10. Gratarola Si registramos un manifest y un service worker somos

    candidatos a: • Install banner • “Standalone mode” • Splash screen
  11. Service worker Es un script que corre en background y

    que tiene acceso a ciertas APIs que nuestros scripts comunes no. De hecho pueden seguir corriendo cuando nos vamos del sitio. El flujo está muy basado en el uso de Promises. Si todavía no sabes que sos, es buen momento para aprenderlo.
  12. Algunos usos de service workers • Offline fallback de recursos

    • Cache de layouts y recursos estáticos • Fake APIs para testing • Push notifications • Background sync • Analytics super posta
  13. Ciclo de vida de un service worker • Instalación: Cache

    de recursos • Activación: Limpiar caches viejos • Fetch: Decidimos que hacer con cada request de un recurso
  14. La vida secreta del service worker self.addEventListener('install', function(event) { /*

    ... */ }); self.addEventListener('activate', function(event) { /* ... */ }); self.addEventListener('fetch', function(event) { /* ... */ });
  15. Network y caches • Nuestro service worker tiene acceso a

    la CACHE API que nos permite crear caches para almacenar recursos. • También se emite un evento en el service worker por cada request en nuestro sitio (navegación, js, css, xhr, etc...). • Podemos frenar un pedido a la red y devolver información cacheada, mockeada o ir incluso seguir a la red y cachear la respuesta para el futuro.
  16. App Shell model • Es un esquema donde el layout

    se cachea (header, footer, sidebar) y se “rellena” con la información que se modifica • Es muy simple hacer una aplicación que cargue instantáneamente (del cache) y se completa con datos que pueden venir de la red o de otro cache • Es muy importante contar con `blank states` (siempre lo es pero especialmente en este caso) • Este no es un estándar sino una recomendación de gugel
  17. Background sync • El service worker recibe un “ping” con

    un nombre cuando la app tiene una conexión estable • Intentamos sincronizar la información que produjo el usuario “offline” con el estado general de nuestros servidores y le hacemos saber al sw si la sync se hizo correctamente • Si no fue correcta la sincronización se intentará nuevamente más tarde • Otra vez, progressive enhancement. Tenemos que chequear si está disponible y actuar en consecuencia. Si no seguimos con la nuestra • Límites en el proceso de sync • Pensar nuestro flujo de datos en términos de sync puede ser más díficil al comienzo pero es útil también para otros esquemas como real-time y múltiples clientes
  18. Background sync - PouchDB “PouchDB is an open-source JavaScript database

    inspired by Apache CouchDB that is designed to run well within the browser. PouchDB was created to help web developers build applications that work as well offline as they do online.”
  19. Push Notifications • Chequear primero si están disponibles • Tenemos

    que pedirle permiso al usuario • Involucrados con los browser vendors (por ejemplo chrome requiere registrar la app) • Funcionan como las push notifications mobile nativas