Progressive Web Applications

@ BAFrontend (2016)

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
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
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.
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) { /* ... */ });
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
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.”
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