18 Feb 2018, 17:56

Implementing the Web Share API in Your App

I was looking into how I might be able to improve the sharing experience on https://scratchthe.world, a digital scratch map PWA that I have been working. One thing I came across recently is the Web Share API, which I thought might be a strong contender for integration. The Web Share API allows for a smoother integration of sharing with popular applications on your mobile device (WhatsApp, Facebook Messenger etc). You can see the documentation on MDN here.

The cool thing about the Web Share API is it has such a minimal interface, making it easy to use an implement without complicating your code. To elaborate, it only has one method, share. The method takes an object with the properties title, text, url:

  • title refers to the title of the thing you’re trying to share, you could for example use document.title here if you’re struggling.
  • text is the text that will be shared with the link in the target application
  • url is the link itself.

Unfortunately support mobile support is not ideal; it’s missing on iOS Safari, Samsung Internet and Opera Mini as it stands.

However depending on who you trust (i.e. StatCounter which powers caniuse.com) Chrome for Android accounts for 50%+ of mobile traffic globally. That’s a lot of people that can benefit!

Another nice aspect of the Share API is it is relatively straight forward to implement a fallback, hence my choice to implement it with Scratch the World. In Scratch the World I provide a input with a link to the state of the map for people to share with there friends. If the Web Share API is available I replace that with a share button.

This isn’t the exact code I use (it is based off the Google Developers page linked above) but to give you a feel for the rough approach:


    const setupShareButton = () => {
        const shareButton = document.getElementById("share-button");

        // Add an onclick listener to the element
        shareButton.addEventListener("click", () => {
            console.log("on click");
            if (navigator.share) {
                // If we have web share enabled use that
                useWebShare();
            } else {
                // Else do something else to help people share
                // your content
                useFallback();
            }
        });
    }
    
    const useFallback = () => {
        console.log("Using fallback!");
        const copyPasteUrl = document.getElementById("copy-paste-url");
        copyPasteUrl.style.visibility = "visible";
        // You could add a bar with share buttons for various 
        // social media sites here as another idea
    }
  
    const useWebShare = () => {
        console.log("Using Web Share!");
        // Web Share is promised based so we do .then and .catch
        // after to handle success or failure
        navigator.share({
            title: 'Using webshare!',
            text: 'This is an example of using web share',
            url: 'https://developers.google.com/web',
        })
            .then(() => console.log('Successful share'))
            .catch((error) => console.log('Error sharing', error));
    }

    setupShareButton();

And that’s it! The more complicated bit here is coming up with a nice fallback approach. You could implement sharing workflows for common mediums like Twitter and Facebook for example. Many providers have sharing URLs that you can use to help share your content. You could combine these with Terence Eden’s SuperTinyIcons to create buttons as a performant solution. On a more experimental note, Phil Nash released a Web Component wrapper for links that will default to the Web Share API when available, which is an interesting idea.

Lastly some of you might be wondering what does the Share API look like in practice? Here’s a video of how it shapes up in Scratch the World on Android Chrome:

07 Feb 2018, 19:00

Messaging Between Tabs Using Service Worker

As of late I’ve been thinking a lot about Service Workers (sorry if this is getting boring!), predominantly in relation to the Cache API. For those of you who aren’t familiar, Service Workers are a type of Web Worker that are shared between a domain scope, and can do cool things like intercept network requests and cache them. This is powerful because it means you can improve the performance of your app for commonly accessed assets and even go offline (as the Service Worker acts a network proxy). Alongside caching, Service Workers provide a host for other capabilities for features such as Push Notifications and also syncing data in the background using the Background Sync API. Not too shabby eh?

In this post I want to think about something slightly different. As mentioned Service Workers have this interesting property in that each Service Worker is registered per scope (by default the base location of the Service Worker script). This means multiple ‘clients’ (a “document in a browser context” or more simply tabs and windows) share the same Service Worker.

