UPshow creates interactive experiences on digital screens for brick-and-mortar businesses—encouraging customers and employees to engage with businesses using their mobile devices. To provide a full-screen, immersive, controlled experience, UPshow uses Kiosk apps. But with the upcoming deprecation of Chrome Apps, they needed to migrate their existing kiosk solutions to Progressive Web Apps (PWAs).
To complete this migration, UPshow’s team had to replicate some core functionality from their existing Chrome Apps, including uniquely identifying the device the apps run on and managing cached videos.
To provide the best in client experiences, UPshow needs to maintain a consistent set of logs and metrics—letting them debug and optimize their UX. To be truly effective, they need to be able to quickly pinpoint exact devices across a fleet. In the world of web privacy, this is known as fingerprinting.
Fingerprinting may introduce privacy concerns—so there is no web API for it. But in the context of Enterprise enrolled ChromeOS devices, this technique can be used for legitimate purposes—such as providing better customer support. A Chrome extension installed through an admin policy can gain access to special device attribute APIs that expose identifiers. UPshow pairs these with a PWA to uniquely identify managed devices, achieving the fleet-wide logging and metrics they need.
To retrieve an enrolled device’s ID, UPshow needed code for both their PWA and the extension. Retrieving the device ID starts by having the PWA send a message to their Chrome extension, which responds with the device’s ID—if one is available. This can then be used later, such as while logging.
When the extension receives this message, it then calls the Enterprise
getDirectoryDeviceId API to get the device ID and send it back to the PWA.
With both the extension installed through admin policy and the PWA running in kiosk mode on an enrolled device, UPshow can identify which device across a customer’s fleet their app is being run on—letting them tie logs and metrics to specific devices, aiding in optimization and maintenance.
UPshow’s application experience relies heavily on client uploaded videos. To improve application performance and reduce costs, they often need to cache very large video files on the device. This can prove challenging for two reasons:
- Files can’t be precached. Because what files need to be cached aren’t known in advance, they need to be cached on demand by intercepting requests as they’re needed.
- They need to handle range requests. Their caching strategy needed to handle range requests, as browsers typically use a Range header for media content—which could lead to 206 partial content responses instead of a full response.
To solve this issue, the UPshow team turned to the Workbox service worker library. By leveraging Workbox’s runtime caching strategies and plugins, they were able to solve for both of these challenges.
The UPshow team used a Workbox runtime caching strategy to fulfill on-demand caching requests. The team selected the
CacheFirst strategy, ensuring that the first time a request is made, it goes to the network. That response is then cached and, from that point onward, it is served from the cache:
This cache handler uses the
CacheableResponsePlugin to ensure that only successful requests (those with a status of 200) are cached. It also uses the
RangeRequestsPlugin to allow the cache to return a specific range of a file from a fully cached response—necessary, for instance, if a user starts a video part of the way through. Workbox Routing uses
videoCacheHandler to cache video files (not shown).
The out-of-the-box plugins, though, aren’t enough to handle partial responses. To do that, they needed to create a custom Workbox plugin,
Large video files are usually served to users in small chunks, with the section sent identified with a
content-range header and a 206 status code. This is meant to allow videos to start quickly and download more as you watch, but it can also lead to video buffering if your playback catches up with what’s available.
To combat this, UPshow sends the whole file instead, but still sends it with the
content-range header and status code for browsers that expect 206 responses for videos. To avoid caching only fragments of a file, Workbox doesn’t support caching 206 responses—so to handle these requests, UPshow wrote a custom Workbox plugin to properly cache whole files sent with 206 statuses.
First, the plugin checks if the potential item has a 200 status. If it does, the item is returned, ready to cache. If the status is 206, a response from a range request, it waits to ensure it has the whole item and then returns it with an overridden 200 response code, making it cacheable:
With this custom plugin in place, UPshow can cache any video that may be requested from their application and play it back without needing to hit their server again.
UPshow’s path from Chrome Apps to PWAs has been quite smooth. Close parity between native applications and web applications means they were able to make the switch without losing any functionality. Thanks to the resources available, they were able to get up to speed with PWAs quickly, and many of their needs were already covered by existing libraries. Where they weren’t, they were able to combine PWAs with Chrome Extensions to fill the gaps and take advantage of ChromeOS-specific capabilities.
Even better, the migration has had a significant impact on UPshow’s business. UPshow reported that they were able to realize significant cost reductions through their use of caching. Further, cost savings in bandwidth from video consumption opened a new market from clients that didn’t have dedicated hardware.
UPshow plans to continue adding more functionality to their PWAs—and hope to see these wins increase as they invest more in both PWAs and Kiosk mode on ChromeOS.