Progressive Web Apps

by

Simon Hofmann

-

2018-05-15

and 2018-07-03

Overview

  • Intro
  • PWAs from 10.000 feet above
  • PWA Basics
  • PWA Details
    • Webmanifest
    • Service Workers

Intro

Why a PWA?

  • They're "just" web technologies
  • Easy to distribute
  • (Almost) Platform independent
  • No app-store fee

PWAs from 10.000 feet above

"Any web app could be a PWA if you're brave enough!"

-

Me - today

PWAs are:

  • HTTPS
  • HTML5, CSS3
  • Modern™ JavaScript
  • Mobile first, responsive design
  • Webmanifests
  • Service workers

PWA Basics

PWAs provide:

  • "App-like" UI/UX
  • "Install on homescreen" banner
  • An auto-generated splash screen
  • "Native" features:
    • Offline capability
    • Background synchronization
    • Push notifications

PWA Details I

Webmanifest

  • Contains info about your PWA
    • Name
    • Icons
    • Scope
    • Orientation
    • ...
  • Makes your PWA installable
  • Used to generate the splash screen

Webmanifest

Example manifest file

Webmanifest

Manifest registration

Webmanifest

PWA Details II

Service Workers

  • Just JavaScript
  • Runs in a separate thread
    • No DOM access
  • Even runs when:
    • The user has left the page
    • The user has closed its browser

Service Workers

  • Service workers act as proxy
  • `fetch` events can be intercepted
    • Custom request logic
    • Custom responses
    • Manual caching
  • Powerful request manipulation
  • Requires HTTPS connections (except on localhost)

Service Workers

Service worker registration

Service Workers

Capabilities object

Service Workers - Lifecycle

Service worker lifecycle

Service Workers

  • Service workers are only active after the user reloads the page
  • (Though immediate updates can be enabled)
  • Instant reload might cause weird behaviour

Service Workers - Offline Capability

Service worker oninstall event

Service Workers - Offline Capability

  • "App Shell" caching
  • Hook into the install event and put all static assets into cache
  • Once the page reloads, all static assets are served from cache
    • Faster page loading
    • Our static content will be available offline

Service Workers - Cache Versioning

  • Cached assets will be served from cache
  • In case of an update, our cache serves outdated assets
    • Caches can be named
    • Versioned cache names avoid outdated caches
    • Cache version increases as soon as we update data

Service Workers - Cache Cleanup

Service worker onactivate event

Service Workers - Cache Cleanup

  • Once the `onactivate` event fires, our updated service worker is active
  • Old caches can be evicted, since we don't need them any longer
  • Clear all caches which do no match the current version

Service Workers - Intercepting Requests

Service worker onfetch event

Detour - Installable Apps

  • At this very moment our PWA becomes "installable"
  • This requires:
    • HTTPS connection
    • Webmanifest with name, short_name and icons
    • Installable service worker with `onfetch` listener
    • Install popup will be shown if criteria are met

Back to topic...

Service Workers - Dynamic Caching

  • It's also possible to cache dynamic requests
  • By hooking into the `onfetch` event, we're able to manually cache responses

Service Workers - Dynamic Data Caching

Service worker content cache

Service Workers - Dynamic Data Caching

  • Service workers can store dynamic data like JSON in IndexedDB
  • This allows to return custom Response objects to return cached dynamic data
  • Caching dynamic data provides true offline availability

Service Workers - Caching Best Practices

Service Workers - Background Synchronization

Service worker onsync event

Service Workers - Background Synchronization

  • Unfortunately there are quite a few places with poor or no network connectivity
  • Service workers allow us to cache requests until connection is re-established
  • (Browser support is really poor at the moment, though)

Service Workers - Background Synchronization

  • The `SyncManager` allows us to register sync events with certain tags
  • Every time connection re-establishes, a `sync` event is fired and we're able to react to it from within our service worker
  • Depending on the event's tag, we're able to carry out the appropriate action

Service Workers - Background Synchronization

  • Caches are not able to store Request objects
  • Workaround:
    1. Store request data in IndexedDB
    2. Build request in sync event and try to send it
    3. Remove data from IndexedDB on success
    4. Profit $$$

That's it (for now)!

Thank's for your attention!

Questions?

Or feedback?