Progressive Web Applications

Transcript

1. Moebius Progressive web applications Dan Zajdband (@impronunciable)

2. 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

3. Moebius (1966) “Un topólogo investiga la misteriosa desaparición de un

   tren subterráneo junto a sus 30 pasajeros.” - IMDB
4. None

5. 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

6. 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?

7. La respuesta a (casi) todo PROGRESSIVE ENHANCEMENT

8. Progressive enhancement 101

9. 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

10. Progressive Web Applications El foco está puesto en: • Networking

    • Lifecycle
11. None

12. 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

13. manifest.json { "name": "Muddy", "short_name": "Muddy", "start_url": "/", "scope": "/",

    "display": "standalone", "background_color": "#D32F2F", "icons": [ { "src": "logo.png", "sizes": "256x256" } ] }

14. 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') }

15. Features asociadas a PWAs • Offline y caches • Home

    screen icon + splash screen • Push notifications • Background sync + Background jobs

16. Gratarola Si registramos un manifest y un service worker somos

    candidatos a: • Install banner • “Standalone mode” • Splash screen

17. Gratarola

18. 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.
19. None

20. 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

21. 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

22. La vida secreta del service worker self.addEventListener('install', function(event) { /*

    ... */ }); self.addEventListener('activate', function(event) { /* ... */ }); self.addEventListener('fetch', function(event) { /* ... */ });
23. None

24. 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.

25. 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
26. None

27. 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

28. Background sync - WebStorage • LocalStorage • IndexedDB (IDB promise)

    • WebSQL

29. 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.”
30. None

31. 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

32. Qué está mal? localStorage[‘messi’] = ‘gol’;

33. Qué está mal? try { localStorage[‘messi’] = ‘gol’; } catch

    (error) {}

34. La posta • Async/Await (js) • Flexbox (css)

35. Recursos • https://www.youtube.com/watch?v=cmGr0RszHc8 • https://serviceworke.rs/ • https://developers.google.com/web/updates/2015/11/app-shell • https://getmango.com/blog/adaptando-la-web-a-plataformas-moviles •

    http://hood.ie/blog/beyond-progressive-web-apps-part-1.html

36. Preguntas? • dan.zajdband@(gmail | nytimes).com • @impronunciable • Zajdband.com