Chrome Dev Summit - Progressive Web Apps / The Physical Web

Transcript

1. Progressive Web Apps
2. What are Progressive Web Apps? • Progressive web apps are a plan to provide web apps with several of the advantages of a standalone native app. • These advantages are: – Offline support – Quick loading – Push messaging – A place on the device home screen • The name implies that these capabilities are provided as a progressive enhancement to something that is 'just a web page'.
3. Progressive Apps and Service Workers • Most of the additional capabilities of a progressive web app are provided using a service worker. • Offline support and quick loading are provided by the service worker's cache functionality, plus an app shell, about which more later! • Push messaging requires a service worker to respond to and display pushes. • Finally, since service workers require HTTPS, progressive web apps must be served securely.
4. App Shells • The app shell is a recommended complement to the service worker for providing quick loads and offline support. • The definition of an app shell is: – A page skeleton for the app/site, that – Loads immediately from the service worker, and – Manages the rest of the page load processes through inline or SW-provided scripting
5. Perceived Performance Benefits of App Shells • Once a service worker loads on a domain, it can respond to requests for any content on that domain. • By responding to a request for any page with the app shell, the service worker can provide near- instant apparent responses while waiting for a (possibly slow) network request. • The Flipkart Lite app demoed at the Dev Summit has a first paint at only 30 ms from the initial navigation, even on 2G connections.
6. App Shell Flow #1 • The app shell could just request the original page while showing a loading screen, then replace itself using document.write() • This would require very little change to the existing site, but provides no bandwidth savings or additional capabilities. App Shell Requests Original Page Renders
7. App Shell Flow #2 • The app shell can make whatever requests it wants, so it can request JSON data rather than HTML. • It can then render that data into a (cached) template for a much smaller page load. • This is the model used by the Flipkart app. App Shell Renders Template Renders JSON
8. App Shell Flow #3 (Mobify) • If the app shell loads the original page, it is under no obligation to display it as-is. • In particular, it can pass the original page HTML to Adaptive.js, with a bundle that can be cached by the service worker. • This provides Adaptive without Capturing, at least on Android.
9. App Shell Example • Google has provided an example app with an app shell at https://app-shell.appspot.com/ • Full source and documentation is available at https://github.com/GoogleChrome/application-shell • This example does not use a framework, though support for app shells is in development for both Polymer and React.
10. Service Worker Caching and Offline Support • The service worker has full control over its cache area, and can use any caching protocol it wants to maintain it. • If the device is offline, the service worker can respond from the cache if items are available. • If the items are not available from the cache, the service worker can transparently provide fallback data that is cached if that is simpler for the use case than error handling.
11. Home Screen Support • Home screen support for a web app can be configured in its manifest.json. • If the support is configured and a service worker is loaded, Chrome will ask after a certain number of visits/pages whether the user would like to add the app to the home screen. • If this is accepted, tapping on the home screen icon will load the app from the service worker, including a configurable splash screen. • The first page must load without touching the network.
12. Push Notifications
13. From the Keynote
14. Web Bluetooth and The Physical Web
15. Web Bluetooth • Web Bluetooth is a new API in the pipeline for Chrome that allows a web page to access Bluetooth Low Energy Generic Attributes devices. • HTTPS only!
16. The Physical Web • Basic concept: Place a beacon out in the world, broadcasting an URL that relates to the device or its location. • This is purely a passive interaction; the beacon merely broadcasts the URL and your device can watch for these. • Available already in the Chrome for iOS widget!
17. Eddystone Beacons • The Eddystone standard was released by Google in July. • They can broadcast URLs and/or UUIDs, to be received by apps on mobile devices
18. Physical Web and Active Objects • The page loaded by a device's Physical Web URL can interact with the device. • If Web Bluetooth is supported, it can interact directly with the device. • Otherwise, the page can communicate through the Internet at large with a network-connected device.