One side effect of this is that these clients can pass messages to the Service Worker and then propagate down messages to other open clients. I wanted to explore the potential of this capability a little more. I did a bit of research and found this fantastic blog post from Craig Russell about sending messages with Service Workers. I want to expand on Craig’s work to take it a little bit futher into the realm of updating tab state. Under the assumption that we have correctly registered our Service Worker in the page, lets demonstrate how we might achieve basic message passing, and then see what kind of things that might allow us to do.

From the client code we need a function to allow us to post a message to a Service Worker. One misconception is that the data passed needs to be a string, but it can actually be any basic data type that is acceptable by the Structured Clone Algorithm. In short this is pretty much everything except Errors, Functions and DOM nodes. In theory if you needed to pass these things you could use JSON.stringify and JSON.parse but these present their own pitfalls. This aside let see how the message sending works:


function stateToServiceWorker(data){
    if (navigator.serviceWorker && navigator.serviceWorker.controller) {
        navigator.serviceWorker.controller.postMessage(data);
    }
}

So this function covers sending from the client, what about receiving from the client? We could do something like this in our registration code to register for messages from our Service Worker:


if ('serviceWorker' in navigator) {

    navigator.serviceWorker.register('service-worker.js')
        .then(function() {
            return navigator.serviceWorker.ready;
        })
        .then(function(reg) {
            
            // Here we add the event listener for receiving messages
            navigator.serviceWorker.addEventListener('message', function(event){
                console.log(event.data)
            });

        }).catch(function(error) {
            console.error('Service Worker registration error : ', error);
        });

}

This concludes our client side code for sending and receiving messages. Now what about our Service Worker? Firstly lets examine receiving messages:


self.addEventListener('message', function(event){
    // Receive the data from the client
    var data = event.data;

    // The unique ID of the tab
    var clientId = event.source.id 

    // A function that handles the message
    self.syncTabState(data, clientId);
});

Now that we’ve received a message from the client, we need to know how to send it back to potential clients. We could probably inline this code but wanted to break it down for this demonstration:


self.sendTabState = function(client, data){
    // Post data to a specific client
    client.postMessage(data);
}

Greg’s post actually shows how you can send a message back to the client in question if you so wish. This can be done by sending a reference to a MessageChannels ports across and using some nice Promise callback wrapping, but for the sake of simplicity I’m omitting that here.

Now we can send some message to any specific client of our choosing, but how do actually call this function to access all the clients? We could do something like this:


self.syncTabState = function(data, clientId){
    clients.matchAll().then(function(clients) {

        // Loop over all available clients
        clients.forEach(function(client) {

            // No need to update the tab that 
            // sent the data
            if (client.id !== clientId) {
                self.sendTabState(client, data)
            }
           
        })
    })
}

So we’ve shown how to send and receive messages from the Service Worker. What’s the actual use case for this? Well the original idea I had in mind was quite abstract in syncing state across all opened tabs for an application. Let me show you a basic example through the medium of the this suboptimal gif:

Since then I’ve had a deeper think and I believe there might be some more exact/substantial use cases for this technique to consider, especially in the web app space. For example you could sync the state of your application across tabs without the explicit need for polling/websockets, or watching localStorage / IndexDB. Think updating a balance after bank transfer on another tab, or close a EU cookies banner simultaneously across open clients. You could also do things like triggering tabs that are on a specific route to perform some action, like open a specific dialog or hide information that is no longer relevant. Kitson Kelly made the point that this could come into it’s own in more heavy weight / power-user centered applications.

I’d be really opening to hearing other peoples suggestions on the matter, so feel free to drop me a line on Twitter. If you are interested in seeing the code you can check out the GitHub here.

23 Aug 2017, 19:28

Low Hanging PWA Fruit: Manifest Files and Service Worker Precache

It would be a fair assessment to state that Progressive Web Apps (often abbreviated to PWA) are a popular buzzword in the web development and JavaScript communities at the moment. We have also seen further excitement recently, generated by Apple’s move to start supporting development for PWA features within Safari.

