In this series of articles, we have described what PWAs are, how they work, can be leveraged by media companies, and what would be the benefits of it. In this article, we will go a little further, and explain how the capabilities of PWAs can be leveraged with the THEOplayer PWA SDK.

Setting up a PWA with THEOplayer

At THEO, we strongly believe in the future of PWAs. They provide an interesting balance between web and native apps, bringing high flexibility at a fraction of the cost of natively developed apps. For these reasons, we have built the THEOplayer PWA SDK. This SDK empowers our customers to more easily set up PWAs, and provides a framework for PWA development.

Using the THEOplayer PWA SDK has been made very simple. Once you have loaded the SDK, you will notice a number of different assets:

  • HTML files showing a standard index page reference
  • JavaScript files as a basic service worker example
  • JavaScript files containing the player libraries
  • CSS files containing player styling
  • A sample web app manifest

When you would want to launch a basic PWA, it could already suffice to take these assets, fill in the placeholders (like “Sample App” names), and deploy it on a web server. Doing so would only give you a basic PWA, which shows how to include the THEOplayer libraries. When you want to deploy a PWA reflecting your brand, and playing your content, some additional steps will need to be taken, and these assets will need to be integrated into your (mobile) website. If you need assistance with this, don’t hesitate to let us know: our services team is more than happy to help.

Leveraging preloading in your PWA

When a service worker is installed correctly a few new options become available. This will mostly manifest in additional capabilities in APIs as well as modifications in behavior. For example, the Cache API will allow you to schedule caching tasks on the service worker instead of the main browser thread. As a result, caching can now be done in the background. Also, the THEOplayer instances within your pages will have access to the assets cached by the service worker. This means THEOplayer will automatically load its assets from cache first, providing a significant speed improvement. THEOplayer will also verify if those assets would need to be reloaded.

The biggest advantage in preloading is often achieved by preloading starting pieces from relevant content. In order to preload the first part of an asset, simply use the Caching API as if you would be on a normal web page:

The amount of content to cache will depend on the use cases you see. In most cases, caching a fixed number of seconds, for example the first 10 or 30 seconds could be interesting. In some cases, it might be more ideal to choose a certain percentage of the video asset, for example caching the first 5%.

When preloading, it is important to keep into account the likeliness of a user watching a certain piece of content. As a rule of thumb, we advise to give higher priority to the assets a user is most likely to click.

This likeliness can be calculated based on the number of pixels shown on the screen where a user could click to go to the asset, in combination with the distance of how far the content is from the middle of the screen. This simple formula ensures main featured content (which are often shown bigger on front pages) and the videos within the screen are prioritised to preload. Different heuristics can however be used. For example, priority for content which has already been watched could be lowered, the videos being watched most could be increased, or frequent item set information could be used based on the user profile. Often however, these metrics are already considered when displaying the links to the content.

Distance of the player from the center of the image and Percentage of the window occupied by the player box

Fig. 1 - Distance from center and percetange of screen

Enabling offline playback

Offline playback liberates your viewers completely from any network dependency. This allows viewers to access content even when they are on the train, in an airplane, or in an area where their data services are not available. With the THEOplayer PWA SDK, making content available offline becomes easy.

Making content available offline comes in two steps:

  • in a first step, THEOplayer will download the content and store it in the local storage on the device;
  • during playback, the player will access the content from the storage instead of using the network connection.

When making offline content available however, there are a few aspects to keep in mind:

  • Multiple audio tracks: When working with multiple audio tracks, users would likely be able to consume the content in the language they prefer. There are multiple approaches to make this possible. One approach could be to simply download all audio tracks to the local storage. This however would consume more storage on the user’s device, which could be an unwanted side-effect. An option which is often better, is to store the user’s preferred language and obtain that audio track. Often, we see it is probably a good idea to load the original audio track as well. The best approach can likely be found in providing the option for the user. This can be done by allowing the user to configure within his account which audio tracks need to be loaded by default. In order to offer more flexibility, it might be interesting to also provide the option to choose the tracks to load on a per-asset basis.
  • Subtitles and closed captions: With subtitles, we see a similar issue as with multiple audio tracks. In this case, it is also important to download the appropriate languages without loading too much data. For subtitles however, storage consumed for unused tracks is often significantly lower compared to audio tracks. As a result, this case allows for more flexibility in loading multiple (potentially unused) languages.
  • DRM and content protection: When content is being made available offline, one important aspect to keep in mind is content protection. When content is protected with DRM or similar measures, THEOplayer will automatically detect this. To provide full network independence, DRM licenses required should be made available in offline mode, allowing the player to store these licenses in secured storage. If licenses are not made available in offline mode, THEOplayer will need to access the license server to play the content. While the media itself will not be loaded from the web, the license will be resulting in limited network independence.
  • Other metadata: Next to alternative audio tracks, subtitles and DRM licenses, there might be other metadata which should be synchronized when making content available offline. This metadata could contain content titles, descriptions, movie posters, thumbnails and much more. It is always important to keep in mind the storage usage on the user’s device. As a rule of thumb, the balance between enhancement in user experience and storage usage should be optimized for the specific use cases.

Customizing media notifications

A nice advantage of modern browser APIs and PWA capabilities, is the possibility to integrate with media notifications. This allows viewers to access metadata about the content being played from within the notification slider or lock screen. This is especially important for use cases where audio is being streamed, or in case a remote casting functionality is used.

Next to viewing metadata, the integration with media notifications also allows to control media from within those notifications. With these capabilities, users can pause, play, seek or change tracks from their lock screen.

When THEOplayer is configured, the metadata to be shown can be entered together with the source of the video. This metadata will be picked up automatically by THEOplayer to be displayed when casting, or when displaying a notification. This includes information such as the title, description, and poster image.

In parallel with showing the appropriate metadata, THEOplayer will also automatically manage the media session to react to commands coming from the notification buttons. This becomes possible without the need for any additional configuration.

Push Up notifications smartwatch and smartphone

At THEO, we continuously strive to make available new capabilities and features to our SDKs. With this PWA SDK, we are committed to make life easier for our customers, and harness the power of PWAs in a straightforward and effective manner. Do you have any questions on PWAs and how they can be used for your use cases? Don’t hesitate to let us know: our technical team is happy to help and provide insights.

Get in contact with us