General format for passing messages to Cordova

Hi,

We're experimenting with Urban Airship. We currently use a different notification provider but are are interested in what UA can offer.

Our Cordova app is in the Apple store and Google store so we have some experience in making these things work :)

Our app provides personalised traffic information to London drivers so notifications are a vital part of our app.

We have no problems in generating messages to the UA server from our servers, we also have the UA plugin working in our app. 

Our question is around the message format and how we are expected to provide the information to the UA server.  We're not looking for technical help, but some guidance on how to structure the data we want to pass to our app. We have also read the documentation :)

A use case may help:

We want to send an IOS  silent notification to our app. This is a signal for it to go and collect a lot of updated traffic information from a central server. This is a technique we are already using and it works well for us. We have a lot of data that we don't want to send using a notification. 

We create a JSON notification in Perl (we use perl for all backend processes) with

notification => { ios => { 'content-available' => 1 }}

This is correctly passed to the UA server, we then get a push event received at our client

2017-01-02 09:25:33.853 Jambuster[2505:205584] [I] +[UAAppIntegration handleIncomingNotification:foregroundPresentation:completionHandler:] [Line 228] Received notification: {
"_" = "efbb6bca-01b1-4c07-826f-f4a72cc85281";
 aps =     {
        "content-available" = 1;
    };
}

This looks good but the event received by our UA JavaScript handler is NOT the same JSON format, 

We get 

2017-01-02 09:57:45.700 Jambuster[2505:205584] *************************
2017-01-02 09:57:45.700 Jambuster[2505:205584] ***** HandleUrbanAirshipIOSNotification: event = {"message":"","extras":{}}
2017-01-02 09:57:45.700 Jambuster[2505:205584] *************************

returned. 

The code for the JavaScript handler is pretty simple, we're just printing it out whilst we check what to do.

function HandleUrbanAirshipIOSNotification(event) {
var debugHandleUrbanAirshipIOSNotification = debugTrue;
if (debugHandleUrbanAirshipIOSNotification)
{
ConsoleLog("*************************");
ConsoleLog("***** HandleUrbanAirshipIOSNotification: event = " + JSON.stringify(event));
ConsoleLog("*************************");
}}

We have experimented with passing extra information in the extras field, e.g. a second content-available flag and that seems to work, but it doesn't feel right. We *think* we should get the same JSON format in our handler and NOT have to pass additional information in the extras field.

{
    "_" = "efbb6bca-01b1-4c07-826f-f4a72cc85281";
    aps =     {
        "content-available" = 1;
    };
}

Looking through the docs doesn't seem to shed any light on this, e.g. how would we handle the content-available flag without passing it in the config twice. 

Any suggestions welcomed.

Thanks

Rob

Didn't find what you were looking for?

New post

Comments

3 comments

  • Rob,

    That behavior is actually expected.

    The payload that Urban Airship requires when you send a push is quite a bit different than the APNS payload that the device receives.

    Comparing our JSON structure with Apple's JSON structure, you'll see that the two are similar, but very different.

    So, what you're seeing in your handler is the Urban Airship structure of data, not the APNS structure of data, which is expected. Because there isn't any extra information or any message, you get the empty response as you've shown. As soon as you enter more details into the push itself will you see information populate in the response.

    Typically, when you send a silent push using the content-available flag, there will be some data inside the payload itself, usually within the "extras" object. That extras object can contain key/value pairs that, when the app detects them, will tell the app to download some data or perform some action in the background. It's not usually seen where a silent push is sent with the single purpose of waking the app up without any additional data.

    Comment actions Permalink
    1
  • Michael,

    Thanks for that information. We kind of guessed that was the approach, but since it was so different to other notification providers we were a little confused. 

    Adding in these extra fields will add around 10-15 mins of work, so its neither here not there from a development point of view. We were more concerned that we had misunderstood the philosophy of how we were expected to pass data around.

    As an aside we actually do use the content-available flag just as a signaller that data is available. We have so much data that changes so regularly its easier to work this way. 

    Thanks for taking the time to reply.

    Rob

    Comment actions Permalink
    0
  • Rob,

    Good to hear! With regards to the data changing in your app, that makes sense. If it works for you, then I see no reason to not continue using it in that fashion.

    Comment actions Permalink
    0

Please sign in to leave a comment.