Many great posts and documentation exist around explaining the full case for PWAs and how they benefit users. For a solid introduction to Progressive Web Apps check out Google’s page on the matter. In addition, if you’re looking for something tangible there’s also lots of great examples of PWAs that you can explore in more detail at pwa.rocks.

Perhaps now more than ever it’s time to start exploring how you can start looking into aligning your app or site with PWA functionality. This post will be more practical than theoretical, but to give some context I will list out some of the core concepts of what makes a PWA for those of you unfamiliar:

  • Pages are responsive: The app’s content fits in a sensible way on a tablets, mobiles etc
  • Site is served over HTTPS: assets and resources are served using encryption over the wire
  • The entry page loads offline for users
  • The app uses a manifest.json file to allow adding the app to a users homescreen
  • Load times are reasonable even on slower connections like 3G
  • Each page has its own unique URL
  • The site works across modern browsers

Here we will just focus in on two of these concepts and how to integrate them, namely adding a manifest.json file and adding a Service Worker. Subsequently, we can also use the Service Worker to allow the initial page to work offline by using a precache.

Adding a Manifest File

A manifest file provides a few additional weapons to the web app arsenal for developers. The file itself is fairly plain; a JSON file that contains configuration and metadata for various aspects of the application.

However what the manifest file allows for is a whole host of interesting benefits for those looking to give a more ‘app like’ experience:

  • Allowing users to add a web app to their home screen
  • Giving that home screen button a unique name and icon
  • Giving a splash screen to the app when the user loads it
  • Being able to add a theme colour for the web app
  • Define if the app should load ‘standalone’ or in a web browser

Now we’ve gone through why you would add a manifest.json file, let’s take a look at an example config:


{
  "name": "SomeCoolApp",
  "short_name": "SomeCoolApp",
  "start_url": ".",
  "display": "standalone",
  "background_color": "#111111",
  "description": "An app for doing cool things",
   "icons": [{
    "src": "images/manifest/48.png",
    "sizes": "48x48",
    "type": "image/png"
  }, {
    "src": "images/manifest/72.png",
    "sizes": "72x72",
    "type": "image/png"
  }, {
    "src": "images/manifest/96.png",
    "sizes": "96x96",
    "type": "image/png"
  }, {
    "src": "images/manifest/144.png",
    "sizes": "144x144",
    "type": "image/png"
  }, {
    "src": "images/manifest/168.png",
    "sizes": "168x168",
    "type": "image/png"
  }, {
    "src": "images/manifest/homescreen192.png",
    "sizes": "192x192",
    "type": "image/png"
  }],
  "related_applications": [{
    "platform": "web"
  }, {
    "platform": "play",
    "url": "https://play.google.com/store/apps/details?id=SomeCoolApp"
  }]
}

You can see that we provide a name and short_name which give a name and an abbreviated name for the app when space is a premium. start_url expresses where the kick off URL for the application when the user starts the app. For example, it could be their profile page or the home page.

As mentioned, we can decide if the app should load in a web browser or have a more native experience. This is realised through the display property. We can provide standalone to give a more native feel as it hides away browser features like the URL bar (this may be a negative feature depending on your feelings!). There are other options for this such as fullscreen which hides OS UI features, and also minimal-ui which take a middle ground on the matter.

The background_color property allows for us to express a colour that will occur before the app has fully loaded into its container. icons provide a way to give icons for our applications at different device sizes. For a full list of options check out MDN’s page on the matter.

You could write the manifest file manually (see Google’s instructions here). However, if you want a more streamlined experience you could use a generator instead. One generator I found user-friendly and straight forward is the app-manifest app on Firebase, which you can use to generate a zip file which can be unloaded into your web app directory.

Lastly we can include it in our home page’s HTML as so:

<link rel="manifest" href="/manifest.json">

Adding a Service Worker

