A fairy tale about dynamic manifest.json files: The First Chapter

Reading Time: 4 minutes

Good afternoon passengers. This is your captain speaking. Our today’s in-flight movie will talk about implementing web notifications with Pushwoosh and how a dynamic manifest.json file was required in order to support reusability. So let me start this fairy tale by giving an overview of what we’ll discuss. In this post, I’ll guide you through my challenges and decisions when implementing Pushwoosh’s Web Push SDK 3.0. Long story short, I did it, it’s available on forge and you’re free to use it!

At My Game Solutions, we are developing a mobile application with the major intent to connect players. For me, that’s a real issue and a problem worth solving. Since I’m still fairly new in my current city and I don’t know a lot of people, having a tool that allows me to find other people with the same interests (in this case, playing a sport) would be very good. But let’s stop talking about my needs and let’s focus on the problem: implement web notifications.

 

Why and Who?

It has become pretty common today for websites to ask your permission to receive notifications. It’s a useful way to have a deeper connection with your users and a different way to obtain a competitive advantage over your competition. All of the “generic” news website I use prompt for notification permission. Fun fact though: the two major websites for sport information don’t prompt you and one of those serves content over HTTP even when you request the HTTPS version. But while here I’ve shown pratical reasons why a news website might want to send you notifications, our product relies on those same notifications. How can you know that I have invited you? You’ll have to receive notifications, of course!

So we have partnered with Pushwoosh in order to use them as our tool to manage push notifications. As you might see from their website, they provide support for twenty-one (21!) platforms with a single service. Since we wanted to support mobile as well as push notifications, it was an easy choice. The configuration is straightforward and no bigger issues have arisen – except that time when I could not use p12 files generated by OpenSSL because unknown reasons.

 

How?

I’m not sure if the choice was also influenced by the availability of an already-built – and supported – plugin for the OutSystems platform since, at the time the choice was made, I was not part of My Game Solutions. The plugin works but has some flaws, as I’ve documented here and fixed here. Also, there is an excellent article detailing an almost step-by-step guide on the usage here. Credit needs to be given and these guys have done a great guide.

So far we have: a service that supports 21 platforms and an official plugin that supports mobile only. In the case you’re wondering what’s missing… web push notifications. And that’s where the fun begins!

 

The starting point…

Let’s start from the beginning: you go to Pushwoosh’s website or to Google (which is what I do, 99.9% of the time) and just search for the Web Push SDK 3.0. You follow the instructions and download it. And what do you get? A manifest.json containing some static data and a pushwoosh-service-worker.js file. According to the documentation, both of those files need to be publicly accessible. First thought? Import as resources and deploy to a target directory. Easy.

Before doing it, we need to change the contents of the manifest.json file. The default contents are:

{
    "name": "Pushwoosh Demo",
    "short_name": "Pushwoosh Demo",
    "gcm_sender_id": "GOOGLE_PROJECT_NUMBER",
    "display": "standalone",
    "gcm_user_visible_only": true
}

For my initial version, I changed the first three values. The first two are arbitrary and the third one is a value you can get from your Google Developer’s console. Files changed, resources imported, marked for deployment and we are ready to go… to next step*.

Now it’s time to import that manifest.json file into the head of our document – all of the following steps are made on the preparation. In order to do so, I’ve used HTTPRequestHandler.AddLinkTag action:

 

 

 

Now that this is done, the next step is to import the SDK in an asynchronous manner. In order to achieve that, I had to do a custom version of the HTTPRequestHandler extension since the original one doesn’t allow me to import the files asynchronously – at least, as far as I know. If, for any reason, it supports it, let me know. It will be one less dependency.

So my new extension HTTPRequestHandlerBuffed – I thought buffed was a good suffix for it – just allows to add a raw tag to the header and you use it just like this:

 

With this, we end part one. Stay tuned for part two, where we’ll discuss the initialization of the component as well as the dynamic part of the manifest.json file.

 

As usual, let me know your comments via comment form below, via Twitter or via contact form.

Armando

 

* This next step has no relation to OutSystems NextStep event. But you should go, it’s nice.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.