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
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
PWAs provide:
- "App-like" UI/UX
-
"Install on homescreen" banner
- An auto-generated splash screen
- "Native" features:
- Offline capability
- Background synchronization
- Push notifications
Webmanifest
- Contains info about your PWA
- Name
- Icons
- Scope
- Orientation
- ...
- Makes your PWA installable
- Used to generate the splash screen
Webmanifest
Webmanifest
Service Workers
- Just JavaScript
- Runs in a separate thread
- 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 Workers
Service Workers - 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 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 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
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
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 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
- There exists various tools and strategies to implement caching
Service Workers - Background Synchronization
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:
- Store request data in IndexedDB
- Build request in sync event and try to send it
- Remove data from IndexedDB on success
- Profit $$$
That's it (for now)!
Thank's for your attention!