The Service Worker is a slightly more complex concept than the manifest file. In essence Service Workers are web workers that allow code to run outside of the web page context within the browser. The Service Worker also in some ways acts as a network proxy, allowing the developer to change the behaviour of network requests (i.e. to read from a cache rather than a remote resource). In principle, these two concepts allow for a host of new opportunities for web apps, including push notifications, offline interactivity and background sync (sending server requests upon resumption of connectivity).

Before we dive in any deeper, it’s important to note that Service Workers require HTTPS to operate, so you will need to have that setup on your site before continuing (checkout Let’s Encrypt if you’re in need of an SSL certificate).

Although we could dig in deep into the Service Worker internals and life cycle, I would rather focus on getting us up and running with a Service Worker. Others have done a great job explaining Service Workers in depth, for example see the Google primer on Service Worker or check out Phil Nash’s great introductory video here. Instead we will focus on one example Service Worker template that allows us to get a registered Service Worker into our page quickly.

An easy to leverage Service Worker template is provided by sw-precache. Using a precache allows you to serve resources from the Service Worker cache, rather than having to wait for it to come over the wire which improves the performance of the app. It also allows us to get resources whilst offline. sw-precache itself is a tool that allows for the automatic code generation of a Service Worker for caching assets that we would normally receive over the network (images, css etc). As sw-precache requires a preprocessing step to generate the Service Worker we need to leverage a task runner. Here we can use gulp, a JavaScript task runner to create a task to generate the list of resources we want to precache. Here’s some example code with comments:


    // Register the service-worker task with Gulp
    gulp.task('service-worker', function(callback) {

        // Get hold of the sw-precache module
        var swPrecache = require('sw-precache');
        var rootDir = '../public/';
        var serviceWorkerName = "precache"; 
        var fileName = `${rootDir}${serviceWorkerName}.js`;

        // Write the precache Service Worker
        swPrecache.write(fileName, {

            // An array of file paths to precache (we use globbing)
            staticFileGlobs: [
                rootDir + 'index.html',
                rootDir + 'templates/.{html}',
                rootDir + 'js/**/*.{js}',
                rootDir + 'css/**/*.{css}',
                rootDir + 'fonts/**/*.{svg,eot,ttf,woff,woff2}',
                rootDir + 'icons/**/*.{svg}',
                rootDir + 'images/**/*.{png,jpg}',
            ],
            // We remove the prefix and can replace it with another
            // Here `../public/` becomes `/` for example
            stripPrexix: rootDir,
            replacePrefix: "/"

        }, callback);

    });

Running gulp service-worker will generate our Service Worker precache file called precache.js. We can now register this into our app using the code expressed below:

    // Check to make sure the Service Worker feature exists
    if ("serviceWorker" in navigator) {
        // On page load, call the Service Worker registration
        window.addEventListener('load', registerSW);
    }

    // The actual registration code
    var registerSW = function() {

        // The location of our generated pre-cache Service Worker
        var swPath = "/precache.js";
        navigator.serviceWorker.register(swPath)
            .then(registrationSuccess, registrationFailed);

    }

    var registrationFailed = function(error) {
        // Do something if there is an error
    }

    var registrationSuccess = function(registration) {
        // Do something if everything is successful
    }

Once the Service Worker is registered the user will make use of the cache when making network requests for cached assets.

Conclusion

Here we have shown how you could add a manifest and a Service Worker to your web app without complicating your application code too much. If you already have gulp in your build process integrating sw-precache shouldn’t be too much extra effort to get up and running. Similarly using the manifest.json app shown above we can simply generate a working manifest file for our application.

Hopefully, this article has begun to pave the way for further PWA features in your applications. Support is gradually getting there so the reasons to avoid the potential benefits are decreasing. If you are interested in auditing your app to see how much it adheres to Google’s PWA checklist, check out a Chrome extension called Lighthouse. Lighthouse will score your app depending on how well it compares a set of pre-defined criteria.