[Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4 push plugin specifically on the iOS side.

Summary

We have two versions of our app, an Android and an IOS version. Both use the latest Cordova push plugin 2.0.4. They also both have the latest Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android versions are compiled at the same time. We are running cordova 5.3.3 with Ionic 1.7.8 (?).

  1. We make sure that both apps are NOT started up on each device. We also check they are NOT in the background.

  2. We send the same simple notification to each device. This notification config is as below, we have anonymised the variants and alias in this JSON structure, though we can report that the UPS server sends the data correctly. We use the additionalData flag to provide the information necessary to decide which notification has been clicked in the notification drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
    'additionalData' => { 'Disruption_Id' => '107546',
                         'EpochTime' => '1450125268'
                        },
    'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.' },
    'alias' => [ ‘alias1’ ],
    'ttl' => 600
};
  1. Both devices show the message, the Android device stacks the message and the iOS device display an individual message. This looks correct.

  2. Clicking on the Android stacked message starts up the app and the Javascript notification handler we have defined, HandleAeroGearNotification is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","badge":"-1"}}
  1. Clicking on the notification in the notification drawer on the iOS device also starts our app up correctly but the notification handler, HandleAeroGearNotification(), is NOT called. The app starts up as normal as if the notification had not been clicked. We would expect the notification handler to be called in iOS as it is in Android.

  2. All notifications are cleared on both Android and iOS correctly when the app is started up.

  3. We define HandleAeroGearNotification as


    var aeroGearPushConfig = {
        pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
        ios: {
            variantID: “variantid_obscured”,
             variantSecret: “variant_secret_obscured”
            } ,
         android: {
                senderID: "variantid_obscured" ,
            variantID: "variant_id_obscured" ,
            variantSecret: "variant_secret_obscured"
         } ,
        sendMetricInfo: true,
        alias: alias1
    };

    function HandleAeroGearNotification(event) {
        console.log(“HandleAeroGearNotification: event => “ + JSON.stringify(event));

        // Stuff cut for clarity
    }

    // Slightly simplified registration event.
    push.register(HandleAeroGearNotification , function () { 
        console.log(“Success”):
    } , function () {
        console.log(“Failure”);
    } , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Erik Jan de Wit
Hi Rob,

That would be a bug, although I can not reproduce it, to test it this is what I've done to test it:

$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed pushServerUrl and variant info and changed quotes to " (this is your email client no doubt) and changed : into ; after console.log("Success")


Attach Safari debugger and send a message when the app is in the foreground and get in the console:

HandleAeroGearNotification: event => {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send another message and 'touch' the message to launch the app:

HandleAeroGearNotification: event => {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to remove it send another message and 'touch' it to launch the app. This kills my safari debugger so no way to see the console log, but in this case coldstart should be true. To test this better changed the code to alert instead of console:

  function HandleAeroGearNotification(event) {
      alert("HandleAeroGearNotification: event => " + event.coldstart);

      // Stuff cut for clarity
  }

I send another notification 'touch' it to launch the app and see the alert box display the text:

HandleAeroGearNotification: event => true

Hope this helps



On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4 push plugin specifically on the iOS side.

Summary

We have two versions of our app, an Android and an IOS version. Both use the latest Cordova push plugin 2.0.4. They also both have the latest Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android versions are compiled at the same time. We are running cordova 5.3.3 with Ionic 1.7.8 (?).

  1. We make sure that both apps are NOT started up on each device. We also check they are NOT in the background.

  2. We send the same simple notification to each device. This notification config is as below, we have anonymised the variants and alias in this JSON structure, though we can report that the UPS server sends the data correctly. We use the additionalData flag to provide the information necessary to decide which notification has been clicked in the notification drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
    'additionalData' => { 'Disruption_Id' => '107546',
                         'EpochTime' => '1450125268'
                        },
    'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.' },
    'alias' => [ ‘alias1’ ],
    'ttl' => 600
};
  1. Both devices show the message, the Android device stacks the message and the iOS device display an individual message. This looks correct.

  2. Clicking on the Android stacked message starts up the app and the Javascript notification handler we have defined, HandleAeroGearNotification is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon Street (EC4N) (All Directions) at the junction of King William Street - To facilitate a heavy lift in Cannon Street, Cannon Street will be closed. Traffic is slow moving on diversion.","badge":"-1"}}
  1. Clicking on the notification in the notification drawer on the iOS device also starts our app up correctly but the notification handler, HandleAeroGearNotification(), is NOT called. The app starts up as normal as if the notification had not been clicked. We would expect the notification handler to be called in iOS as it is in Android.

  2. All notifications are cleared on both Android and iOS correctly when the app is started up.

  3. We define HandleAeroGearNotification as


    var aeroGearPushConfig = {
        pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
        ios: {
            variantID: “variantid_obscured”,
             variantSecret: “variant_secret_obscured”
            } ,
         android: {
                senderID: "variantid_obscured" ,
            variantID: "variant_id_obscured" ,
            variantSecret: "variant_secret_obscured"
         } ,
        sendMetricInfo: true,
        alias: alias1
    };

    function HandleAeroGearNotification(event) {
        console.log(“HandleAeroGearNotification: event => “ + JSON.stringify(event));

        // Stuff cut for clarity
    }

    // Slightly simplified registration event.
    push.register(HandleAeroGearNotification , function () { 
        console.log(“Success”):
    } , function () {
        console.log(“Failure”);
    } , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Cheers,
       Erik Jan

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett-2
Erok,

Thanks for the informative reply. I’ve been out all day doing family
things but I’ll go through this in detail once I get back this
evening.

You are correct re quotes. We use MailMate for our email client and
sometimes strange and wonderful things happen with quotes. The : was a
transcription error as we removed a lot of debug code to make the
example simpler. We do have this stuff working in the foreground and
background :)

What you are describing is that we are doing. However I started to put
together a tiny dummy app last night to test the issue in isolation and
will finish it tonight to see if we get the same results. I agree with
everything you say apart from the bit after killing it, touch a
notification and it being seen as an alert (thats the bit we cannot get
working). I’d be delighted if its our code at fault, embarrassed but
delighted.

 From a quick perusal of your code I *think* we are doing exactly what
you are doing.

Let me go through it later and I’ll come back,

Best wishes,

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

> Hi Rob,
>
> That would be a bug, although I can not reproduce it, to test it this
> is
> what I've done to test it:
>
> $ > cordova create push-test <my bundle id>
> $ > cordova platform add ios
> $ > cordova plugin add aerogear-cordova-push
>
> copy paste your js code into www/js/index.js onDeviceReady, changed
> pushServerUrl and variant info and changed quotes to " (this is your
> email
> client no doubt) and changed : into ; after console.log("Success")
>
>
> Attach Safari debugger and send a message when the app is in the
> foreground
> and get in the console:
>
> HandleAeroGearNotification: event =>
> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> I press the home button and send the app to the background send
> another
> message and 'touch' the message to launch the app:
>
> HandleAeroGearNotification: event =>
> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> The I kill the app by pressing home twice and swiping over the app to
> remove it send another message and 'touch' it to launch the app. This
> kills
> my safari debugger so no way to see the console log, but in this case
> coldstart should be true. To test this better changed the code to
> alert
> instead of console:
>
> function HandleAeroGearNotification(event) {
>    alert("HandleAeroGearNotification: event => " + event.coldstart);
>
>    // Stuff cut for clarity
> }
>
> I send another notification 'touch' it to launch the app and see the
> alert
> box display the text:
>
> HandleAeroGearNotification: event => true
>
> Hope this helps
>
>
>
> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
> [hidden email]> wrote:
>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>>  'additionalData' => { 'Disruption_Id' => '107546',
>>                       'EpochTime' => '1450125268'
>>                      },
>>  'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>>  'alias' => [ ‘alias1’ ],
>>  'ttl' => 600
>> };
>>
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>>
>>  var aeroGearPushConfig = {
>>      pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>      ios: {
>>          variantID: “variantid_obscured”,
>>           variantSecret: “variant_secret_obscured”
>>          } ,
>>       android: {
>>              senderID: "variantid_obscured" ,
>>          variantID: "variant_id_obscured" ,
>>          variantSecret: "variant_secret_obscured"
>>       } ,
>>      sendMetricInfo: true,
>>      alias: alias1
>>  };
>>
>>  function HandleAeroGearNotification(event) {
>>      console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>>      // Stuff cut for clarity
>>  }
>>
>>  // Slightly simplified registration event.
>>  push.register(HandleAeroGearNotification , function () {
>>      console.log(“Success”):
>>  } , function () {
>>      console.log(“Failure”);
>>  } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>>
>> Rob
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett
In reply to this post by Erik Jan de Wit
Erik,

We have built our own test using a cordova startup, much the same as you
have outlined below, using our own JS code and it works OK. We get the
same results.

However when we run our app (with the code from above) we still get the
same error as before.

So clearly the Aerogear plugin does work and something in our code, or
in the Ionic framework we are using, is causing a problem specifically
to IOS. We spent a couple of hours late yesterday going through our code
trying to see what, if anything was causing the issue but nothing
positive emerged.

So the problem is ours to solve, we will keep looking at pulling code
out until it works. We’ll also reproduce the simple test but using the
Ionic framework to see if thats the problem. Our thinking has to be that
its our code and theres some sort of race or timing condition we are
introducing.

Thanks again, sadly we have a lot of work to do today.

Best wishes,

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

> Hi Rob,
>
> That would be a bug, although I can not reproduce it, to test it this
> is
> what I've done to test it:
>
> $ > cordova create push-test <my bundle id>
> $ > cordova platform add ios
> $ > cordova plugin add aerogear-cordova-push
>
> copy paste your js code into www/js/index.js onDeviceReady, changed
> pushServerUrl and variant info and changed quotes to " (this is your
> email
> client no doubt) and changed : into ; after console.log("Success")
>
>
> Attach Safari debugger and send a message when the app is in the
> foreground
> and get in the console:
>
> HandleAeroGearNotification: event =>
> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> I press the home button and send the app to the background send
> another
> message and 'touch' the message to launch the app:
>
> HandleAeroGearNotification: event =>
> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> The I kill the app by pressing home twice and swiping over the app to
> remove it send another message and 'touch' it to launch the app. This
> kills
> my safari debugger so no way to see the console log, but in this case
> coldstart should be true. To test this better changed the code to
> alert
> instead of console:
>
> function HandleAeroGearNotification(event) {
> alert("HandleAeroGearNotification: event => " + event.coldstart);
>
> // Stuff cut for clarity
> }
>
> I send another notification 'touch' it to launch the app and see the
> alert
> box display the text:
>
> HandleAeroGearNotification: event => true
>
> Hope this helps
>
>
>
> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
> [hidden email]> wrote:
>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>> 'additionalData' => { 'Disruption_Id' => '107546',
>>                    'EpochTime' => '1450125268'
>>                   },
>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>> 'alias' => [ ‘alias1’ ],
>> 'ttl' => 600
>> };
>>
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>>
>> var aeroGearPushConfig = {
>>   pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>   ios: {
>>       variantID: “variantid_obscured”,
>>        variantSecret: “variant_secret_obscured”
>>       } ,
>>    android: {
>>           senderID: "variantid_obscured" ,
>>       variantID: "variant_id_obscured" ,
>>       variantSecret: "variant_secret_obscured"
>>    } ,
>>   sendMetricInfo: true,
>>   alias: alias1
>> };
>>
>> function HandleAeroGearNotification(event) {
>>   console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>>   // Stuff cut for clarity
>> }
>>
>> // Slightly simplified registration event.
>> push.register(HandleAeroGearNotification , function () {
>>   console.log(“Success”):
>> } , function () {
>>   console.log(“Failure”);
>> } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>>
>> Rob
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
>  Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett
In reply to this post by Erik Jan de Wit
Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

1. IOS App in foreground, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good

2. IOS App in background, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good

3. IOS App killed, we send a simple push notification from the Aerogear
console and some of the time when we click on the notification in the
notification drawer we do NOT get the notification handler called. Not
so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

> Hi Rob,
>
> That would be a bug, although I can not reproduce it, to test it this
> is
> what I've done to test it:
> $ > cordova create push-test <my bundle id>
> $ > cordova platform add ios
> $ > cordova plugin add aerogear-cordova-push
>
> copy paste your js code into www/js/index.js onDeviceReady, changed
> pushServerUrl and variant info and changed quotes to " (this is your
> email
> client no doubt) and changed : into ; after console.log("Success")
>
>
> Attach Safari debugger and send a message when the app is in the
> foreground
> and get in the console:
>
> HandleAeroGearNotification: event =>
> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> I press the home button and send the app to the background send
> another
> message and 'touch' the message to launch the app:
>
> HandleAeroGearNotification: event =>
> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> The I kill the app by pressing home twice and swiping over the app to
> remove it send another message and 'touch' it to launch the app. This
> kills
> my safari debugger so no way to see the console log, but in this case
> coldstart should be true. To test this better changed the code to
> alert
> instead of console:
>
> function HandleAeroGearNotification(event) {
>    alert("HandleAeroGearNotification: event => " + event.coldstart);
>
>    // Stuff cut for clarity
> }
>
> I send another notification 'touch' it to launch the app and see the
> alert
> box display the text:
>
> HandleAeroGearNotification: event => true
>
> Hope this helps
>
>
>
> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
> [hidden email]> wrote:
>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>>  'additionalData' => { 'Disruption_Id' => '107546',
>>                       'EpochTime' => '1450125268'
>>                      },
>>  'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>>  'alias' => [ ‘alias1’ ],
>>  'ttl' => 600
>> };
>>
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>>
>>  var aeroGearPushConfig = {
>>      pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>      ios: {
>>          variantID: “variantid_obscured”,
>>           variantSecret: “variant_secret_obscured”
>>          } ,
>>       android: {
>>              senderID: "variantid_obscured" ,
>>          variantID: "variant_id_obscured" ,
>>          variantSecret: "variant_secret_obscured"
>>       } ,
>>      sendMetricInfo: true,
>>      alias: alias1
>>  };
>>
>>  function HandleAeroGearNotification(event) {
>>      console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>>      // Stuff cut for clarity
>>  }
>>
>>  // Slightly simplified registration event.
>>  push.register(HandleAeroGearNotification , function () {
>>      console.log(“Success”):
>>  } , function () {
>>      console.log(“Failure”);
>>  } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>>
>> Rob
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Sebastien Blanc
In the ionic app when do you do the registration of UPS ? on the platformReady event ? 

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <[hidden email]> wrote:
Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

1. IOS App in foreground, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good

2. IOS App in background, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good

3. IOS App killed, we send a simple push notification from the Aerogear
console and some of the time when we click on the notification in the
notification drawer we do NOT get the notification handler called. Not
so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

> Hi Rob,
>
> That would be a bug, although I can not reproduce it, to test it this
> is
> what I've done to test it:
> $ > cordova create push-test <my bundle id>
> $ > cordova platform add ios
> $ > cordova plugin add aerogear-cordova-push
>
> copy paste your js code into www/js/index.js onDeviceReady, changed
> pushServerUrl and variant info and changed quotes to " (this is your
> email
> client no doubt) and changed : into ; after console.log("Success")
>
>
> Attach Safari debugger and send a message when the app is in the
> foreground
> and get in the console:
>
> HandleAeroGearNotification: event =>
> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> I press the home button and send the app to the background send
> another
> message and 'touch' the message to launch the app:
>
> HandleAeroGearNotification: event =>
> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>
> The I kill the app by pressing home twice and swiping over the app to
> remove it send another message and 'touch' it to launch the app. This
> kills
> my safari debugger so no way to see the console log, but in this case
> coldstart should be true. To test this better changed the code to
> alert
> instead of console:
>
> function HandleAeroGearNotification(event) {
>    alert("HandleAeroGearNotification: event => " + event.coldstart);
>
>    // Stuff cut for clarity
> }
>
> I send another notification 'touch' it to launch the app and see the
> alert
> box display the text:
>
> HandleAeroGearNotification: event => true
>
> Hope this helps
>
>
>
> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
> [hidden email]> wrote:
>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>>  'additionalData' => { 'Disruption_Id' => '107546',
>>                       'EpochTime' => '1450125268'
>>                      },
>>  'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>>  'alias' => [ ‘alias1’ ],
>>  'ttl' => 600
>> };
>>
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>>
>>  var aeroGearPushConfig = {
>>      pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>      ios: {
>>          variantID: “variantid_obscured”,
>>           variantSecret: “variant_secret_obscured”
>>          } ,
>>       android: {
>>              senderID: "variantid_obscured" ,
>>          variantID: "variant_id_obscured" ,
>>          variantSecret: "variant_secret_obscured"
>>       } ,
>>      sendMetricInfo: true,
>>      alias: alias1
>>  };
>>
>>  function HandleAeroGearNotification(event) {
>>      console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>>      // Stuff cut for clarity
>>  }
>>
>>  // Slightly simplified registration event.
>>  push.register(HandleAeroGearNotification , function () {
>>      console.log(“Success”):
>>  } , function () {
>>      console.log(“Failure”);
>>  } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>>
>> Rob
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett

Sebastien

Yes, we do it at that point, $ionicPlatform.ready. I include the whole of that area of code for reference but we’re not expecting you to debug it for us. Merely to demonstrate its there.

At the moment all we want the code to do is put an alert up.

.run(function($ionicPlatform , CordovaService) {
    $ionicPlatform.ready(function() {
        if (window.StatusBar) {
            // org.apache.cordova.statusbar required
            StatusBar.styleDefault();
        }

        ConsoleLog('<<< Cordova ready >>>');

        /* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */
        cordova.plugins.Keyboard.disableScroll(true);

       isDeviceReady = true;

        var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";

        var aeroGearPushConfig = {
            pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
            ios: {
                variantID: “XXXXX”,
                variantSecret: “YYYYYYY”
            } ,
            // sendMetricInfo: true,
            alias: uuid
        };

        push.register(function (event) {
            alert("EVENT = " + JSON.stringify(event));

        } ,  function () {
            if (1)
            {
                // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
                // ConsoleLog("UUID = " + uuid);
            }
        } , function () {
    } , aeroGearPushConfig);

We were still loading up another 18,000 lines of code so we need to start pruning that back until we have something that works.

Rob

On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:

In the ionic app when do you do the registration of UPS ? on the
platformReady event ?

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <[hidden email]

wrote:

Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

  1. IOS App in foreground, we send a simple push notification from the
    Aerogear console - Works OK, We can see the event. Good

  2. IOS App in background, we send a simple push notification from the
    Aerogear console - Works OK, We can see the event. Good

  3. IOS App killed, we send a simple push notification from the Aerogear
    console and some of the time when we click on the notification in the
    notification drawer we do NOT get the notification handler called. Not
    so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

Hi Rob,

That would be a bug, although I can not reproduce it, to test it this
is
what I've done to test it:
$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed
pushServerUrl and variant info and changed quotes to " (this is your
email
client no doubt) and changed : into ; after console.log("Success")

Attach Safari debugger and send a message when the app is in the
foreground
and get in the console:

HandleAeroGearNotification: event =>

{"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send
another
message and 'touch' the message to launch the app:

HandleAeroGearNotification: event =>

{"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to
remove it send another message and 'touch' it to launch the app. This
kills
my safari debugger so no way to see the console log, but in this case
coldstart should be true. To test this better changed the code to
alert
instead of console:

function HandleAeroGearNotification(event) {
alert("HandleAeroGearNotification: event => " + event.coldstart);

// Stuff cut for clarity
}

I send another notification 'touch' it to launch the app and see the
alert
box display the text:

HandleAeroGearNotification: event => true

Hope this helps

On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4
push
plugin specifically on the iOS side.
Summary

We have two versions of our app, an Android and an IOS version. Both
use
the latest Cordova push plugin 2.0.4. They also both have the latest
Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
versions are compiled at the same time. We are running cordova 5.3.3
with
Ionic 1.7.8 (?).

1.

We make sure that both apps are NOT started up on each device. We
also
check they are NOT in the background.
2.

We send the same simple notification to each device. This
notification
config is as below, we have anonymised the variants and alias in this
JSON
structure, though we can report that the UPS server sends the data
correctly. We use the additionalData flag to provide the information
necessary to decide which notification has been clicked in the
notification
drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
'additionalData' => { 'Disruption_Id' => '107546',
'EpochTime' => '1450125268'
},
'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
King William Street - To facilitate a heavy lift in Cannon Street,
Cannon Street will be closed. Traffic is slow moving on diversion.'
},
'alias' => [ ‘alias1’ ],
'ttl' => 600
};

1.

Both devices show the message, the Android device stacks the message
and the iOS device display an individual message. This looks correct.
2.

Clicking on the Android stacked message starts up the app and the
Javascript notification handler we have defined,
HandleAeroGearNotification
is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
(All Directions) at the junction of King William Street - To
facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on

diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon

Street (EC4N) (All Directions) at the junction of King William Street
- To facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on diversion.","badge":"-1"}}

1.

Clicking on the notification in the notification drawer on the iOS
device also starts our app up correctly but the notification handler,
HandleAeroGearNotification(), is NOT called. The app starts up as
normal as
if the notification had not been clicked. We would expect the
notification
handler to be called in iOS as it is in Android.
2.

All notifications are cleared on both Android and iOS correctly when
the app is started up.
3.

We define HandleAeroGearNotification as

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “variantid_obscured”,
variantSecret: “variant_secret_obscured”
} ,
android: {
senderID: "variantid_obscured" ,
variantID: "variant_id_obscured" ,
variantSecret: "variant_secret_obscured"
} ,
sendMetricInfo: true,
alias: alias1
};

function HandleAeroGearNotification(event) {
console.log(“HandleAeroGearNotification: event => “ +
JSON.stringify(event));

// Stuff cut for clarity
}

// Slightly simplified registration event.
push.register(HandleAeroGearNotification , function () {
console.log(“Success”):
} , function () {
console.log(“Failure”);
} , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and
wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Erik Jan de Wit
Hi Rob,

What you could try is to debug this in xcode, when the notification is touched it should launch the app and that will in turn call the JS callback. Would be good to see if this code is called 100% of the time.

You can put a breakpoint here:

That code will execute on cold start and here:

That is where the onNotification callback gets invoked.

Hope this helps,

On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <[hidden email]> wrote:

Sebastien

Yes, we do it at that point, $ionicPlatform.ready. I include the whole of that area of code for reference but we’re not expecting you to debug it for us. Merely to demonstrate its there.

At the moment all we want the code to do is put an alert up.

.run(function($ionicPlatform , CordovaService) {
    $ionicPlatform.ready(function() {
        if (window.StatusBar) {
            // org.apache.cordova.statusbar required
            StatusBar.styleDefault();
        }

        ConsoleLog('<<< Cordova ready >>>');

        /* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */
        cordova.plugins.Keyboard.disableScroll(true);

       isDeviceReady = true;

        var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";

        var aeroGearPushConfig = {
            pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
            ios: {
                variantID: “XXXXX”,
                variantSecret: “YYYYYYY”
            } ,
            // sendMetricInfo: true,
            alias: uuid
        };

        push.register(function (event) {
            alert("EVENT = " + JSON.stringify(event));

        } ,  function () {
            if (1)
            {
                // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
                // ConsoleLog("UUID = " + uuid);
            }
        } , function () {
    } , aeroGearPushConfig);

We were still loading up another 18,000 lines of code so we need to start pruning that back until we have something that works.

Rob

On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:

In the ionic app when do you do the registration of UPS ? on the
platformReady event ?

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <[hidden email]

wrote:

Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

  1. IOS App in foreground, we send a simple push notification from the
    Aerogear console - Works OK, We can see the event. Good

  2. IOS App in background, we send a simple push notification from the
    Aerogear console - Works OK, We can see the event. Good

  3. IOS App killed, we send a simple push notification from the Aerogear


    console and some of the time when we click on the notification in the
    notification drawer we do NOT get the notification handler called. Not
    so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

Hi Rob,

That would be a bug, although I can not reproduce it, to test it this
is
what I've done to test it:
$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed
pushServerUrl and variant info and changed quotes to " (this is your
email
client no doubt) and changed : into ; after console.log("Success")

Attach Safari debugger and send a message when the app is in the
foreground
and get in the console:

HandleAeroGearNotification: event =>

{"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send
another
message and 'touch' the message to launch the app:

HandleAeroGearNotification: event =>

{"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to
remove it send another message and 'touch' it to launch the app. This
kills
my safari debugger so no way to see the console log, but in this case
coldstart should be true. To test this better changed the code to
alert
instead of console:

function HandleAeroGearNotification(event) {
alert("HandleAeroGearNotification: event => " + event.coldstart);

// Stuff cut for clarity
}

I send another notification 'touch' it to launch the app and see the
alert
box display the text:

HandleAeroGearNotification: event => true

Hope this helps

On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4
push
plugin specifically on the iOS side.
Summary

We have two versions of our app, an Android and an IOS version. Both
use
the latest Cordova push plugin 2.0.4. They also both have the latest
Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
versions are compiled at the same time. We are running cordova 5.3.3
with
Ionic 1.7.8 (?).

1.

We make sure that both apps are NOT started up on each device. We
also
check they are NOT in the background.
2.

We send the same simple notification to each device. This
notification
config is as below, we have anonymised the variants and alias in this
JSON
structure, though we can report that the UPS server sends the data
correctly. We use the additionalData flag to provide the information
necessary to decide which notification has been clicked in the
notification
drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
'additionalData' => { 'Disruption_Id' => '107546',
'EpochTime' => '1450125268'
},
'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
King William Street - To facilitate a heavy lift in Cannon Street,
Cannon Street will be closed. Traffic is slow moving on diversion.'
},
'alias' => [ ‘alias1’ ],
'ttl' => 600
};

1.

Both devices show the message, the Android device stacks the message
and the iOS device display an individual message. This looks correct.
2.

Clicking on the Android stacked message starts up the app and the
Javascript notification handler we have defined,
HandleAeroGearNotification
is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
(All Directions) at the junction of King William Street - To
facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on

diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon

Street (EC4N) (All Directions) at the junction of King William Street
- To facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on diversion.","badge":"-1"}}

1.

Clicking on the notification in the notification drawer on the iOS
device also starts our app up correctly but the notification handler,
HandleAeroGearNotification(), is NOT called. The app starts up as
normal as
if the notification had not been clicked. We would expect the
notification
handler to be called in iOS as it is in Android.
2.

All notifications are cleared on both Android and iOS correctly when
the app is started up.
3.

We define HandleAeroGearNotification as

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “variantid_obscured”,
variantSecret: “variant_secret_obscured”
} ,
android: {
senderID: "variantid_obscured" ,
variantID: "variant_id_obscured" ,
variantSecret: "variant_secret_obscured"
} ,
sendMetricInfo: true,
alias: alias1
};

function HandleAeroGearNotification(event) {
console.log(“HandleAeroGearNotification: event => “ +
JSON.stringify(event));

// Stuff cut for clarity
}

// Slightly simplified registration event.
push.register(HandleAeroGearNotification , function () {
console.log(“Success”):
} , function () {
console.log(“Failure”);
} , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and
wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Cheers,
       Erik Jan

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett

Erok,

We’ve not forgotten the notification issue, we’re still working on it to try and get to the bottom of it. The problem for us is that its not so simple to cut code out and try and reduce the problem down. Our code is quite interlinked, for good or for worse.

We’ve added some simple sound debugging to the Objective C source for the Aerogear plugin. This means that we can hear where things are when the plugin starts up from a cold start after receiving a notification. This works quite well.

We initially added a beep to here

- (void)notificationReceived {
    NSLog(@"Notification received");

    AudioServicesPlaySystemSound(1005);


    if (notificationMessage && self.callbackId) {

and this works whenever we get a notification in the foreground and when the app is in the background. We then started tracing backwards in the source code to see what called notificationReceived

We can see it here

- (void)register:(CDVInvokedUrlCommand *)command; {
    NSLog(@"register");
    self.callbackId = command.callbackId;

    AudioServicesPlaySystemSound(1007);

    isInline = NO;

    [self.commandDelegate runInBackground:^{
        NSMutableDictionary *options = [self parseOptions:command];
        [self saveConfig:options];

        // when running under iOS 8 we will use the new API for APNS registration
        #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
            if ([[UIApplication sharedApplication] respondsToSelector:@selector(registerUserNotificationSettings:)]) {
                UIUserNotificationSettings* notificationSettings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound categories:nil];
                [[UIApplication sharedApplication] registerUserNotificationSettings:notificationSettings];
                [[UIApplication sharedApplication] registerForRemoteNotifications];
            } else {
                [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
            }

        #else
            [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
        #endif

        CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_NO_RESULT];
        [pluginResult setKeepCallback:@YES];
        [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId];
    }];

    if (notificationMessage)            // if there is a pending startup notification
    {
        AudioServicesPlaySystemSound(1024);

        [self notificationReceived];    // go ahead and process it
    }
}

So we add some more beeps in to track down whats going on. We add AudioServicesPlaySystemSound(1007) at the beginning of the function and add AudioServicesPlaySystemSound(1024) just before we call the notificationReceived method.

We get the first sounds on startup but do NOT get the second set of sounds. It looks like notificationMessage is not being set at application startup.

Our problem now is that we are not Objective-C developers so we are struggling to debug much further. So trying to understand how notificationMessage is set and defined as its declared as @synthesis is unclear. We’ll start reading and learning quickly but as this is new for us, so we will be slow.

Any suggestions welcomed,

Rob

On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:

Hi Rob,

What you could try is to debug this in xcode, when the notification is
touched it should launch the app and that will in turn call the JS
callback. Would be good to see if this code is called 100% of the time.

You can put a breakpoint here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56

That code will execute on cold start and here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102

That is where the onNotification callback gets invoked.

Hope this helps,

On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <[hidden email]

wrote:

Sebastien

Yes, we do it at that point, $ionicPlatform.ready. I include the whole of
that area of code for reference but we’re not expecting you to debug it for
us. Merely to demonstrate its there.

At the moment all we want the code to do is put an alert up.

.run(function($ionicPlatform , CordovaService) {
$ionicPlatform.ready(function() {
if (window.StatusBar) {
// org.apache.cordova.statusbar required
StatusBar.styleDefault();
}

ConsoleLog('<<< Cordova ready >>>');

/* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */
cordova.plugins.Keyboard.disableScroll(true);

isDeviceReady = true;

var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “XXXXX”,
variantSecret: “YYYYYYY”
} ,
// sendMetricInfo: true,
alias: uuid
};

push.register(function (event) {
alert("EVENT = " + JSON.stringify(event));

} , function () {
if (1)
{
// alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
// ConsoleLog("UUID = " + uuid);
}
} , function () {
} , aeroGearPushConfig);

We were still loading up another 18,000 lines of code so we need to start
pruning that back until we have something that works.

Rob

On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:

In the ionic app when do you do the registration of UPS ? on the
platformReady event ?

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
[hidden email]

wrote:

Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

1.

IOS App in foreground, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
2.

IOS App in background, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
3.

IOS App killed, we send a simple push notification from the Aerogear

console and some of the time when we click on the notification in the
notification drawer we do NOT get the notification handler called. Not
so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

Hi Rob,

That would be a bug, although I can not reproduce it, to test it this
is
what I've done to test it:
$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed
pushServerUrl and variant info and changed quotes to " (this is your
email
client no doubt) and changed : into ; after console.log("Success")

Attach Safari debugger and send a message when the app is in the
foreground
and get in the console:

HandleAeroGearNotification: event =>

{"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send
another
message and 'touch' the message to launch the app:

HandleAeroGearNotification: event =>

{"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to
remove it send another message and 'touch' it to launch the app. This
kills
my safari debugger so no way to see the console log, but in this case
coldstart should be true. To test this better changed the code to
alert
instead of console:

function HandleAeroGearNotification(event) {
alert("HandleAeroGearNotification: event => " + event.coldstart);

// Stuff cut for clarity
}

I send another notification 'touch' it to launch the app and see the
alert
box display the text:

HandleAeroGearNotification: event => true

Hope this helps

On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4
push
plugin specifically on the iOS side.
Summary

We have two versions of our app, an Android and an IOS version. Both
use
the latest Cordova push plugin 2.0.4. They also both have the latest
Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
versions are compiled at the same time. We are running cordova 5.3.3
with
Ionic 1.7.8 (?).

1.

We make sure that both apps are NOT started up on each device. We
also
check they are NOT in the background.
2.

We send the same simple notification to each device. This
notification
config is as below, we have anonymised the variants and alias in this
JSON
structure, though we can report that the UPS server sends the data
correctly. We use the additionalData flag to provide the information
necessary to decide which notification has been clicked in the
notification
drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
'additionalData' => { 'Disruption_Id' => '107546',
'EpochTime' => '1450125268'
},
'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
King William Street - To facilitate a heavy lift in Cannon Street,
Cannon Street will be closed. Traffic is slow moving on diversion.'
},
'alias' => [ ‘alias1’ ],
'ttl' => 600
};

1.

Both devices show the message, the Android device stacks the message
and the iOS device display an individual message. This looks correct.
2.

Clicking on the Android stacked message starts up the app and the
Javascript notification handler we have defined,
HandleAeroGearNotification
is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
(All Directions) at the junction of King William Street - To
facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on

diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon

Street (EC4N) (All Directions) at the junction of King William Street
- To facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on diversion.","badge":"-1"}}

1.

Clicking on the notification in the notification drawer on the iOS
device also starts our app up correctly but the notification handler,
HandleAeroGearNotification(), is NOT called. The app starts up as
normal as
if the notification had not been clicked. We would expect the
notification
handler to be called in iOS as it is in Android.
2.

All notifications are cleared on both Android and iOS correctly when
the app is started up.
3.

We define HandleAeroGearNotification as

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “variantid_obscured”,
variantSecret: “variant_secret_obscured”
} ,
android: {
senderID: "variantid_obscured" ,
variantID: "variant_id_obscured" ,
variantSecret: "variant_secret_obscured"
} ,
sendMetricInfo: true,
alias: alias1
};

function HandleAeroGearNotification(event) {
console.log(“HandleAeroGearNotification: event => “ +
JSON.stringify(event));

// Stuff cut for clarity
}

// Slightly simplified registration event.
push.register(HandleAeroGearNotification , function () {
console.log(“Success”):
} , function () {
console.log(“Failure”);
} , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and
wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,

Erik Jan

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett

Erik, Sebastien,

We’ve spent a significant part of the weekend looking into this issue and we have still not got to the bottom of it.

We have built a very simple Ionic test app that works in isolation. We have used the default Ionic tabs at

http://ionicframework.com/getting-started/

We then add in our Javascript files as <script> entries in the index.html file (shown for example)

    <script src="js/polygon.js"></script>
    <script src="js/urls.js"></script>
    <script src="js/utilities.js"></script>

    <script src="js/moment.js"></script>
    <script src="js/perimeter.js"></script>
    <script src="js/leaflet.markercluster-src.js"></script>
    <script src="js/cycle.js"></script>
    <script src="js/clipper.js"></script>
    <script src="js/easy_button.js"></script>
    <script src="js/graham_scan.js"></script>
    <script src="js/sha.js"></script>
    <script src="js/r-tree.js"></script>
    <script src="js/angular-leaflet-directive.min.js"></script>
    <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
    <script src="pouchdb/pouchdb-5.1.0.min.js"></script>

We do NOT call any functions within any of these files, indeed we make no reference to these files beyond including them in the index.html file. Our dummy html templates make no reference to them. We simply load the javascript files in. We get no errors from including the files. We have used the controllers and services as provided by the dummy sample Ionic app.

If we then send foreground notifications, the notifications are always handled by the Aerogear notification handler.

If we send notifications to the app when it is in the background, the notifications are always handled by the Aerogear notification handler.

If we kill by swiping up the app, we get the notifications but when we click on the notification from the main IOS screen it is arbitrary as to whether the notification is handled by the Aerogear handler when the app starts up. Sometimes the handler is called, but once the handler is not called, the Aerogear notification handler never appears to be called again. If we reinstall the app it sometimes works again and sometimes it fails.

We can reinstall the app and the Aerogear notification handler might be called or it might not. We just ran the app with 20 tests to the app, each time killing the app and then sending down a a notification and it started the Aerogear notification handler each time. We then reinstall the app again, no changes in the code and it simply doesn’t process any notification when the app is closed. The notification turns up, but no event is called to the Aerogear event handler.

Given that we are getting arbitrary results from the same codebase, clearly something is remiss. Sometimes it works and sometimes it doesn’t. There is no logic that we can see. We’ve closed down Xcode after installing, we’ve started and stopped our sample app a few times to try and make sure its closed down, ew are sending exactly the same payload each time.

We feel that there is some sort of timing or race condition, or if this was a piece of C code, that we are overwriting somewhere we shouldn’t be. It has that sort of feeling of a pointer going bad but we cannot see where the issue is at all. The fact that we get different results from doing the same install is very worrying but we can’t say whether its the Aerogear plugin, Ionic or our code.

Thanks,

Rob

On 18 Dec 2015, at 17:26, Rob Willett wrote:

Erok,

We’ve not forgotten the notification issue, we’re still working on it to try and get to the bottom of it. The problem for us is that its not so simple to cut code out and try and reduce the problem down. Our code is quite interlinked, for good or for worse.

We’ve added some simple sound debugging to the Objective C source for the Aerogear plugin. This means that we can hear where things are when the plugin starts up from a cold start after receiving a notification. This works quite well.

We initially added a beep to here

- (void)notificationReceived {
 NSLog(@"Notification received");

 AudioServicesPlaySystemSound(1005);


 if (notificationMessage && self.callbackId) {

and this works whenever we get a notification in the foreground and when the app is in the background. We then started tracing backwards in the source code to see what called notificationReceived

We can see it here

- (void)register:(CDVInvokedUrlCommand *)command; {
 NSLog(@"register");
 self.callbackId = command.callbackId;

 AudioServicesPlaySystemSound(1007);

 isInline = NO;

 [self.commandDelegate runInBackground:^{
     NSMutableDictionary *options = [self parseOptions:command];
     [self saveConfig:options];

     // when running under iOS 8 we will use the new API for APNS registration
     #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
         if ([[UIApplication sharedApplication] respondsToSelector:@selector(registerUserNotificationSettings:)]) {
             UIUserNotificationSettings* notificationSettings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound categories:nil];
             [[UIApplication sharedApplication] registerUserNotificationSettings:notificationSettings];
             [[UIApplication sharedApplication] registerForRemoteNotifications];
         } else {
             [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
         }

     #else
         [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
     #endif

     CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_NO_RESULT];
     [pluginResult setKeepCallback:@YES];
     [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId];
 }];

 if (notificationMessage)            // if there is a pending startup notification
 {
     AudioServicesPlaySystemSound(1024);

     [self notificationReceived];    // go ahead and process it
 }
}

So we add some more beeps in to track down whats going on. We add AudioServicesPlaySystemSound(1007) at the beginning of the function and add AudioServicesPlaySystemSound(1024) just before we call the notificationReceived method.

We get the first sounds on startup but do NOT get the second set of sounds. It looks like notificationMessage is not being set at application startup.

Our problem now is that we are not Objective-C developers so we are struggling to debug much further. So trying to understand how notificationMessage is set and defined as its declared as @synthesis is unclear. We’ll start reading and learning quickly but as this is new for us, so we will be slow.

Any suggestions welcomed,

Rob

On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:

Hi Rob,

What you could try is to debug this in xcode, when the notification is
touched it should launch the app and that will in turn call the JS
callback. Would be good to see if this code is called 100% of the time.

You can put a breakpoint here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56

That code will execute on cold start and here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102

That is where the onNotification callback gets invoked.

Hope this helps,

On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <[hidden email]

wrote:

Sebastien

Yes, we do it at that point, $ionicPlatform.ready. I include the whole of
that area of code for reference but we’re not expecting you to debug it for
us. Merely to demonstrate its there.

At the moment all we want the code to do is put an alert up.

.run(function($ionicPlatform , CordovaService) {
$ionicPlatform.ready(function() {
if (window.StatusBar) {
// org.apache.cordova.statusbar required
StatusBar.styleDefault();
}

ConsoleLog('<<< Cordova ready >>>');

/* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */
cordova.plugins.Keyboard.disableScroll(true);

isDeviceReady = true;

var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “XXXXX”,
variantSecret: “YYYYYYY”
} ,
// sendMetricInfo: true,
alias: uuid
};

push.register(function (event) {
alert("EVENT = " + JSON.stringify(event));

} , function () {
if (1)
{
// alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
// ConsoleLog("UUID = " + uuid);
}
} , function () {
} , aeroGearPushConfig);

We were still loading up another 18,000 lines of code so we need to start
pruning that back until we have something that works.

Rob

On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:

In the ionic app when do you do the registration of UPS ? on the
platformReady event ?

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
[hidden email]

wrote:

Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

1.

IOS App in foreground, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
2.

IOS App in background, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
3.

IOS App killed, we send a simple push notification from the Aerogear

console and some of the time when we click on the notification in the
notification drawer we do NOT get the notification handler called. Not
so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

Hi Rob,

That would be a bug, although I can not reproduce it, to test it this
is
what I've done to test it:
$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed
pushServerUrl and variant info and changed quotes to " (this is your
email
client no doubt) and changed : into ; after console.log("Success")

Attach Safari debugger and send a message when the app is in the
foreground
and get in the console:

HandleAeroGearNotification: event =>

{"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send
another
message and 'touch' the message to launch the app:

HandleAeroGearNotification: event =>

{"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to
remove it send another message and 'touch' it to launch the app. This
kills
my safari debugger so no way to see the console log, but in this case
coldstart should be true. To test this better changed the code to
alert
instead of console:

function HandleAeroGearNotification(event) {
alert("HandleAeroGearNotification: event => " + event.coldstart);

// Stuff cut for clarity
}

I send another notification 'touch' it to launch the app and see the
alert
box display the text:

HandleAeroGearNotification: event => true

Hope this helps

On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4
push
plugin specifically on the iOS side.
Summary

We have two versions of our app, an Android and an IOS version. Both
use
the latest Cordova push plugin 2.0.4. They also both have the latest
Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
versions are compiled at the same time. We are running cordova 5.3.3
with
Ionic 1.7.8 (?).

1.

We make sure that both apps are NOT started up on each device. We
also
check they are NOT in the background.
2.

We send the same simple notification to each device. This
notification
config is as below, we have anonymised the variants and alias in this
JSON
structure, though we can report that the UPS server sends the data
correctly. We use the additionalData flag to provide the information
necessary to decide which notification has been clicked in the
notification
drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
'additionalData' => { 'Disruption_Id' => '107546',
'EpochTime' => '1450125268'
},
'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
King William Street - To facilitate a heavy lift in Cannon Street,
Cannon Street will be closed. Traffic is slow moving on diversion.'
},
'alias' => [ ‘alias1’ ],
'ttl' => 600
};

1.

Both devices show the message, the Android device stacks the message
and the iOS device display an individual message. This looks correct.
2.

Clicking on the Android stacked message starts up the app and the
Javascript notification handler we have defined,
HandleAeroGearNotification
is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
(All Directions) at the junction of King William Street - To
facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on

diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon

Street (EC4N) (All Directions) at the junction of King William Street
- To facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on diversion.","badge":"-1"}}

1.

Clicking on the notification in the notification drawer on the iOS
device also starts our app up correctly but the notification handler,
HandleAeroGearNotification(), is NOT called. The app starts up as
normal as
if the notification had not been clicked. We would expect the
notification
handler to be called in iOS as it is in Android.
2.

All notifications are cleared on both Android and iOS correctly when
the app is started up.
3.

We define HandleAeroGearNotification as

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “variantid_obscured”,
variantSecret: “variant_secret_obscured”
} ,
android: {
senderID: "variantid_obscured" ,
variantID: "variant_id_obscured" ,
variantSecret: "variant_secret_obscured"
} ,
sendMetricInfo: true,
alias: alias1
};

function HandleAeroGearNotification(event) {
console.log(“HandleAeroGearNotification: event => “ +
JSON.stringify(event));

// Stuff cut for clarity
}

// Slightly simplified registration event.
push.register(HandleAeroGearNotification , function () {
console.log(“Success”):
} , function () {
console.log(“Failure”);
} , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and
wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,

Erik Jan

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett

Dear all,

We think we can now reproduce the problem. Clearly writing the last e-mail has focussed our attention :)

Summary.

We have a simple Ionic app that would call the Aerogear notification handler when notifications were receive in the foreground and when the app was in the background. The Aerogear notification handler would sometimes be called and sometimes NOT be called when a notification was received when the app was not started. See our long previous e-mails detailing the problem.

We think we can now reproduce the problem as follows:

  1. Kill the app.

  2. Send a notification down to the app.

  3. It appears in the iOS notification drawer

  4. Click on the notification. if the Aerogear handler has worked then go to 1 and repeat. We want a failure :)

  5. If the Aerogear handler is NOT called, then put the app into the background using the Home button and then click on the app icon to resume.

  6. The notification is now processed by the Aerogear handler. We can now see it.

We are at a loss to explain this, we found it by accident, but we think it shows some sort of timing issue somewhere because if we pull out the various Javascript files the Aerogear plugin seems to work consistently at startup. We have checked and checked the JavaScript files and cannot see any error with them at all at load time.

All suggestions welcome now.

Rob

On 20 Dec 2015, at 19:26, Rob Willett wrote:

Erik, Sebastien,

We’ve spent a significant part of the weekend looking into this issue and we have still not got to the bottom of it.

We have built a very simple Ionic test app that works in isolation. We have used the default Ionic tabs at

http://ionicframework.com/getting-started/

We then add in our Javascript files as <script> entries in the index.html file (shown for example)

 <script src="js/polygon.js"></script>
 <script src="js/urls.js"></script>
 <script src="js/utilities.js"></script>

 <script src="js/moment.js"></script>
 <script src="js/perimeter.js"></script>
 <script src="js/leaflet.markercluster-src.js"></script>
 <script src="js/cycle.js"></script>
 <script src="js/clipper.js"></script>
 <script src="js/easy_button.js"></script>
 <script src="js/graham_scan.js"></script>
 <script src="js/sha.js"></script>
 <script src="js/r-tree.js"></script>
 <script src="js/angular-leaflet-directive.min.js"></script>
 <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
 <script src="pouchdb/pouchdb-5.1.0.min.js"></script>

We do NOT call any functions within any of these files, indeed we make no reference to these files beyond including them in the index.html file. Our dummy html templates make no reference to them. We simply load the javascript files in. We get no errors from including the files. We have used the controllers and services as provided by the dummy sample Ionic app.

If we then send foreground notifications, the notifications are always handled by the Aerogear notification handler.

If we send notifications to the app when it is in the background, the notifications are always handled by the Aerogear notification handler.

If we kill by swiping up the app, we get the notifications but when we click on the notification from the main IOS screen it is arbitrary as to whether the notification is handled by the Aerogear handler when the app starts up. Sometimes the handler is called, but once the handler is not called, the Aerogear notification handler never appears to be called again. If we reinstall the app it sometimes works again and sometimes it fails.

We can reinstall the app and the Aerogear notification handler might be called or it might not. We just ran the app with 20 tests to the app, each time killing the app and then sending down a a notification and it started the Aerogear notification handler each time. We then reinstall the app again, no changes in the code and it simply doesn’t process any notification when the app is closed. The notification turns up, but no event is called to the Aerogear event handler.

Given that we are getting arbitrary results from the same codebase, clearly something is remiss. Sometimes it works and sometimes it doesn’t. There is no logic that we can see. We’ve closed down Xcode after installing, we’ve started and stopped our sample app a few times to try and make sure its closed down, ew are sending exactly the same payload each time.

We feel that there is some sort of timing or race condition, or if this was a piece of C code, that we are overwriting somewhere we shouldn’t be. It has that sort of feeling of a pointer going bad but we cannot see where the issue is at all. The fact that we get different results from doing the same install is very worrying but we can’t say whether its the Aerogear plugin, Ionic or our code.

Thanks,

Rob

On 18 Dec 2015, at 17:26, Rob Willett wrote:

Erok,

We’ve not forgotten the notification issue, we’re still working on it to try and get to the bottom of it. The problem for us is that its not so simple to cut code out and try and reduce the problem down. Our code is quite interlinked, for good or for worse.

We’ve added some simple sound debugging to the Objective C source for the Aerogear plugin. This means that we can hear where things are when the plugin starts up from a cold start after receiving a notification. This works quite well.

We initially added a beep to here

- (void)notificationReceived {
NSLog(@"Notification received");

AudioServicesPlaySystemSound(1005);


if (notificationMessage && self.callbackId) {

and this works whenever we get a notification in the foreground and when the app is in the background. We then started tracing backwards in the source code to see what called notificationReceived

We can see it here

- (void)register:(CDVInvokedUrlCommand *)command; {
NSLog(@"register");
self.callbackId = command.callbackId;

AudioServicesPlaySystemSound(1007);

isInline = NO;

[self.commandDelegate runInBackground:^{
 NSMutableDictionary *options = [self parseOptions:command];
 [self saveConfig:options];

 // when running under iOS 8 we will use the new API for APNS registration
 #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
     if ([[UIApplication sharedApplication] respondsToSelector:@selector(registerUserNotificationSettings:)]) {
         UIUserNotificationSettings* notificationSettings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound categories:nil];
         [[UIApplication sharedApplication] registerUserNotificationSettings:notificationSettings];
         [[UIApplication sharedApplication] registerForRemoteNotifications];
     } else {
         [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
     }

 #else
     [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
 #endif

 CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_NO_RESULT];
 [pluginResult setKeepCallback:@YES];
 [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId];
}];

if (notificationMessage)            // if there is a pending startup notification
{
 AudioServicesPlaySystemSound(1024);

 [self notificationReceived];    // go ahead and process it
}
}

So we add some more beeps in to track down whats going on. We add AudioServicesPlaySystemSound(1007) at the beginning of the function and add AudioServicesPlaySystemSound(1024) just before we call the notificationReceived method.

We get the first sounds on startup but do NOT get the second set of sounds. It looks like notificationMessage is not being set at application startup.

Our problem now is that we are not Objective-C developers so we are struggling to debug much further. So trying to understand how notificationMessage is set and defined as its declared as @synthesis is unclear. We’ll start reading and learning quickly but as this is new for us, so we will be slow.

Any suggestions welcomed,

Rob

On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:

Hi Rob,

What you could try is to debug this in xcode, when the notification is
touched it should launch the app and that will in turn call the JS
callback. Would be good to see if this code is called 100% of the time.

You can put a breakpoint here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56

That code will execute on cold start and here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102

That is where the onNotification callback gets invoked.

Hope this helps,

On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <[hidden email]

wrote:

Sebastien

Yes, we do it at that point, $ionicPlatform.ready. I include the whole of
that area of code for reference but we’re not expecting you to debug it for
us. Merely to demonstrate its there.

At the moment all we want the code to do is put an alert up.

.run(function($ionicPlatform , CordovaService) {
$ionicPlatform.ready(function() {
if (window.StatusBar) {
// org.apache.cordova.statusbar required
StatusBar.styleDefault();
}

ConsoleLog('<<< Cordova ready >>>');

/* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */
cordova.plugins.Keyboard.disableScroll(true);

isDeviceReady = true;

var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “XXXXX”,
variantSecret: “YYYYYYY”
} ,
// sendMetricInfo: true,
alias: uuid
};

push.register(function (event) {
alert("EVENT = " + JSON.stringify(event));

} , function () {
if (1)
{
// alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
// ConsoleLog("UUID = " + uuid);
}
} , function () {
} , aeroGearPushConfig);

We were still loading up another 18,000 lines of code so we need to start
pruning that back until we have something that works.

Rob

On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:

In the ionic app when do you do the registration of UPS ? on the
platformReady event ?

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
[hidden email]

wrote:

Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

1.

IOS App in foreground, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
2.

IOS App in background, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
3.

IOS App killed, we send a simple push notification from the Aerogear

console and some of the time when we click on the notification in the
notification drawer we do NOT get the notification handler called. Not
so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

Hi Rob,

That would be a bug, although I can not reproduce it, to test it this
is
what I've done to test it:
$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed
pushServerUrl and variant info and changed quotes to " (this is your
email
client no doubt) and changed : into ; after console.log("Success")

Attach Safari debugger and send a message when the app is in the
foreground
and get in the console:

HandleAeroGearNotification: event =>

{"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send
another
message and 'touch' the message to launch the app:

HandleAeroGearNotification: event =>

{"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to
remove it send another message and 'touch' it to launch the app. This
kills
my safari debugger so no way to see the console log, but in this case
coldstart should be true. To test this better changed the code to
alert
instead of console:

function HandleAeroGearNotification(event) {
alert("HandleAeroGearNotification: event => " + event.coldstart);

// Stuff cut for clarity
}

I send another notification 'touch' it to launch the app and see the
alert
box display the text:

HandleAeroGearNotification: event => true

Hope this helps

On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4
push
plugin specifically on the iOS side.
Summary

We have two versions of our app, an Android and an IOS version. Both
use
the latest Cordova push plugin 2.0.4. They also both have the latest
Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
versions are compiled at the same time. We are running cordova 5.3.3
with
Ionic 1.7.8 (?).

1.

We make sure that both apps are NOT started up on each device. We
also
check they are NOT in the background.
2.

We send the same simple notification to each device. This
notification
config is as below, we have anonymised the variants and alias in this
JSON
structure, though we can report that the UPS server sends the data
correctly. We use the additionalData flag to provide the information
necessary to decide which notification has been clicked in the
notification
drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
'additionalData' => { 'Disruption_Id' => '107546',
'EpochTime' => '1450125268'
},
'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
King William Street - To facilitate a heavy lift in Cannon Street,
Cannon Street will be closed. Traffic is slow moving on diversion.'
},
'alias' => [ ‘alias1’ ],
'ttl' => 600
};

1.

Both devices show the message, the Android device stacks the message
and the iOS device display an individual message. This looks correct.
2.

Clicking on the Android stacked message starts up the app and the
Javascript notification handler we have defined,
HandleAeroGearNotification
is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
(All Directions) at the junction of King William Street - To
facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on

diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon

Street (EC4N) (All Directions) at the junction of King William Street
- To facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on diversion.","badge":"-1"}}

1.

Clicking on the notification in the notification drawer on the iOS
device also starts our app up correctly but the notification handler,
HandleAeroGearNotification(), is NOT called. The app starts up as
normal as
if the notification had not been clicked. We would expect the
notification
handler to be called in iOS as it is in Android.
2.

All notifications are cleared on both Android and iOS correctly when
the app is started up.
3.

We define HandleAeroGearNotification as

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “variantid_obscured”,
variantSecret: “variant_secret_obscured”
} ,
android: {
senderID: "variantid_obscured" ,
variantID: "variant_id_obscured" ,
variantSecret: "variant_secret_obscured"
} ,
sendMetricInfo: true,
alias: alias1
};

function HandleAeroGearNotification(event) {
console.log(“HandleAeroGearNotification: event => “ +
JSON.stringify(event));

// Stuff cut for clarity
}

// Slightly simplified registration event.
push.register(HandleAeroGearNotification , function () {
console.log(“Success”):
} , function () {
console.log(“Failure”);
} , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and
wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,

Erik Jan

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Erik Jan de Wit
Seems to be an cordova issue, when loading a lot of javascript makes the plugin skip init, are there warnings in the log about this?

On Sun, Dec 20, 2015 at 8:52 PM, Rob Willett <[hidden email]> wrote:

Dear all,

We think we can now reproduce the problem. Clearly writing the last e-mail has focussed our attention :)

Summary.

We have a simple Ionic app that would call the Aerogear notification handler when notifications were receive in the foreground and when the app was in the background. The Aerogear notification handler would sometimes be called and sometimes NOT be called when a notification was received when the app was not started. See our long previous e-mails detailing the problem.

We think we can now reproduce the problem as follows:

  1. Kill the app.

  2. Send a notification down to the app.

  3. It appears in the iOS notification drawer

  4. Click on the notification. if the Aerogear handler has worked then go to 1 and repeat. We want a failure :)

  5. If the Aerogear handler is NOT called, then put the app into the background using the Home button and then click on the app icon to resume.

  6. The notification is now processed by the Aerogear handler. We can now see it.

We are at a loss to explain this, we found it by accident, but we think it shows some sort of timing issue somewhere because if we pull out the various Javascript files the Aerogear plugin seems to work consistently at startup. We have checked and checked the JavaScript files and cannot see any error with them at all at load time.

All suggestions welcome now.

Rob

On 20 Dec 2015, at 19:26, Rob Willett wrote:

Erik, Sebastien,

We’ve spent a significant part of the weekend looking into this issue and we have still not got to the bottom of it.

We have built a very simple Ionic test app that works in isolation. We have used the default Ionic tabs at

http://ionicframework.com/getting-started/

We then add in our Javascript files as <script> entries in the index.html file (shown for example)

 <script src="js/polygon.js"></script>
 <script src="js/urls.js"></script>
 <script src="js/utilities.js"></script>

 <script src="js/moment.js"></script>
 <script src="js/perimeter.js"></script>
 <script src="js/leaflet.markercluster-src.js"></script>
 <script src="js/cycle.js"></script>
 <script src="js/clipper.js"></script>
 <script src="js/easy_button.js"></script>
 <script src="js/graham_scan.js"></script>
 <script src="js/sha.js"></script>
 <script src="js/r-tree.js"></script>
 <script src="js/angular-leaflet-directive.min.js"></script>
 <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
 <script src="pouchdb/pouchdb-5.1.0.min.js"></script>

We do NOT call any functions within any of these files, indeed we make no reference to these files beyond including them in the index.html file. Our dummy html templates make no reference to them. We simply load the javascript files in. We get no errors from including the files. We have used the controllers and services as provided by the dummy sample Ionic app.

If we then send foreground notifications, the notifications are always handled by the Aerogear notification handler.

If we send notifications to the app when it is in the background, the notifications are always handled by the Aerogear notification handler.

If we kill by swiping up the app, we get the notifications but when we click on the notification from the main IOS screen it is arbitrary as to whether the notification is handled by the Aerogear handler when the app starts up. Sometimes the handler is called, but once the handler is not called, the Aerogear notification handler never appears to be called again. If we reinstall the app it sometimes works again and sometimes it fails.

We can reinstall the app and the Aerogear notification handler might be called or it might not. We just ran the app with 20 tests to the app, each time killing the app and then sending down a a notification and it started the Aerogear notification handler each time. We then reinstall the app again, no changes in the code and it simply doesn’t process any notification when the app is closed. The notification turns up, but no event is called to the Aerogear event handler.

Given that we are getting arbitrary results from the same codebase, clearly something is remiss. Sometimes it works and sometimes it doesn’t. There is no logic that we can see. We’ve closed down Xcode after installing, we’ve started and stopped our sample app a few times to try and make sure its closed down, ew are sending exactly the same payload each time.

We feel that there is some sort of timing or race condition, or if this was a piece of C code, that we are overwriting somewhere we shouldn’t be. It has that sort of feeling of a pointer going bad but we cannot see where the issue is at all. The fact that we get different results from doing the same install is very worrying but we can’t say whether its the Aerogear plugin, Ionic or our code.

Thanks,

Rob

On 18 Dec 2015, at 17:26, Rob Willett wrote:

Erok,

We’ve not forgotten the notification issue, we’re still working on it to try and get to the bottom of it. The problem for us is that its not so simple to cut code out and try and reduce the problem down. Our code is quite interlinked, for good or for worse.

We’ve added some simple sound debugging to the Objective C source for the Aerogear plugin. This means that we can hear where things are when the plugin starts up from a cold start after receiving a notification. This works quite well.

We initially added a beep to here

- (void)notificationReceived {
NSLog(@"Notification received");

AudioServicesPlaySystemSound(1005);


if (notificationMessage && self.callbackId) {

and this works whenever we get a notification in the foreground and when the app is in the background. We then started tracing backwards in the source code to see what called notificationReceived

We can see it here

- (void)register:(CDVInvokedUrlCommand *)command; {
NSLog(@"register");
self.callbackId = command.callbackId;

AudioServicesPlaySystemSound(1007);

isInline = NO;

[self.commandDelegate runInBackground:^{
 NSMutableDictionary *options = [self parseOptions:command];
 [self saveConfig:options];

 // when running under iOS 8 we will use the new API for APNS registration
 #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
     if ([[UIApplication sharedApplication] respondsToSelector:@selector(registerUserNotificationSettings:)]) {
         UIUserNotificationSettings* notificationSettings = [UIUserNotificationSettings settingsForTypes:UIUserNotificationTypeAlert | UIUserNotificationTypeBadge | UIUserNotificationTypeSound categories:nil];
         [[UIApplication sharedApplication] registerUserNotificationSettings:notificationSettings];
         [[UIApplication sharedApplication] registerForRemoteNotifications];
     } else {
         [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
     }

 #else
     [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
 #endif

 CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_NO_RESULT];
 [pluginResult setKeepCallback:@YES];
 [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId];
}];

if (notificationMessage)            // if there is a pending startup notification
{
 AudioServicesPlaySystemSound(1024);

 [self notificationReceived];    // go ahead and process it
}
}

So we add some more beeps in to track down whats going on. We add AudioServicesPlaySystemSound(1007) at the beginning of the function and add AudioServicesPlaySystemSound(1024) just before we call the notificationReceived method.

We get the first sounds on startup but do NOT get the second set of sounds. It looks like notificationMessage is not being set at application startup.

Our problem now is that we are not Objective-C developers so we are struggling to debug much further. So trying to understand how notificationMessage is set and defined as its declared as @synthesis is unclear. We’ll start reading and learning quickly but as this is new for us, so we will be slow.

Any suggestions welcomed,

Rob

On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:

Hi Rob,

What you could try is to debug this in xcode, when the notification is
touched it should launch the app and that will in turn call the JS
callback. Would be good to see if this code is called 100% of the time.

You can put a breakpoint here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56

That code will execute on cold start and here:
https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102

That is where the onNotification callback gets invoked.

Hope this helps,

On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <[hidden email]

wrote:

Sebastien

Yes, we do it at that point, $ionicPlatform.ready. I include the whole of
that area of code for reference but we’re not expecting you to debug it for
us. Merely to demonstrate its there.

At the moment all we want the code to do is put an alert up.

.run(function($ionicPlatform , CordovaService) {
$ionicPlatform.ready(function() {
if (window.StatusBar) {
// org.apache.cordova.statusbar required
StatusBar.styleDefault();
}

ConsoleLog('<<< Cordova ready >>>');

/* This seems to remove an annoying page flicker on iOS when the keyboard is displayed */
cordova.plugins.Keyboard.disableScroll(true);

isDeviceReady = true;

var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “XXXXX”,
variantSecret: “YYYYYYY”
} ,
// sendMetricInfo: true,
alias: uuid
};

push.register(function (event) {
alert("EVENT = " + JSON.stringify(event));

} , function () {
if (1)
{
// alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
// ConsoleLog("UUID = " + uuid);
}
} , function () {
} , aeroGearPushConfig);

We were still loading up another 18,000 lines of code so we need to start
pruning that back until we have something that works.

Rob

On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:

In the ionic app when do you do the registration of UPS ? on the
platformReady event ?

On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
[hidden email]

wrote:

Erik,

We have built the simplest possible app we can that uses the Aerogear
push plugin but using the ionic tabs starter kit.

http://ionicframework.com/getting-started/

We have taken the code directly from the Cordova simple app that we have
got working and put it into the Ionic app.

if we follow your tests as below:

1.

IOS App in foreground, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
2.

IOS App in background, we send a simple push notification from the
Aerogear console - Works OK, We can see the event. Good
3.

IOS App killed, we send a simple push notification from the Aerogear

console and some of the time when we click on the notification in the
notification drawer we do NOT get the notification handler called. Not
so good

However it does appear to work most of the time with our minimal Ionic
app, but some of the time it fails. We had a run of 1 in 2 failures when
we click on the notification. Now we have just done 20 runs in a row,
each time killing the app after receiving the notification and not a
single failure. Nothing changed.

We cannot find any obvious reason for this so we are still
investigating.

We have reconfigured our main app to work the same way as the minimal
app but we are still getting the same issues as before, we can see the
notification in the drawer but clicking on it does NOT call the same
handler with the same code as the minimal app. We get zero calls to the
notification event handler.

We are wondering if there is a timing issue somewhere in our code, but
we can’t see it. We also wondered if the size of the code we are
loading is the cause of a timing issue as well.

Is there any way of adding more debugging into the Aerogear push plugin
to see if we can track things down that way?

Its very frustrating, but thanks for your help to date. It does look
like its an interaction with our code, Ionic and the Aerogear plugin. My
money is on our code though. We’ll now start pulling working code out
of our app until we get back to the minimal app. Only 18,604 lines to go
:)

Rob

On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:

Hi Rob,

That would be a bug, although I can not reproduce it, to test it this
is
what I've done to test it:
$ > cordova create push-test <my bundle id>
$ > cordova platform add ios
$ > cordova plugin add aerogear-cordova-push

copy paste your js code into www/js/index.js onDeviceReady, changed
pushServerUrl and variant info and changed quotes to " (this is your
email
client no doubt) and changed : into ; after console.log("Success")

Attach Safari debugger and send a message when the app is in the
foreground
and get in the console:

HandleAeroGearNotification: event =>

{"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

I press the home button and send the app to the background send
another
message and 'touch' the message to launch the app:

HandleAeroGearNotification: event =>

{"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}

The I kill the app by pressing home twice and swiping over the app to
remove it send another message and 'touch' it to launch the app. This
kills
my safari debugger so no way to see the console log, but in this case
coldstart should be true. To test this better changed the code to
alert
instead of console:

function HandleAeroGearNotification(event) {
alert("HandleAeroGearNotification: event => " + event.coldstart);

// Stuff cut for clarity
}

I send another notification 'touch' it to launch the app and see the
alert
box display the text:

HandleAeroGearNotification: event => true

Hope this helps

On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
[hidden email]> wrote:

Hi,

We think we have found a possible bug in the Aerogear Cordova 2.0.4
push
plugin specifically on the iOS side.
Summary

We have two versions of our app, an Android and an IOS version. Both
use
the latest Cordova push plugin 2.0.4. They also both have the latest
Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
versions are compiled at the same time. We are running cordova 5.3.3
with
Ionic 1.7.8 (?).

1.

We make sure that both apps are NOT started up on each device. We
also
check they are NOT in the background.
2.

We send the same simple notification to each device. This
notification
config is as below, we have anonymised the variants and alias in this
JSON
structure, though we can report that the UPS server sends the data
correctly. We use the additionalData flag to provide the information
necessary to decide which notification has been clicked in the
notification
drawer.

'variants' => [‘variant1’,’variant2’ ],
'message' => {
'additionalData' => { 'Disruption_Id' => '107546',
'EpochTime' => '1450125268'
},
'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
King William Street - To facilitate a heavy lift in Cannon Street,
Cannon Street will be closed. Traffic is slow moving on diversion.'
},
'alias' => [ ‘alias1’ ],
'ttl' => 600
};

1.

Both devices show the message, the Android device stacks the message
and the iOS device display an individual message. This looks correct.
2.

Clicking on the Android stacked message starts up the app and the
Javascript notification handler we have defined,
HandleAeroGearNotification
is called

HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
(All Directions) at the junction of King William Street - To
facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on

diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon

Street (EC4N) (All Directions) at the junction of King William Street
- To facilitate a heavy lift in Cannon Street, Cannon Street will be
closed. Traffic is slow moving on diversion.","badge":"-1"}}

1.

Clicking on the notification in the notification drawer on the iOS
device also starts our app up correctly but the notification handler,
HandleAeroGearNotification(), is NOT called. The app starts up as
normal as
if the notification had not been clicked. We would expect the
notification
handler to be called in iOS as it is in Android.
2.

All notifications are cleared on both Android and iOS correctly when
the app is started up.
3.

We define HandleAeroGearNotification as

var aeroGearPushConfig = {
pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
ios: {
variantID: “variantid_obscured”,
variantSecret: “variant_secret_obscured”
} ,
android: {
senderID: "variantid_obscured" ,
variantID: "variant_id_obscured" ,
variantSecret: "variant_secret_obscured"
} ,
sendMetricInfo: true,
alias: alias1
};

function HandleAeroGearNotification(event) {
console.log(“HandleAeroGearNotification: event => “ +
JSON.stringify(event));

// Stuff cut for clarity
}

// Slightly simplified registration event.
push.register(HandleAeroGearNotification , function () {
console.log(“Success”):
} , function () {
console.log(“Failure”);
} , aeroGearPushConfig);

We cannot see any reference to this issue in the JIRA database and
wondered if it is a bug or not.

If its a bug we are happy to raise it accordingly.

Please let us know,

Thanks

Rob

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,

Erik Jan

Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Cheers,
       Erik Jan

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett
Erik,

No there are no warnings or any any errors. Errors and warnings we can
work with, this simply didn’t fire.

At the moment we have got around the issue with a different plugin. We
didn’t change the architecture at all and the different plugin works.

At the time we thought it was a timing or race condition and we still
think that.

We have this on the backburner as we need to get a release out. We’ll
try and revisit it later but it won’t be for a few weeks as Twitter
interfaces, GPS maps and route matching is on the critical path :)

Thanks

Rob

On 13 Jan 2016, at 9:43, Erik Jan de Wit wrote:

> Seems to be an cordova issue, when loading a lot of javascript makes
> the
> plugin skip init, are there warnings in the log about this?
>
> On Sun, Dec 20, 2015 at 8:52 PM, Rob Willett
> <[hidden email]
>> wrote:
>
>> Dear all,
>>
>> We *think* we can now reproduce the problem. Clearly writing the last
>> e-mail has focussed our attention :)
>>
>> Summary.
>>
>> We have a simple Ionic app that would call the Aerogear notification
>> handler when notifications were receive in the foreground and when
>> the app
>> was in the background. The Aerogear notification handler would
>> sometimes be
>> called and sometimes NOT be called when a notification was received
>> when
>> the app was not started. See our long previous e-mails detailing the
>> problem.
>>
>> We think we can now reproduce the problem as follows:
>>
>> 1.
>>
>> Kill the app.
>> 2.
>>
>> Send a notification down to the app.
>> 3.
>>
>> It appears in the iOS notification drawer
>> 4.
>>
>> Click on the notification. if the Aerogear handler has worked then go
>> to 1 and repeat. We want a failure :)
>> 5.
>>
>> If the Aerogear handler is NOT called, then put the app into the
>> background using the Home button and then click on the app icon to
>> resume.
>> 6.
>>
>> The notification is now processed by the Aerogear handler. We can now
>> see it.
>>
>> We are at a loss to explain this, we found it by accident, but we
>> think it
>> shows some sort of timing issue somewhere because if we pull out the
>> various Javascript files the Aerogear plugin seems to work
>> consistently at
>> startup. We have checked and checked the JavaScript files and cannot
>> see
>> any error with them at all at load time.
>>
>> All suggestions welcome now.
>>
>> Rob
>>
>> On 20 Dec 2015, at 19:26, Rob Willett wrote:
>>
>> Erik, Sebastien,
>>
>> We’ve spent a significant part of the weekend looking into this
>> issue and
>> we have still not got to the bottom of it.
>>
>> We have built a very simple Ionic test app that works in isolation.
>> We
>> have used the default Ionic tabs at
>>
>> http://ionicframework.com/getting-started/
>>
>> We then add in our Javascript files as <script> entries in the
>> index.html
>> file (shown for example)
>>
>> <script src="js/polygon.js"></script>
>> <script src="js/urls.js"></script>
>> <script src="js/utilities.js"></script>
>>
>> <script src="js/moment.js"></script>
>> <script src="js/perimeter.js"></script>
>> <script src="js/leaflet.markercluster-src.js"></script>
>> <script src="js/cycle.js"></script>
>> <script src="js/clipper.js"></script>
>> <script src="js/easy_button.js"></script>
>> <script src="js/graham_scan.js"></script>
>> <script src="js/sha.js"></script>
>> <script src="js/r-tree.js"></script>
>> <script src="js/angular-leaflet-directive.min.js"></script>
>> <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
>> <script src="pouchdb/pouchdb-5.1.0.min.js"></script>
>>
>> We do NOT call any functions within any of these files, indeed we
>> make no
>> reference to these files beyond including them in the index.html
>> file. Our
>> dummy html templates make no reference to them. We simply load the
>> javascript files in. We get no errors from including the files. We
>> have
>> used the controllers and services as provided by the dummy sample
>> Ionic app.
>>
>> If we then send foreground notifications, the notifications are
>> always
>> handled by the Aerogear notification handler.
>>
>> If we send notifications to the app when it is in the background, the
>> notifications are always handled by the Aerogear notification
>> handler.
>>
>> If we kill by swiping up the app, we get the notifications but when
>> we
>> click on the notification from the main IOS screen it is arbitrary as
>> to
>> whether the notification is handled by the Aerogear handler when the
>> app
>> starts up. Sometimes the handler is called, but once the handler is
>> not
>> called, the Aerogear notification handler never appears to be called
>> again.
>> If we reinstall the app it sometimes works again and sometimes it
>> fails.
>>
>> We can reinstall the app and the Aerogear notification handler might
>> be
>> called or it might not. We just ran the app with 20 tests to the app,
>> each
>> time killing the app and then sending down a a notification and it
>> started
>> the Aerogear notification handler each time. We then reinstall the
>> app
>> again, no changes in the code and it simply doesn’t process any
>> notification when the app is closed. The notification turns up, but
>> no
>> event is called to the Aerogear event handler.
>>
>> Given that we are getting arbitrary results from the same codebase,
>> clearly something is remiss. Sometimes it works and sometimes it
>> doesn’t.
>> There is no logic that we can see. We’ve closed down Xcode after
>> installing, we’ve started and stopped our sample app a few times to
>> try and
>> make sure its closed down, ew are sending exactly the same payload
>> each
>> time.
>>
>> We feel that there is some sort of timing or race condition, or if
>> this
>> was a piece of C code, that we are overwriting somewhere we
>> shouldn’t be.
>> It has that sort of feeling of a pointer going bad but we cannot see
>> where
>> the issue is at all. The fact that we get different results from
>> doing the
>> same install is very worrying but we can’t say whether its the
>> Aerogear
>> plugin, Ionic or our code.
>>
>> Thanks,
>>
>> Rob
>>
>> On 18 Dec 2015, at 17:26, Rob Willett wrote:
>>
>> Erok,
>>
>> We’ve not forgotten the notification issue, we’re still working
>> on it to
>> try and get to the bottom of it. The problem for us is that its not
>> so
>> simple to cut code out and try and reduce the problem down. Our code
>> is
>> quite interlinked, for good or for worse.
>>
>> We’ve added some simple sound debugging to the Objective C source
>> for the
>> Aerogear plugin. This means that we can hear where things are when
>> the
>> plugin starts up from a cold start after receiving a notification.
>> This
>> works quite well.
>>
>> We initially added a beep to here
>>
>> - (void)notificationReceived {
>> NSLog(@"Notification received");
>>
>> AudioServicesPlaySystemSound(1005);
>>
>>
>> if (notificationMessage && self.callbackId) {
>>
>> and this works whenever we get a notification in the foreground and
>> when
>> the app is in the background. We then started tracing backwards in
>> the
>> source code to see what called notificationReceived
>>
>> We can see it here
>>
>> - (void)register:(CDVInvokedUrlCommand *)command; {
>> NSLog(@"register");
>> self.callbackId = command.callbackId;
>>
>> AudioServicesPlaySystemSound(1007);
>>
>> isInline = NO;
>>
>> [self.commandDelegate runInBackground:^{
>> NSMutableDictionary *options = [self parseOptions:command];
>> [self saveConfig:options];
>>
>> // when running under iOS 8 we will use the new API for APNS
>> registration
>> #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
>>   if ([[UIApplication sharedApplication]
>> respondsToSelector:@selector(registerUserNotificationSettings:)]) {
>>       UIUserNotificationSettings* notificationSettings =
>> [UIUserNotificationSettings
>> settingsForTypes:UIUserNotificationTypeAlert |
>> UIUserNotificationTypeBadge | UIUserNotificationTypeSound
>> categories:nil];
>>       [[UIApplication sharedApplication]
>> registerUserNotificationSettings:notificationSettings];
>>       [[UIApplication sharedApplication]
>> registerForRemoteNotifications];
>>   } else {
>>       [[UIApplication sharedApplication]
>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge |
>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>>   }
>>
>> #else
>>   [[UIApplication sharedApplication]
>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge |
>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>> #endif
>>
>> CDVPluginResult* pluginResult = [CDVPluginResult
>> resultWithStatus:CDVCommandStatus_NO_RESULT];
>> [pluginResult setKeepCallback:@YES];
>> [self.commandDelegate sendPluginResult:pluginResult
>> callbackId:command.callbackId];
>> }];
>>
>> if (notificationMessage)            // if there is a pending startup
>> notification
>> {
>> AudioServicesPlaySystemSound(1024);
>>
>> [self notificationReceived];    // go ahead and process it
>> }
>> }
>>
>> So we add some more beeps in to track down whats going on. We add
>> AudioServicesPlaySystemSound(1007) at the beginning of the function
>> and add
>> AudioServicesPlaySystemSound(1024) just before we call the
>> notificationReceived method.
>>
>> We get the first sounds on startup but do NOT get the second set of
>> sounds. It looks like notificationMessage is not being set at
>> application
>> startup.
>>
>> Our problem now is that we are not Objective-C developers so we are
>> struggling to debug much further. So trying to understand how
>> notificationMessage is set and defined as its declared as @synthesis
>> is
>> unclear. We’ll start reading and learning quickly but as this is
>> new for
>> us, so we will be slow.
>>
>> Any suggestions welcomed,
>>
>> Rob
>>
>> On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> What you could try is to debug this in xcode, when the notification
>> is
>> touched it should launch the app and that will in turn call the JS
>> callback. Would be good to see if this code is called 100% of the
>> time.
>>
>> You can put a breakpoint here:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56
>>
>> That code will execute on cold start and here:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102
>>
>> That is where the onNotification callback gets invoked.
>>
>> Hope this helps,
>>
>> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <
>> [hidden email]
>>
>> wrote:
>>
>> Sebastien
>>
>> Yes, we do it at that point, $ionicPlatform.ready. I include the
>> whole of
>> that area of code for reference but we’re not expecting you to
>> debug it for
>> us. Merely to demonstrate its there.
>>
>> At the moment all we want the code to do is put an alert up.
>>
>> .run(function($ionicPlatform , CordovaService) {
>> $ionicPlatform.ready(function() {
>> if (window.StatusBar) {
>> // org.apache.cordova.statusbar required
>> StatusBar.styleDefault();
>> }
>>
>> ConsoleLog('<<< Cordova ready >>>');
>>
>> /* This seems to remove an annoying page flicker on iOS when the
>> keyboard
>> is displayed */
>> cordova.plugins.Keyboard.disableScroll(true);
>>
>> isDeviceReady = true;
>>
>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";
>>
>> var aeroGearPushConfig = {
>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>> ios: {
>> variantID: “XXXXX”,
>> variantSecret: “YYYYYYY”
>> } ,
>> // sendMetricInfo: true,
>> alias: uuid
>> };
>>
>> push.register(function (event) {
>> alert("EVENT = " + JSON.stringify(event));
>>
>> } , function () {
>> if (1)
>> {
>> // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
>> // ConsoleLog("UUID = " + uuid);
>> }
>> } , function () {
>> } , aeroGearPushConfig);
>>
>> We were still loading up another 18,000 lines of code so we need to
>> start
>> pruning that back until we have something that works.
>>
>> Rob
>>
>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:
>>
>> In the ionic app when do you do the registration of UPS ? on the
>> platformReady event ?
>>
>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
>> [hidden email]
>>
>> wrote:
>>
>> Erik,
>>
>> We have built the simplest possible app we can that uses the Aerogear
>> push plugin but using the ionic tabs starter kit.
>>
>> http://ionicframework.com/getting-started/
>>
>> We have taken the code directly from the Cordova simple app that we
>> have
>> got working and put it into the Ionic app.
>>
>> if we follow your tests as below:
>>
>> 1.
>>
>> IOS App in foreground, we send a simple push notification from the
>> Aerogear console - Works OK, We can see the event. Good
>> 2.
>>
>> IOS App in background, we send a simple push notification from the
>> Aerogear console - Works OK, We can see the event. Good
>> 3.
>>
>> IOS App killed, we send a simple push notification from the Aerogear
>>
>> console and some of the time when we click on the notification in the
>> notification drawer we do NOT get the notification handler called.
>> Not
>> so good
>>
>> However it does appear to work most of the time with our minimal
>> Ionic
>> app, but some of the time it fails. We had a run of 1 in 2 failures
>> when
>> we click on the notification. Now we have just done 20 runs in a row,
>> each time killing the app after receiving the notification and not a
>> single failure. Nothing changed.
>>
>> We cannot find any obvious reason for this so we are still
>> investigating.
>>
>> We have reconfigured our main app to work the same way as the minimal
>> app but we are still getting the same issues as before, we can see
>> the
>> notification in the drawer but clicking on it does NOT call the same
>> handler with the same code as the minimal app. We get zero calls to
>> the
>> notification event handler.
>>
>> We are wondering if there is a timing issue somewhere in our code,
>> but
>> we can’t see it. We also wondered if the size of the code we are
>> loading is the cause of a timing issue as well.
>>
>> Is there any way of adding more debugging into the Aerogear push
>> plugin
>> to see if we can track things down that way?
>>
>> Its very frustrating, but thanks for your help to date. It does look
>> like its an interaction with our code, Ionic and the Aerogear plugin.
>> My
>> money is on our code though. We’ll now start pulling working code
>> out
>> of our app until we get back to the minimal app. Only 18,604 lines to
>> go
>> :)
>>
>> Rob
>>
>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> That would be a bug, although I can not reproduce it, to test it this
>> is
>> what I've done to test it:
>> $ > cordova create push-test <my bundle id>
>> $ > cordova platform add ios
>> $ > cordova plugin add aerogear-cordova-push
>>
>> copy paste your js code into www/js/index.js onDeviceReady, changed
>> pushServerUrl and variant info and changed quotes to " (this is your
>> email
>> client no doubt) and changed : into ; after console.log("Success")
>>
>> Attach Safari debugger and send a message when the app is in the
>> foreground
>> and get in the console:
>>
>> HandleAeroGearNotification: event =>
>>
>>
>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>
>> I press the home button and send the app to the background send
>> another
>> message and 'touch' the message to launch the app:
>>
>> HandleAeroGearNotification: event =>
>>
>>
>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>
>> The I kill the app by pressing home twice and swiping over the app to
>> remove it send another message and 'touch' it to launch the app. This
>> kills
>> my safari debugger so no way to see the console log, but in this case
>> coldstart should be true. To test this better changed the code to
>> alert
>> instead of console:
>>
>> function HandleAeroGearNotification(event) {
>> alert("HandleAeroGearNotification: event => " + event.coldstart);
>>
>> // Stuff cut for clarity
>> }
>>
>> I send another notification 'touch' it to launch the app and see the
>> alert
>> box display the text:
>>
>> HandleAeroGearNotification: event => true
>>
>> Hope this helps
>>
>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
>> [hidden email]> wrote:
>>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>> 'additionalData' => { 'Disruption_Id' => '107546',
>> 'EpochTime' => '1450125268'
>> },
>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>> 'alias' => [ ‘alias1’ ],
>> 'ttl' => 600
>> };
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>>
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>>
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>> var aeroGearPushConfig = {
>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>> ios: {
>> variantID: “variantid_obscured”,
>> variantSecret: “variant_secret_obscured”
>> } ,
>> android: {
>> senderID: "variantid_obscured" ,
>> variantID: "variant_id_obscured" ,
>> variantSecret: "variant_secret_obscured"
>> } ,
>> sendMetricInfo: true,
>> alias: alias1
>> };
>>
>> function HandleAeroGearNotification(event) {
>> console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>> // Stuff cut for clarity
>> }
>>
>> // Slightly simplified registration event.
>> push.register(HandleAeroGearNotification , function () {
>> console.log(“Success”):
>> } , function () {
>> console.log(“Failure”);
>> } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>> Rob
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Erik Jan de Wit
So you are using a different plugin for push atm? Can you tell me which one, then we can see if there are differences between how it initialises and we might be able to fix this.

On Wed, Jan 13, 2016 at 12:07 PM, Rob Willett <[hidden email]> wrote:
Erik,

No there are no warnings or any any errors. Errors and warnings we can
work with, this simply didn’t fire.

At the moment we have got around the issue with a different plugin. We
didn’t change the architecture at all and the different plugin works.

At the time we thought it was a timing or race condition and we still
think that.

We have this on the backburner as we need to get a release out. We’ll
try and revisit it later but it won’t be for a few weeks as Twitter
interfaces, GPS maps and route matching is on the critical path :)

Thanks

Rob

On 13 Jan 2016, at 9:43, Erik Jan de Wit wrote:

> Seems to be an cordova issue, when loading a lot of javascript makes
> the
> plugin skip init, are there warnings in the log about this?
>
> On Sun, Dec 20, 2015 at 8:52 PM, Rob Willett
> <[hidden email]
>> wrote:
>
>> Dear all,
>>
>> We *think* we can now reproduce the problem. Clearly writing the last
>> e-mail has focussed our attention :)
>>
>> Summary.
>>
>> We have a simple Ionic app that would call the Aerogear notification
>> handler when notifications were receive in the foreground and when
>> the app
>> was in the background. The Aerogear notification handler would
>> sometimes be
>> called and sometimes NOT be called when a notification was received
>> when
>> the app was not started. See our long previous e-mails detailing the
>> problem.
>>
>> We think we can now reproduce the problem as follows:
>>
>> 1.
>>
>> Kill the app.
>> 2.
>>
>> Send a notification down to the app.
>> 3.
>>
>> It appears in the iOS notification drawer
>> 4.
>>
>> Click on the notification. if the Aerogear handler has worked then go
>> to 1 and repeat. We want a failure :)
>> 5.
>>
>> If the Aerogear handler is NOT called, then put the app into the
>> background using the Home button and then click on the app icon to
>> resume.
>> 6.
>>
>> The notification is now processed by the Aerogear handler. We can now
>> see it.
>>
>> We are at a loss to explain this, we found it by accident, but we
>> think it
>> shows some sort of timing issue somewhere because if we pull out the
>> various Javascript files the Aerogear plugin seems to work
>> consistently at
>> startup. We have checked and checked the JavaScript files and cannot
>> see
>> any error with them at all at load time.
>>
>> All suggestions welcome now.
>>
>> Rob
>>
>> On 20 Dec 2015, at 19:26, Rob Willett wrote:
>>
>> Erik, Sebastien,
>>
>> We’ve spent a significant part of the weekend looking into this
>> issue and
>> we have still not got to the bottom of it.
>>
>> We have built a very simple Ionic test app that works in isolation.
>> We
>> have used the default Ionic tabs at
>>
>> http://ionicframework.com/getting-started/
>>
>> We then add in our Javascript files as <script> entries in the
>> index.html
>> file (shown for example)
>>
>> <script src="js/polygon.js"></script>
>> <script src="js/urls.js"></script>
>> <script src="js/utilities.js"></script>
>>
>> <script src="js/moment.js"></script>
>> <script src="js/perimeter.js"></script>
>> <script src="js/leaflet.markercluster-src.js"></script>
>> <script src="js/cycle.js"></script>
>> <script src="js/clipper.js"></script>
>> <script src="js/easy_button.js"></script>
>> <script src="js/graham_scan.js"></script>
>> <script src="js/sha.js"></script>
>> <script src="js/r-tree.js"></script>
>> <script src="js/angular-leaflet-directive.min.js"></script>
>> <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
>> <script src="pouchdb/pouchdb-5.1.0.min.js"></script>
>>
>> We do NOT call any functions within any of these files, indeed we
>> make no
>> reference to these files beyond including them in the index.html
>> file. Our
>> dummy html templates make no reference to them. We simply load the
>> javascript files in. We get no errors from including the files. We
>> have
>> used the controllers and services as provided by the dummy sample
>> Ionic app.
>>
>> If we then send foreground notifications, the notifications are
>> always
>> handled by the Aerogear notification handler.
>>
>> If we send notifications to the app when it is in the background, the
>> notifications are always handled by the Aerogear notification
>> handler.
>>
>> If we kill by swiping up the app, we get the notifications but when
>> we
>> click on the notification from the main IOS screen it is arbitrary as
>> to
>> whether the notification is handled by the Aerogear handler when the
>> app
>> starts up. Sometimes the handler is called, but once the handler is
>> not
>> called, the Aerogear notification handler never appears to be called
>> again.
>> If we reinstall the app it sometimes works again and sometimes it
>> fails.
>>
>> We can reinstall the app and the Aerogear notification handler might
>> be
>> called or it might not. We just ran the app with 20 tests to the app,
>> each
>> time killing the app and then sending down a a notification and it
>> started
>> the Aerogear notification handler each time. We then reinstall the
>> app
>> again, no changes in the code and it simply doesn’t process any
>> notification when the app is closed. The notification turns up, but
>> no
>> event is called to the Aerogear event handler.
>>
>> Given that we are getting arbitrary results from the same codebase,
>> clearly something is remiss. Sometimes it works and sometimes it
>> doesn’t.
>> There is no logic that we can see. We’ve closed down Xcode after
>> installing, we’ve started and stopped our sample app a few times to
>> try and
>> make sure its closed down, ew are sending exactly the same payload
>> each
>> time.
>>
>> We feel that there is some sort of timing or race condition, or if
>> this
>> was a piece of C code, that we are overwriting somewhere we
>> shouldn’t be.
>> It has that sort of feeling of a pointer going bad but we cannot see
>> where
>> the issue is at all. The fact that we get different results from
>> doing the
>> same install is very worrying but we can’t say whether its the
>> Aerogear
>> plugin, Ionic or our code.
>>
>> Thanks,
>>
>> Rob
>>
>> On 18 Dec 2015, at 17:26, Rob Willett wrote:
>>
>> Erok,
>>
>> We’ve not forgotten the notification issue, we’re still working
>> on it to
>> try and get to the bottom of it. The problem for us is that its not
>> so
>> simple to cut code out and try and reduce the problem down. Our code
>> is
>> quite interlinked, for good or for worse.
>>
>> We’ve added some simple sound debugging to the Objective C source
>> for the
>> Aerogear plugin. This means that we can hear where things are when
>> the
>> plugin starts up from a cold start after receiving a notification.
>> This
>> works quite well.
>>
>> We initially added a beep to here
>>
>> - (void)notificationReceived {
>> NSLog(@"Notification received");
>>
>> AudioServicesPlaySystemSound(1005);
>>
>>
>> if (notificationMessage && self.callbackId) {
>>
>> and this works whenever we get a notification in the foreground and
>> when
>> the app is in the background. We then started tracing backwards in
>> the
>> source code to see what called notificationReceived
>>
>> We can see it here
>>
>> - (void)register:(CDVInvokedUrlCommand *)command; {
>> NSLog(@"register");
>> self.callbackId = command.callbackId;
>>
>> AudioServicesPlaySystemSound(1007);
>>
>> isInline = NO;
>>
>> [self.commandDelegate runInBackground:^{
>> NSMutableDictionary *options = [self parseOptions:command];
>> [self saveConfig:options];
>>
>> // when running under iOS 8 we will use the new API for APNS
>> registration
>> #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
>>   if ([[UIApplication sharedApplication]
>> respondsToSelector:@selector(registerUserNotificationSettings:)]) {
>>       UIUserNotificationSettings* notificationSettings =
>> [UIUserNotificationSettings
>> settingsForTypes:UIUserNotificationTypeAlert |
>> UIUserNotificationTypeBadge | UIUserNotificationTypeSound
>> categories:nil];
>>       [[UIApplication sharedApplication]
>> registerUserNotificationSettings:notificationSettings];
>>       [[UIApplication sharedApplication]
>> registerForRemoteNotifications];
>>   } else {
>>       [[UIApplication sharedApplication]
>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge |
>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>>   }
>>
>> #else
>>   [[UIApplication sharedApplication]
>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge |
>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>> #endif
>>
>> CDVPluginResult* pluginResult = [CDVPluginResult
>> resultWithStatus:CDVCommandStatus_NO_RESULT];
>> [pluginResult setKeepCallback:@YES];
>> [self.commandDelegate sendPluginResult:pluginResult
>> callbackId:command.callbackId];
>> }];
>>
>> if (notificationMessage)            // if there is a pending startup
>> notification
>> {
>> AudioServicesPlaySystemSound(1024);
>>
>> [self notificationReceived];    // go ahead and process it
>> }
>> }
>>
>> So we add some more beeps in to track down whats going on. We add
>> AudioServicesPlaySystemSound(1007) at the beginning of the function
>> and add
>> AudioServicesPlaySystemSound(1024) just before we call the
>> notificationReceived method.
>>
>> We get the first sounds on startup but do NOT get the second set of
>> sounds. It looks like notificationMessage is not being set at
>> application
>> startup.
>>
>> Our problem now is that we are not Objective-C developers so we are
>> struggling to debug much further. So trying to understand how
>> notificationMessage is set and defined as its declared as @synthesis
>> is
>> unclear. We’ll start reading and learning quickly but as this is
>> new for
>> us, so we will be slow.
>>
>> Any suggestions welcomed,
>>
>> Rob
>>
>> On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> What you could try is to debug this in xcode, when the notification
>> is
>> touched it should launch the app and that will in turn call the JS
>> callback. Would be good to see if this code is called 100% of the
>> time.
>>
>> You can put a breakpoint here:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56
>>
>> That code will execute on cold start and here:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102
>>
>> That is where the onNotification callback gets invoked.
>>
>> Hope this helps,
>>
>> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <
>> [hidden email]
>>
>> wrote:
>>
>> Sebastien
>>
>> Yes, we do it at that point, $ionicPlatform.ready. I include the
>> whole of
>> that area of code for reference but we’re not expecting you to
>> debug it for
>> us. Merely to demonstrate its there.
>>
>> At the moment all we want the code to do is put an alert up.
>>
>> .run(function($ionicPlatform , CordovaService) {
>> $ionicPlatform.ready(function() {
>> if (window.StatusBar) {
>> // org.apache.cordova.statusbar required
>> StatusBar.styleDefault();
>> }
>>
>> ConsoleLog('<<< Cordova ready >>>');
>>
>> /* This seems to remove an annoying page flicker on iOS when the
>> keyboard
>> is displayed */
>> cordova.plugins.Keyboard.disableScroll(true);
>>
>> isDeviceReady = true;
>>
>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";
>>
>> var aeroGearPushConfig = {
>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>> ios: {
>> variantID: “XXXXX”,
>> variantSecret: “YYYYYYY”
>> } ,
>> // sendMetricInfo: true,
>> alias: uuid
>> };
>>
>> push.register(function (event) {
>> alert("EVENT = " + JSON.stringify(event));
>>
>> } , function () {
>> if (1)
>> {
>> // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
>> // ConsoleLog("UUID = " + uuid);
>> }
>> } , function () {
>> } , aeroGearPushConfig);
>>
>> We were still loading up another 18,000 lines of code so we need to
>> start
>> pruning that back until we have something that works.
>>
>> Rob
>>
>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:
>>
>> In the ionic app when do you do the registration of UPS ? on the
>> platformReady event ?
>>
>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
>> [hidden email]
>>
>> wrote:
>>
>> Erik,
>>
>> We have built the simplest possible app we can that uses the Aerogear
>> push plugin but using the ionic tabs starter kit.
>>
>> http://ionicframework.com/getting-started/
>>
>> We have taken the code directly from the Cordova simple app that we
>> have
>> got working and put it into the Ionic app.
>>
>> if we follow your tests as below:
>>
>> 1.
>>
>> IOS App in foreground, we send a simple push notification from the
>> Aerogear console - Works OK, We can see the event. Good
>> 2.
>>
>> IOS App in background, we send a simple push notification from the
>> Aerogear console - Works OK, We can see the event. Good
>> 3.
>>
>> IOS App killed, we send a simple push notification from the Aerogear
>>
>> console and some of the time when we click on the notification in the
>> notification drawer we do NOT get the notification handler called.
>> Not
>> so good
>>
>> However it does appear to work most of the time with our minimal
>> Ionic
>> app, but some of the time it fails. We had a run of 1 in 2 failures
>> when
>> we click on the notification. Now we have just done 20 runs in a row,
>> each time killing the app after receiving the notification and not a
>> single failure. Nothing changed.
>>
>> We cannot find any obvious reason for this so we are still
>> investigating.
>>
>> We have reconfigured our main app to work the same way as the minimal
>> app but we are still getting the same issues as before, we can see
>> the
>> notification in the drawer but clicking on it does NOT call the same
>> handler with the same code as the minimal app. We get zero calls to
>> the
>> notification event handler.
>>
>> We are wondering if there is a timing issue somewhere in our code,
>> but
>> we can’t see it. We also wondered if the size of the code we are
>> loading is the cause of a timing issue as well.
>>
>> Is there any way of adding more debugging into the Aerogear push
>> plugin
>> to see if we can track things down that way?
>>
>> Its very frustrating, but thanks for your help to date. It does look
>> like its an interaction with our code, Ionic and the Aerogear plugin.
>> My
>> money is on our code though. We’ll now start pulling working code
>> out
>> of our app until we get back to the minimal app. Only 18,604 lines to
>> go
>> :)
>>
>> Rob
>>
>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> That would be a bug, although I can not reproduce it, to test it this
>> is
>> what I've done to test it:
>> $ > cordova create push-test <my bundle id>
>> $ > cordova platform add ios
>> $ > cordova plugin add aerogear-cordova-push
>>
>> copy paste your js code into www/js/index.js onDeviceReady, changed
>> pushServerUrl and variant info and changed quotes to " (this is your
>> email
>> client no doubt) and changed : into ; after console.log("Success")
>>
>> Attach Safari debugger and send a message when the app is in the
>> foreground
>> and get in the console:
>>
>> HandleAeroGearNotification: event =>
>>
>>
>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>
>> I press the home button and send the app to the background send
>> another
>> message and 'touch' the message to launch the app:
>>
>> HandleAeroGearNotification: event =>
>>
>>
>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>
>> The I kill the app by pressing home twice and swiping over the app to
>> remove it send another message and 'touch' it to launch the app. This
>> kills
>> my safari debugger so no way to see the console log, but in this case
>> coldstart should be true. To test this better changed the code to
>> alert
>> instead of console:
>>
>> function HandleAeroGearNotification(event) {
>> alert("HandleAeroGearNotification: event => " + event.coldstart);
>>
>> // Stuff cut for clarity
>> }
>>
>> I send another notification 'touch' it to launch the app and see the
>> alert
>> box display the text:
>>
>> HandleAeroGearNotification: event => true
>>
>> Hope this helps
>>
>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
>> [hidden email]> wrote:
>>
>> Hi,
>>
>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>> push
>> plugin specifically on the iOS side.
>> Summary
>>
>> We have two versions of our app, an Android and an IOS version. Both
>> use
>> the latest Cordova push plugin 2.0.4. They also both have the latest
>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and Android
>> versions are compiled at the same time. We are running cordova 5.3.3
>> with
>> Ionic 1.7.8 (?).
>>
>> 1.
>>
>> We make sure that both apps are NOT started up on each device. We
>> also
>> check they are NOT in the background.
>> 2.
>>
>> We send the same simple notification to each device. This
>> notification
>> config is as below, we have anonymised the variants and alias in this
>> JSON
>> structure, though we can report that the UPS server sends the data
>> correctly. We use the additionalData flag to provide the information
>> necessary to decide which notification has been clicked in the
>> notification
>> drawer.
>>
>> 'variants' => [‘variant1’,’variant2’ ],
>> 'message' => {
>> 'additionalData' => { 'Disruption_Id' => '107546',
>> 'EpochTime' => '1450125268'
>> },
>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction of
>> King William Street - To facilitate a heavy lift in Cannon Street,
>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>> },
>> 'alias' => [ ‘alias1’ ],
>> 'ttl' => 600
>> };
>>
>> 1.
>>
>> Both devices show the message, the Android device stacks the message
>> and the iOS device display an individual message. This looks correct.
>> 2.
>>
>> Clicking on the Android stacked message starts up the app and the
>> Javascript notification handler we have defined,
>> HandleAeroGearNotification
>> is called
>>
>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>> (All Directions) at the junction of King William Street - To
>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on
>>
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>>
>> Street (EC4N) (All Directions) at the junction of King William Street
>> - To facilitate a heavy lift in Cannon Street, Cannon Street will be
>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>
>> 1.
>>
>> Clicking on the notification in the notification drawer on the iOS
>> device also starts our app up correctly but the notification handler,
>> HandleAeroGearNotification(), is NOT called. The app starts up as
>> normal as
>> if the notification had not been clicked. We would expect the
>> notification
>> handler to be called in iOS as it is in Android.
>> 2.
>>
>> All notifications are cleared on both Android and iOS correctly when
>> the app is started up.
>> 3.
>>
>> We define HandleAeroGearNotification as
>>
>> var aeroGearPushConfig = {
>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>> ios: {
>> variantID: “variantid_obscured”,
>> variantSecret: “variant_secret_obscured”
>> } ,
>> android: {
>> senderID: "variantid_obscured" ,
>> variantID: "variant_id_obscured" ,
>> variantSecret: "variant_secret_obscured"
>> } ,
>> sendMetricInfo: true,
>> alias: alias1
>> };
>>
>> function HandleAeroGearNotification(event) {
>> console.log(“HandleAeroGearNotification: event => “ +
>> JSON.stringify(event));
>>
>> // Stuff cut for clarity
>> }
>>
>> // Slightly simplified registration event.
>> push.register(HandleAeroGearNotification , function () {
>> console.log(“Success”):
>> } , function () {
>> console.log(“Failure”);
>> } , aeroGearPushConfig);
>>
>> We cannot see any reference to this issue in the JIRA database and
>> wondered if it is a bug or not.
>>
>> If its a bug we are happy to raise it accordingly.
>>
>> Please let us know,
>>
>> Thanks
>> Rob
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users



--
Cheers,
       Erik Jan

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett
Erik,

We moved to PushWoosh as we could not resolve the issues.

Rob

On 13 Jan 2016, at 12:53, Erik Jan de Wit wrote:

> So you are using a different plugin for push atm? Can you tell me
> which
> one, then we can see if there are differences between how it
> initialises
> and we might be able to fix this.
>
> On Wed, Jan 13, 2016 at 12:07 PM, Rob Willett <
> [hidden email]> wrote:
>
>> Erik,
>>
>> No there are no warnings or any any errors. Errors and warnings we
>> can
>> work with, this simply didn’t fire.
>>
>> At the moment we have got around the issue with a different plugin.
>> We
>> didn’t change the architecture at all and the different plugin
>> works.
>>
>> At the time we thought it was a timing or race condition and we still
>> think that.
>>
>> We have this on the backburner as we need to get a release out.
>> We’ll
>> try and revisit it later but it won’t be for a few weeks as Twitter
>> interfaces, GPS maps and route matching is on the critical path :)
>>
>> Thanks
>>
>> Rob
>>
>> On 13 Jan 2016, at 9:43, Erik Jan de Wit wrote:
>>
>>> Seems to be an cordova issue, when loading a lot of javascript makes
>>> the
>>> plugin skip init, are there warnings in the log about this?
>>>
>>> On Sun, Dec 20, 2015 at 8:52 PM, Rob Willett
>>> <[hidden email]
>>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> We *think* we can now reproduce the problem. Clearly writing the
>>>> last
>>>> e-mail has focussed our attention :)
>>>>
>>>> Summary.
>>>>
>>>> We have a simple Ionic app that would call the Aerogear
>>>> notification
>>>> handler when notifications were receive in the foreground and when
>>>> the app
>>>> was in the background. The Aerogear notification handler would
>>>> sometimes be
>>>> called and sometimes NOT be called when a notification was received
>>>> when
>>>> the app was not started. See our long previous e-mails detailing
>>>> the
>>>> problem.
>>>>
>>>> We think we can now reproduce the problem as follows:
>>>>
>>>> 1.
>>>>
>>>> Kill the app.
>>>> 2.
>>>>
>>>> Send a notification down to the app.
>>>> 3.
>>>>
>>>> It appears in the iOS notification drawer
>>>> 4.
>>>>
>>>> Click on the notification. if the Aerogear handler has worked then
>>>> go
>>>> to 1 and repeat. We want a failure :)
>>>> 5.
>>>>
>>>> If the Aerogear handler is NOT called, then put the app into the
>>>> background using the Home button and then click on the app icon to
>>>> resume.
>>>> 6.
>>>>
>>>> The notification is now processed by the Aerogear handler. We can
>>>> now
>>>> see it.
>>>>
>>>> We are at a loss to explain this, we found it by accident, but we
>>>> think it
>>>> shows some sort of timing issue somewhere because if we pull out
>>>> the
>>>> various Javascript files the Aerogear plugin seems to work
>>>> consistently at
>>>> startup. We have checked and checked the JavaScript files and
>>>> cannot
>>>> see
>>>> any error with them at all at load time.
>>>>
>>>> All suggestions welcome now.
>>>>
>>>> Rob
>>>>
>>>> On 20 Dec 2015, at 19:26, Rob Willett wrote:
>>>>
>>>> Erik, Sebastien,
>>>>
>>>> We’ve spent a significant part of the weekend looking into this
>>>> issue and
>>>> we have still not got to the bottom of it.
>>>>
>>>> We have built a very simple Ionic test app that works in isolation.
>>>> We
>>>> have used the default Ionic tabs at
>>>>
>>>> http://ionicframework.com/getting-started/
>>>>
>>>> We then add in our Javascript files as <script> entries in the
>>>> index.html
>>>> file (shown for example)
>>>>
>>>> <script src="js/polygon.js"></script>
>>>> <script src="js/urls.js"></script>
>>>> <script src="js/utilities.js"></script>
>>>>
>>>> <script src="js/moment.js"></script>
>>>> <script src="js/perimeter.js"></script>
>>>> <script src="js/leaflet.markercluster-src.js"></script>
>>>> <script src="js/cycle.js"></script>
>>>> <script src="js/clipper.js"></script>
>>>> <script src="js/easy_button.js"></script>
>>>> <script src="js/graham_scan.js"></script>
>>>> <script src="js/sha.js"></script>
>>>> <script src="js/r-tree.js"></script>
>>>> <script src="js/angular-leaflet-directive.min.js"></script>
>>>> <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
>>>> <script src="pouchdb/pouchdb-5.1.0.min.js"></script>
>>>>
>>>> We do NOT call any functions within any of these files, indeed we
>>>> make no
>>>> reference to these files beyond including them in the index.html
>>>> file. Our
>>>> dummy html templates make no reference to them. We simply load the
>>>> javascript files in. We get no errors from including the files. We
>>>> have
>>>> used the controllers and services as provided by the dummy sample
>>>> Ionic app.
>>>>
>>>> If we then send foreground notifications, the notifications are
>>>> always
>>>> handled by the Aerogear notification handler.
>>>>
>>>> If we send notifications to the app when it is in the background,
>>>> the
>>>> notifications are always handled by the Aerogear notification
>>>> handler.
>>>>
>>>> If we kill by swiping up the app, we get the notifications but when
>>>> we
>>>> click on the notification from the main IOS screen it is arbitrary
>>>> as
>>>> to
>>>> whether the notification is handled by the Aerogear handler when
>>>> the
>>>> app
>>>> starts up. Sometimes the handler is called, but once the handler is
>>>> not
>>>> called, the Aerogear notification handler never appears to be
>>>> called
>>>> again.
>>>> If we reinstall the app it sometimes works again and sometimes it
>>>> fails.
>>>>
>>>> We can reinstall the app and the Aerogear notification handler
>>>> might
>>>> be
>>>> called or it might not. We just ran the app with 20 tests to the
>>>> app,
>>>> each
>>>> time killing the app and then sending down a a notification and it
>>>> started
>>>> the Aerogear notification handler each time. We then reinstall the
>>>> app
>>>> again, no changes in the code and it simply doesn’t process any
>>>> notification when the app is closed. The notification turns up, but
>>>> no
>>>> event is called to the Aerogear event handler.
>>>>
>>>> Given that we are getting arbitrary results from the same codebase,
>>>> clearly something is remiss. Sometimes it works and sometimes it
>>>> doesn’t.
>>>> There is no logic that we can see. We’ve closed down Xcode after
>>>> installing, we’ve started and stopped our sample app a few times
>>>> to
>>>> try and
>>>> make sure its closed down, ew are sending exactly the same payload
>>>> each
>>>> time.
>>>>
>>>> We feel that there is some sort of timing or race condition, or if
>>>> this
>>>> was a piece of C code, that we are overwriting somewhere we
>>>> shouldn’t be.
>>>> It has that sort of feeling of a pointer going bad but we cannot
>>>> see
>>>> where
>>>> the issue is at all. The fact that we get different results from
>>>> doing the
>>>> same install is very worrying but we can’t say whether its the
>>>> Aerogear
>>>> plugin, Ionic or our code.
>>>>
>>>> Thanks,
>>>>
>>>> Rob
>>>>
>>>> On 18 Dec 2015, at 17:26, Rob Willett wrote:
>>>>
>>>> Erok,
>>>>
>>>> We’ve not forgotten the notification issue, we’re still working
>>>> on it to
>>>> try and get to the bottom of it. The problem for us is that its not
>>>> so
>>>> simple to cut code out and try and reduce the problem down. Our
>>>> code
>>>> is
>>>> quite interlinked, for good or for worse.
>>>>
>>>> We’ve added some simple sound debugging to the Objective C source
>>>> for the
>>>> Aerogear plugin. This means that we can hear where things are when
>>>> the
>>>> plugin starts up from a cold start after receiving a notification.
>>>> This
>>>> works quite well.
>>>>
>>>> We initially added a beep to here
>>>>
>>>> - (void)notificationReceived {
>>>> NSLog(@"Notification received");
>>>>
>>>> AudioServicesPlaySystemSound(1005);
>>>>
>>>>
>>>> if (notificationMessage && self.callbackId) {
>>>>
>>>> and this works whenever we get a notification in the foreground and
>>>> when
>>>> the app is in the background. We then started tracing backwards in
>>>> the
>>>> source code to see what called notificationReceived
>>>>
>>>> We can see it here
>>>>
>>>> - (void)register:(CDVInvokedUrlCommand *)command; {
>>>> NSLog(@"register");
>>>> self.callbackId = command.callbackId;
>>>>
>>>> AudioServicesPlaySystemSound(1007);
>>>>
>>>> isInline = NO;
>>>>
>>>> [self.commandDelegate runInBackground:^{
>>>> NSMutableDictionary *options = [self parseOptions:command];
>>>> [self saveConfig:options];
>>>>
>>>> // when running under iOS 8 we will use the new API for APNS
>>>> registration
>>>> #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
>>>> if ([[UIApplication sharedApplication]
>>>> respondsToSelector:@selector(registerUserNotificationSettings:)]) {
>>>>    UIUserNotificationSettings* notificationSettings =
>>>> [UIUserNotificationSettings
>>>> settingsForTypes:UIUserNotificationTypeAlert |
>>>> UIUserNotificationTypeBadge | UIUserNotificationTypeSound
>>>> categories:nil];
>>>>    [[UIApplication sharedApplication]
>>>> registerUserNotificationSettings:notificationSettings];
>>>>    [[UIApplication sharedApplication]
>>>> registerForRemoteNotifications];
>>>> } else {
>>>>    [[UIApplication sharedApplication]
>>>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge
>>>> |
>>>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>>>> }
>>>>
>>>> #else
>>>> [[UIApplication sharedApplication]
>>>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge
>>>> |
>>>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>>>> #endif
>>>>
>>>> CDVPluginResult* pluginResult = [CDVPluginResult
>>>> resultWithStatus:CDVCommandStatus_NO_RESULT];
>>>> [pluginResult setKeepCallback:@YES];
>>>> [self.commandDelegate sendPluginResult:pluginResult
>>>> callbackId:command.callbackId];
>>>> }];
>>>>
>>>> if (notificationMessage)            // if there is a pending
>>>> startup
>>>> notification
>>>> {
>>>> AudioServicesPlaySystemSound(1024);
>>>>
>>>> [self notificationReceived];    // go ahead and process it
>>>> }
>>>> }
>>>>
>>>> So we add some more beeps in to track down whats going on. We add
>>>> AudioServicesPlaySystemSound(1007) at the beginning of the function
>>>> and add
>>>> AudioServicesPlaySystemSound(1024) just before we call the
>>>> notificationReceived method.
>>>>
>>>> We get the first sounds on startup but do NOT get the second set of
>>>> sounds. It looks like notificationMessage is not being set at
>>>> application
>>>> startup.
>>>>
>>>> Our problem now is that we are not Objective-C developers so we are
>>>> struggling to debug much further. So trying to understand how
>>>> notificationMessage is set and defined as its declared as
>>>> @synthesis
>>>> is
>>>> unclear. We’ll start reading and learning quickly but as this is
>>>> new for
>>>> us, so we will be slow.
>>>>
>>>> Any suggestions welcomed,
>>>>
>>>> Rob
>>>>
>>>> On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> What you could try is to debug this in xcode, when the notification
>>>> is
>>>> touched it should launch the app and that will in turn call the JS
>>>> callback. Would be good to see if this code is called 100% of the
>>>> time.
>>>>
>>>> You can put a breakpoint here:
>>>>
>>>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56
>>>>
>>>> That code will execute on cold start and here:
>>>>
>>>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102
>>>>
>>>> That is where the onNotification callback gets invoked.
>>>>
>>>> Hope this helps,
>>>>
>>>> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <
>>>> [hidden email]
>>>>
>>>> wrote:
>>>>
>>>> Sebastien
>>>>
>>>> Yes, we do it at that point, $ionicPlatform.ready. I include the
>>>> whole of
>>>> that area of code for reference but we’re not expecting you to
>>>> debug it for
>>>> us. Merely to demonstrate its there.
>>>>
>>>> At the moment all we want the code to do is put an alert up.
>>>>
>>>> .run(function($ionicPlatform , CordovaService) {
>>>> $ionicPlatform.ready(function() {
>>>> if (window.StatusBar) {
>>>> // org.apache.cordova.statusbar required
>>>> StatusBar.styleDefault();
>>>> }
>>>>
>>>> ConsoleLog('<<< Cordova ready >>>');
>>>>
>>>> /* This seems to remove an annoying page flicker on iOS when the
>>>> keyboard
>>>> is displayed */
>>>> cordova.plugins.Keyboard.disableScroll(true);
>>>>
>>>> isDeviceReady = true;
>>>>
>>>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";
>>>>
>>>> var aeroGearPushConfig = {
>>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>>> ios: {
>>>> variantID: “XXXXX”,
>>>> variantSecret: “YYYYYYY”
>>>> } ,
>>>> // sendMetricInfo: true,
>>>> alias: uuid
>>>> };
>>>>
>>>> push.register(function (event) {
>>>> alert("EVENT = " + JSON.stringify(event));
>>>>
>>>> } , function () {
>>>> if (1)
>>>> {
>>>> // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
>>>> // ConsoleLog("UUID = " + uuid);
>>>> }
>>>> } , function () {
>>>> } , aeroGearPushConfig);
>>>>
>>>> We were still loading up another 18,000 lines of code so we need to
>>>> start
>>>> pruning that back until we have something that works.
>>>>
>>>> Rob
>>>>
>>>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:
>>>>
>>>> In the ionic app when do you do the registration of UPS ? on the
>>>> platformReady event ?
>>>>
>>>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
>>>> [hidden email]
>>>>
>>>> wrote:
>>>>
>>>> Erik,
>>>>
>>>> We have built the simplest possible app we can that uses the
>>>> Aerogear
>>>> push plugin but using the ionic tabs starter kit.
>>>>
>>>> http://ionicframework.com/getting-started/
>>>>
>>>> We have taken the code directly from the Cordova simple app that we
>>>> have
>>>> got working and put it into the Ionic app.
>>>>
>>>> if we follow your tests as below:
>>>>
>>>> 1.
>>>>
>>>> IOS App in foreground, we send a simple push notification from the
>>>> Aerogear console - Works OK, We can see the event. Good
>>>> 2.
>>>>
>>>> IOS App in background, we send a simple push notification from the
>>>> Aerogear console - Works OK, We can see the event. Good
>>>> 3.
>>>>
>>>> IOS App killed, we send a simple push notification from the
>>>> Aerogear
>>>>
>>>> console and some of the time when we click on the notification in
>>>> the
>>>> notification drawer we do NOT get the notification handler called.
>>>> Not
>>>> so good
>>>>
>>>> However it does appear to work most of the time with our minimal
>>>> Ionic
>>>> app, but some of the time it fails. We had a run of 1 in 2 failures
>>>> when
>>>> we click on the notification. Now we have just done 20 runs in a
>>>> row,
>>>> each time killing the app after receiving the notification and not
>>>> a
>>>> single failure. Nothing changed.
>>>>
>>>> We cannot find any obvious reason for this so we are still
>>>> investigating.
>>>>
>>>> We have reconfigured our main app to work the same way as the
>>>> minimal
>>>> app but we are still getting the same issues as before, we can see
>>>> the
>>>> notification in the drawer but clicking on it does NOT call the
>>>> same
>>>> handler with the same code as the minimal app. We get zero calls to
>>>> the
>>>> notification event handler.
>>>>
>>>> We are wondering if there is a timing issue somewhere in our code,
>>>> but
>>>> we can’t see it. We also wondered if the size of the code we are
>>>> loading is the cause of a timing issue as well.
>>>>
>>>> Is there any way of adding more debugging into the Aerogear push
>>>> plugin
>>>> to see if we can track things down that way?
>>>>
>>>> Its very frustrating, but thanks for your help to date. It does
>>>> look
>>>> like its an interaction with our code, Ionic and the Aerogear
>>>> plugin.
>>>> My
>>>> money is on our code though. We’ll now start pulling working code
>>>> out
>>>> of our app until we get back to the minimal app. Only 18,604 lines
>>>> to
>>>> go
>>>> :)
>>>>
>>>> Rob
>>>>
>>>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> That would be a bug, although I can not reproduce it, to test it
>>>> this
>>>> is
>>>> what I've done to test it:
>>>> $ > cordova create push-test <my bundle id>
>>>> $ > cordova platform add ios
>>>> $ > cordova plugin add aerogear-cordova-push
>>>>
>>>> copy paste your js code into www/js/index.js onDeviceReady, changed
>>>> pushServerUrl and variant info and changed quotes to " (this is
>>>> your
>>>> email
>>>> client no doubt) and changed : into ; after console.log("Success")
>>>>
>>>> Attach Safari debugger and send a message when the app is in the
>>>> foreground
>>>> and get in the console:
>>>>
>>>> HandleAeroGearNotification: event =>
>>>>
>>>>
>>>>
>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>>>
>>>> I press the home button and send the app to the background send
>>>> another
>>>> message and 'touch' the message to launch the app:
>>>>
>>>> HandleAeroGearNotification: event =>
>>>>
>>>>
>>>>
>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>>>
>>>> The I kill the app by pressing home twice and swiping over the app
>>>> to
>>>> remove it send another message and 'touch' it to launch the app.
>>>> This
>>>> kills
>>>> my safari debugger so no way to see the console log, but in this
>>>> case
>>>> coldstart should be true. To test this better changed the code to
>>>> alert
>>>> instead of console:
>>>>
>>>> function HandleAeroGearNotification(event) {
>>>> alert("HandleAeroGearNotification: event => " + event.coldstart);
>>>>
>>>> // Stuff cut for clarity
>>>> }
>>>>
>>>> I send another notification 'touch' it to launch the app and see
>>>> the
>>>> alert
>>>> box display the text:
>>>>
>>>> HandleAeroGearNotification: event => true
>>>>
>>>> Hope this helps
>>>>
>>>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
>>>> [hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>>>> push
>>>> plugin specifically on the iOS side.
>>>> Summary
>>>>
>>>> We have two versions of our app, an Android and an IOS version.
>>>> Both
>>>> use
>>>> the latest Cordova push plugin 2.0.4. They also both have the
>>>> latest
>>>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and
>>>> Android
>>>> versions are compiled at the same time. We are running cordova
>>>> 5.3.3
>>>> with
>>>> Ionic 1.7.8 (?).
>>>>
>>>> 1.
>>>>
>>>> We make sure that both apps are NOT started up on each device. We
>>>> also
>>>> check they are NOT in the background.
>>>> 2.
>>>>
>>>> We send the same simple notification to each device. This
>>>> notification
>>>> config is as below, we have anonymised the variants and alias in
>>>> this
>>>> JSON
>>>> structure, though we can report that the UPS server sends the data
>>>> correctly. We use the additionalData flag to provide the
>>>> information
>>>> necessary to decide which notification has been clicked in the
>>>> notification
>>>> drawer.
>>>>
>>>> 'variants' => [‘variant1’,’variant2’ ],
>>>> 'message' => {
>>>> 'additionalData' => { 'Disruption_Id' => '107546',
>>>> 'EpochTime' => '1450125268'
>>>> },
>>>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction
>>>> of
>>>> King William Street - To facilitate a heavy lift in Cannon Street,
>>>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>>>> },
>>>> 'alias' => [ ‘alias1’ ],
>>>> 'ttl' => 600
>>>> };
>>>>
>>>> 1.
>>>>
>>>> Both devices show the message, the Android device stacks the
>>>> message
>>>> and the iOS device display an individual message. This looks
>>>> correct.
>>>> 2.
>>>>
>>>> Clicking on the Android stacked message starts up the app and the
>>>> Javascript notification handler we have defined,
>>>> HandleAeroGearNotification
>>>> is called
>>>>
>>>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>>>> (All Directions) at the junction of King William Street - To
>>>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>>>> closed. Traffic is slow moving on
>>>>
>>>>
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>>>>
>>>> Street (EC4N) (All Directions) at the junction of King William
>>>> Street
>>>> - To facilitate a heavy lift in Cannon Street, Cannon Street will
>>>> be
>>>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>>>
>>>> 1.
>>>>
>>>> Clicking on the notification in the notification drawer on the iOS
>>>> device also starts our app up correctly but the notification
>>>> handler,
>>>> HandleAeroGearNotification(), is NOT called. The app starts up as
>>>> normal as
>>>> if the notification had not been clicked. We would expect the
>>>> notification
>>>> handler to be called in iOS as it is in Android.
>>>> 2.
>>>>
>>>> All notifications are cleared on both Android and iOS correctly
>>>> when
>>>> the app is started up.
>>>> 3.
>>>>
>>>> We define HandleAeroGearNotification as
>>>>
>>>> var aeroGearPushConfig = {
>>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>>> ios: {
>>>> variantID: “variantid_obscured”,
>>>> variantSecret: “variant_secret_obscured”
>>>> } ,
>>>> android: {
>>>> senderID: "variantid_obscured" ,
>>>> variantID: "variant_id_obscured" ,
>>>> variantSecret: "variant_secret_obscured"
>>>> } ,
>>>> sendMetricInfo: true,
>>>> alias: alias1
>>>> };
>>>>
>>>> function HandleAeroGearNotification(event) {
>>>> console.log(“HandleAeroGearNotification: event => “ +
>>>> JSON.stringify(event));
>>>>
>>>> // Stuff cut for clarity
>>>> }
>>>>
>>>> // Slightly simplified registration event.
>>>> push.register(HandleAeroGearNotification , function () {
>>>> console.log(“Success”):
>>>> } , function () {
>>>> console.log(“Failure”);
>>>> } , aeroGearPushConfig);
>>>>
>>>> We cannot see any reference to this issue in the JIRA database and
>>>> wondered if it is a bug or not.
>>>>
>>>> If its a bug we are happy to raise it accordingly.
>>>>
>>>> Please let us know,
>>>>
>>>> Thanks
>>>> Rob
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> --
>>>> Cheers,
>>>> Erik Jan
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> --
>>>> Cheers,
>>>> Erik Jan
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>>
>>>> _______________________________________________
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>>  Erik Jan
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Possible bug in Aerogear Push Cordova/iOS implementation but not in the Cordova/Android version

Rob Willett
In reply to this post by Erik Jan de Wit
Erik,

Pressed the return key too early.

We also tried it with OneSignal as well and that was fine.

Rob

On 13 Jan 2016, at 12:53, Erik Jan de Wit wrote:

> So you are using a different plugin for push atm? Can you tell me
> which
> one, then we can see if there are differences between how it
> initialises
> and we might be able to fix this.
>
> On Wed, Jan 13, 2016 at 12:07 PM, Rob Willett <
> [hidden email]> wrote:
>
>> Erik,
>>
>> No there are no warnings or any any errors. Errors and warnings we
>> can
>> work with, this simply didn’t fire.
>>
>> At the moment we have got around the issue with a different plugin.
>> We
>> didn’t change the architecture at all and the different plugin
>> works.
>>
>> At the time we thought it was a timing or race condition and we still
>> think that.
>>
>> We have this on the backburner as we need to get a release out.
>> We’ll
>> try and revisit it later but it won’t be for a few weeks as Twitter
>> interfaces, GPS maps and route matching is on the critical path :)
>>
>> Thanks
>>
>> Rob
>>
>> On 13 Jan 2016, at 9:43, Erik Jan de Wit wrote:
>>
>>> Seems to be an cordova issue, when loading a lot of javascript makes
>>> the
>>> plugin skip init, are there warnings in the log about this?
>>>
>>> On Sun, Dec 20, 2015 at 8:52 PM, Rob Willett
>>> <[hidden email]
>>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> We *think* we can now reproduce the problem. Clearly writing the
>>>> last
>>>> e-mail has focussed our attention :)
>>>>
>>>> Summary.
>>>>
>>>> We have a simple Ionic app that would call the Aerogear
>>>> notification
>>>> handler when notifications were receive in the foreground and when
>>>> the app
>>>> was in the background. The Aerogear notification handler would
>>>> sometimes be
>>>> called and sometimes NOT be called when a notification was received
>>>> when
>>>> the app was not started. See our long previous e-mails detailing
>>>> the
>>>> problem.
>>>>
>>>> We think we can now reproduce the problem as follows:
>>>>
>>>> 1.
>>>>
>>>> Kill the app.
>>>> 2.
>>>>
>>>> Send a notification down to the app.
>>>> 3.
>>>>
>>>> It appears in the iOS notification drawer
>>>> 4.
>>>>
>>>> Click on the notification. if the Aerogear handler has worked then
>>>> go
>>>> to 1 and repeat. We want a failure :)
>>>> 5.
>>>>
>>>> If the Aerogear handler is NOT called, then put the app into the
>>>> background using the Home button and then click on the app icon to
>>>> resume.
>>>> 6.
>>>>
>>>> The notification is now processed by the Aerogear handler. We can
>>>> now
>>>> see it.
>>>>
>>>> We are at a loss to explain this, we found it by accident, but we
>>>> think it
>>>> shows some sort of timing issue somewhere because if we pull out
>>>> the
>>>> various Javascript files the Aerogear plugin seems to work
>>>> consistently at
>>>> startup. We have checked and checked the JavaScript files and
>>>> cannot
>>>> see
>>>> any error with them at all at load time.
>>>>
>>>> All suggestions welcome now.
>>>>
>>>> Rob
>>>>
>>>> On 20 Dec 2015, at 19:26, Rob Willett wrote:
>>>>
>>>> Erik, Sebastien,
>>>>
>>>> We’ve spent a significant part of the weekend looking into this
>>>> issue and
>>>> we have still not got to the bottom of it.
>>>>
>>>> We have built a very simple Ionic test app that works in isolation.
>>>> We
>>>> have used the default Ionic tabs at
>>>>
>>>> http://ionicframework.com/getting-started/
>>>>
>>>> We then add in our Javascript files as <script> entries in the
>>>> index.html
>>>> file (shown for example)
>>>>
>>>> <script src="js/polygon.js"></script>
>>>> <script src="js/urls.js"></script>
>>>> <script src="js/utilities.js"></script>
>>>>
>>>> <script src="js/moment.js"></script>
>>>> <script src="js/perimeter.js"></script>
>>>> <script src="js/leaflet.markercluster-src.js"></script>
>>>> <script src="js/cycle.js"></script>
>>>> <script src="js/clipper.js"></script>
>>>> <script src="js/easy_button.js"></script>
>>>> <script src="js/graham_scan.js"></script>
>>>> <script src="js/sha.js"></script>
>>>> <script src="js/r-tree.js"></script>
>>>> <script src="js/angular-leaflet-directive.min.js"></script>
>>>> <script src="pouchdb/L.TileLayer.PouchDBCached.js"></script>
>>>> <script src="pouchdb/pouchdb-5.1.0.min.js"></script>
>>>>
>>>> We do NOT call any functions within any of these files, indeed we
>>>> make no
>>>> reference to these files beyond including them in the index.html
>>>> file. Our
>>>> dummy html templates make no reference to them. We simply load the
>>>> javascript files in. We get no errors from including the files. We
>>>> have
>>>> used the controllers and services as provided by the dummy sample
>>>> Ionic app.
>>>>
>>>> If we then send foreground notifications, the notifications are
>>>> always
>>>> handled by the Aerogear notification handler.
>>>>
>>>> If we send notifications to the app when it is in the background,
>>>> the
>>>> notifications are always handled by the Aerogear notification
>>>> handler.
>>>>
>>>> If we kill by swiping up the app, we get the notifications but when
>>>> we
>>>> click on the notification from the main IOS screen it is arbitrary
>>>> as
>>>> to
>>>> whether the notification is handled by the Aerogear handler when
>>>> the
>>>> app
>>>> starts up. Sometimes the handler is called, but once the handler is
>>>> not
>>>> called, the Aerogear notification handler never appears to be
>>>> called
>>>> again.
>>>> If we reinstall the app it sometimes works again and sometimes it
>>>> fails.
>>>>
>>>> We can reinstall the app and the Aerogear notification handler
>>>> might
>>>> be
>>>> called or it might not. We just ran the app with 20 tests to the
>>>> app,
>>>> each
>>>> time killing the app and then sending down a a notification and it
>>>> started
>>>> the Aerogear notification handler each time. We then reinstall the
>>>> app
>>>> again, no changes in the code and it simply doesn’t process any
>>>> notification when the app is closed. The notification turns up, but
>>>> no
>>>> event is called to the Aerogear event handler.
>>>>
>>>> Given that we are getting arbitrary results from the same codebase,
>>>> clearly something is remiss. Sometimes it works and sometimes it
>>>> doesn’t.
>>>> There is no logic that we can see. We’ve closed down Xcode after
>>>> installing, we’ve started and stopped our sample app a few times
>>>> to
>>>> try and
>>>> make sure its closed down, ew are sending exactly the same payload
>>>> each
>>>> time.
>>>>
>>>> We feel that there is some sort of timing or race condition, or if
>>>> this
>>>> was a piece of C code, that we are overwriting somewhere we
>>>> shouldn’t be.
>>>> It has that sort of feeling of a pointer going bad but we cannot
>>>> see
>>>> where
>>>> the issue is at all. The fact that we get different results from
>>>> doing the
>>>> same install is very worrying but we can’t say whether its the
>>>> Aerogear
>>>> plugin, Ionic or our code.
>>>>
>>>> Thanks,
>>>>
>>>> Rob
>>>>
>>>> On 18 Dec 2015, at 17:26, Rob Willett wrote:
>>>>
>>>> Erok,
>>>>
>>>> We’ve not forgotten the notification issue, we’re still working
>>>> on it to
>>>> try and get to the bottom of it. The problem for us is that its not
>>>> so
>>>> simple to cut code out and try and reduce the problem down. Our
>>>> code
>>>> is
>>>> quite interlinked, for good or for worse.
>>>>
>>>> We’ve added some simple sound debugging to the Objective C source
>>>> for the
>>>> Aerogear plugin. This means that we can hear where things are when
>>>> the
>>>> plugin starts up from a cold start after receiving a notification.
>>>> This
>>>> works quite well.
>>>>
>>>> We initially added a beep to here
>>>>
>>>> - (void)notificationReceived {
>>>> NSLog(@"Notification received");
>>>>
>>>> AudioServicesPlaySystemSound(1005);
>>>>
>>>>
>>>> if (notificationMessage && self.callbackId) {
>>>>
>>>> and this works whenever we get a notification in the foreground and
>>>> when
>>>> the app is in the background. We then started tracing backwards in
>>>> the
>>>> source code to see what called notificationReceived
>>>>
>>>> We can see it here
>>>>
>>>> - (void)register:(CDVInvokedUrlCommand *)command; {
>>>> NSLog(@"register");
>>>> self.callbackId = command.callbackId;
>>>>
>>>> AudioServicesPlaySystemSound(1007);
>>>>
>>>> isInline = NO;
>>>>
>>>> [self.commandDelegate runInBackground:^{
>>>> NSMutableDictionary *options = [self parseOptions:command];
>>>> [self saveConfig:options];
>>>>
>>>> // when running under iOS 8 we will use the new API for APNS
>>>> registration
>>>> #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 80000
>>>> if ([[UIApplication sharedApplication]
>>>> respondsToSelector:@selector(registerUserNotificationSettings:)]) {
>>>>    UIUserNotificationSettings* notificationSettings =
>>>> [UIUserNotificationSettings
>>>> settingsForTypes:UIUserNotificationTypeAlert |
>>>> UIUserNotificationTypeBadge | UIUserNotificationTypeSound
>>>> categories:nil];
>>>>    [[UIApplication sharedApplication]
>>>> registerUserNotificationSettings:notificationSettings];
>>>>    [[UIApplication sharedApplication]
>>>> registerForRemoteNotifications];
>>>> } else {
>>>>    [[UIApplication sharedApplication]
>>>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge
>>>> |
>>>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>>>> }
>>>>
>>>> #else
>>>> [[UIApplication sharedApplication]
>>>> registerForRemoteNotificationTypes: (UIRemoteNotificationTypeBadge
>>>> |
>>>> UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
>>>> #endif
>>>>
>>>> CDVPluginResult* pluginResult = [CDVPluginResult
>>>> resultWithStatus:CDVCommandStatus_NO_RESULT];
>>>> [pluginResult setKeepCallback:@YES];
>>>> [self.commandDelegate sendPluginResult:pluginResult
>>>> callbackId:command.callbackId];
>>>> }];
>>>>
>>>> if (notificationMessage)            // if there is a pending
>>>> startup
>>>> notification
>>>> {
>>>> AudioServicesPlaySystemSound(1024);
>>>>
>>>> [self notificationReceived];    // go ahead and process it
>>>> }
>>>> }
>>>>
>>>> So we add some more beeps in to track down whats going on. We add
>>>> AudioServicesPlaySystemSound(1007) at the beginning of the function
>>>> and add
>>>> AudioServicesPlaySystemSound(1024) just before we call the
>>>> notificationReceived method.
>>>>
>>>> We get the first sounds on startup but do NOT get the second set of
>>>> sounds. It looks like notificationMessage is not being set at
>>>> application
>>>> startup.
>>>>
>>>> Our problem now is that we are not Objective-C developers so we are
>>>> struggling to debug much further. So trying to understand how
>>>> notificationMessage is set and defined as its declared as
>>>> @synthesis
>>>> is
>>>> unclear. We’ll start reading and learning quickly but as this is
>>>> new for
>>>> us, so we will be slow.
>>>>
>>>> Any suggestions welcomed,
>>>>
>>>> Rob
>>>>
>>>> On 16 Dec 2015, at 16:54, Erik Jan de Wit wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> What you could try is to debug this in xcode, when the notification
>>>> is
>>>> touched it should launch the app and that will in turn call the JS
>>>> callback. Would be good to see if this code is called 100% of the
>>>> time.
>>>>
>>>> You can put a breakpoint here:
>>>>
>>>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AppDelegate%2Bnotification.m#L56
>>>>
>>>> That code will execute on cold start and here:
>>>>
>>>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L102
>>>>
>>>> That is where the onNotification callback gets invoked.
>>>>
>>>> Hope this helps,
>>>>
>>>> On Wed, Dec 16, 2015 at 5:14 PM, Rob Willett <
>>>> [hidden email]
>>>>
>>>> wrote:
>>>>
>>>> Sebastien
>>>>
>>>> Yes, we do it at that point, $ionicPlatform.ready. I include the
>>>> whole of
>>>> that area of code for reference but we’re not expecting you to
>>>> debug it for
>>>> us. Merely to demonstrate its there.
>>>>
>>>> At the moment all we want the code to do is put an alert up.
>>>>
>>>> .run(function($ionicPlatform , CordovaService) {
>>>> $ionicPlatform.ready(function() {
>>>> if (window.StatusBar) {
>>>> // org.apache.cordova.statusbar required
>>>> StatusBar.styleDefault();
>>>> }
>>>>
>>>> ConsoleLog('<<< Cordova ready >>>');
>>>>
>>>> /* This seems to remove an annoying page flicker on iOS when the
>>>> keyboard
>>>> is displayed */
>>>> cordova.plugins.Keyboard.disableScroll(true);
>>>>
>>>> isDeviceReady = true;
>>>>
>>>> var uuid = "D26FBAF1-2EF2-4614-875F-4497EC4212D5/JFL1-0/ios_app";
>>>>
>>>> var aeroGearPushConfig = {
>>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>>> ios: {
>>>> variantID: “XXXXX”,
>>>> variantSecret: “YYYYYYY”
>>>> } ,
>>>> // sendMetricInfo: true,
>>>> alias: uuid
>>>> };
>>>>
>>>> push.register(function (event) {
>>>> alert("EVENT = " + JSON.stringify(event));
>>>>
>>>> } , function () {
>>>> if (1)
>>>> {
>>>> // alert("AeroGearSuccessHandler: OK " + JSON.stringify(uuid));
>>>> // ConsoleLog("UUID = " + uuid);
>>>> }
>>>> } , function () {
>>>> } , aeroGearPushConfig);
>>>>
>>>> We were still loading up another 18,000 lines of code so we need to
>>>> start
>>>> pruning that back until we have something that works.
>>>>
>>>> Rob
>>>>
>>>> On 16 Dec 2015, at 16:04, Sebastien Blanc wrote:
>>>>
>>>> In the ionic app when do you do the registration of UPS ? on the
>>>> platformReady event ?
>>>>
>>>> On Wed, Dec 16, 2015 at 4:54 PM, Rob Willett <
>>>> [hidden email]
>>>>
>>>> wrote:
>>>>
>>>> Erik,
>>>>
>>>> We have built the simplest possible app we can that uses the
>>>> Aerogear
>>>> push plugin but using the ionic tabs starter kit.
>>>>
>>>> http://ionicframework.com/getting-started/
>>>>
>>>> We have taken the code directly from the Cordova simple app that we
>>>> have
>>>> got working and put it into the Ionic app.
>>>>
>>>> if we follow your tests as below:
>>>>
>>>> 1.
>>>>
>>>> IOS App in foreground, we send a simple push notification from the
>>>> Aerogear console - Works OK, We can see the event. Good
>>>> 2.
>>>>
>>>> IOS App in background, we send a simple push notification from the
>>>> Aerogear console - Works OK, We can see the event. Good
>>>> 3.
>>>>
>>>> IOS App killed, we send a simple push notification from the
>>>> Aerogear
>>>>
>>>> console and some of the time when we click on the notification in
>>>> the
>>>> notification drawer we do NOT get the notification handler called.
>>>> Not
>>>> so good
>>>>
>>>> However it does appear to work most of the time with our minimal
>>>> Ionic
>>>> app, but some of the time it fails. We had a run of 1 in 2 failures
>>>> when
>>>> we click on the notification. Now we have just done 20 runs in a
>>>> row,
>>>> each time killing the app after receiving the notification and not
>>>> a
>>>> single failure. Nothing changed.
>>>>
>>>> We cannot find any obvious reason for this so we are still
>>>> investigating.
>>>>
>>>> We have reconfigured our main app to work the same way as the
>>>> minimal
>>>> app but we are still getting the same issues as before, we can see
>>>> the
>>>> notification in the drawer but clicking on it does NOT call the
>>>> same
>>>> handler with the same code as the minimal app. We get zero calls to
>>>> the
>>>> notification event handler.
>>>>
>>>> We are wondering if there is a timing issue somewhere in our code,
>>>> but
>>>> we can’t see it. We also wondered if the size of the code we are
>>>> loading is the cause of a timing issue as well.
>>>>
>>>> Is there any way of adding more debugging into the Aerogear push
>>>> plugin
>>>> to see if we can track things down that way?
>>>>
>>>> Its very frustrating, but thanks for your help to date. It does
>>>> look
>>>> like its an interaction with our code, Ionic and the Aerogear
>>>> plugin.
>>>> My
>>>> money is on our code though. We’ll now start pulling working code
>>>> out
>>>> of our app until we get back to the minimal app. Only 18,604 lines
>>>> to
>>>> go
>>>> :)
>>>>
>>>> Rob
>>>>
>>>> On 15 Dec 2015, at 10:36, Erik Jan de Wit wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> That would be a bug, although I can not reproduce it, to test it
>>>> this
>>>> is
>>>> what I've done to test it:
>>>> $ > cordova create push-test <my bundle id>
>>>> $ > cordova platform add ios
>>>> $ > cordova plugin add aerogear-cordova-push
>>>>
>>>> copy paste your js code into www/js/index.js onDeviceReady, changed
>>>> pushServerUrl and variant info and changed quotes to " (this is
>>>> your
>>>> email
>>>> client no doubt) and changed : into ; after console.log("Success")
>>>>
>>>> Attach Safari debugger and send a message when the app is in the
>>>> foreground
>>>> and get in the console:
>>>>
>>>> HandleAeroGearNotification: event =>
>>>>
>>>>
>>>>
>> {"alert":"test","foreground":true,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>>>
>>>> I press the home button and send the app to the background send
>>>> another
>>>> message and 'touch' the message to launch the app:
>>>>
>>>> HandleAeroGearNotification: event =>
>>>>
>>>>
>>>>
>> {"alert":"background","foreground":false,"coldstart":false,"sound":"default","badge":-1,"payload":{}}
>>>>
>>>> The I kill the app by pressing home twice and swiping over the app
>>>> to
>>>> remove it send another message and 'touch' it to launch the app.
>>>> This
>>>> kills
>>>> my safari debugger so no way to see the console log, but in this
>>>> case
>>>> coldstart should be true. To test this better changed the code to
>>>> alert
>>>> instead of console:
>>>>
>>>> function HandleAeroGearNotification(event) {
>>>> alert("HandleAeroGearNotification: event => " + event.coldstart);
>>>>
>>>> // Stuff cut for clarity
>>>> }
>>>>
>>>> I send another notification 'touch' it to launch the app and see
>>>> the
>>>> alert
>>>> box display the text:
>>>>
>>>> HandleAeroGearNotification: event => true
>>>>
>>>> Hope this helps
>>>>
>>>> On Mon, Dec 14, 2015 at 10:20 PM, Rob Willett <
>>>> [hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> We think we have found a possible bug in the Aerogear Cordova 2.0.4
>>>> push
>>>> plugin specifically on the iOS side.
>>>> Summary
>>>>
>>>> We have two versions of our app, an Android and an IOS version.
>>>> Both
>>>> use
>>>> the latest Cordova push plugin 2.0.4. They also both have the
>>>> latest
>>>> Cordova platforms, android 4.1.1, ios 3.9.2. Both the iOS and
>>>> Android
>>>> versions are compiled at the same time. We are running cordova
>>>> 5.3.3
>>>> with
>>>> Ionic 1.7.8 (?).
>>>>
>>>> 1.
>>>>
>>>> We make sure that both apps are NOT started up on each device. We
>>>> also
>>>> check they are NOT in the background.
>>>> 2.
>>>>
>>>> We send the same simple notification to each device. This
>>>> notification
>>>> config is as below, we have anonymised the variants and alias in
>>>> this
>>>> JSON
>>>> structure, though we can report that the UPS server sends the data
>>>> correctly. We use the additionalData flag to provide the
>>>> information
>>>> necessary to decide which notification has been clicked in the
>>>> notification
>>>> drawer.
>>>>
>>>> 'variants' => [‘variant1’,’variant2’ ],
>>>> 'message' => {
>>>> 'additionalData' => { 'Disruption_Id' => '107546',
>>>> 'EpochTime' => '1450125268'
>>>> },
>>>> 'alert' => 'Cannon Street (EC4N) (All Directions) at the junction
>>>> of
>>>> King William Street - To facilitate a heavy lift in Cannon Street,
>>>> Cannon Street will be closed. Traffic is slow moving on diversion.'
>>>> },
>>>> 'alias' => [ ‘alias1’ ],
>>>> 'ttl' => 600
>>>> };
>>>>
>>>> 1.
>>>>
>>>> Both devices show the message, the Android device stacks the
>>>> message
>>>> and the iOS device display an individual message. This looks
>>>> correct.
>>>> 2.
>>>>
>>>> Clicking on the Android stacked message starts up the app and the
>>>> Javascript notification handler we have defined,
>>>> HandleAeroGearNotification
>>>> is called
>>>>
>>>> HandleAeroGearNotification: event => {"alert":"Cannon Street (EC4N)
>>>> (All Directions) at the junction of King William Street - To
>>>> facilitate a heavy lift in Cannon Street, Cannon Street will be
>>>> closed. Traffic is slow moving on
>>>>
>>>>
>> diversion.","coldstart":true,"foreground":true,"payload":{"alert":"Cannon
>>>>
>>>> Street (EC4N) (All Directions) at the junction of King William
>>>> Street
>>>> - To facilitate a heavy lift in Cannon Street, Cannon Street will
>>>> be
>>>> closed. Traffic is slow moving on diversion.","badge":"-1"}}
>>>>
>>>> 1.
>>>>
>>>> Clicking on the notification in the notification drawer on the iOS
>>>> device also starts our app up correctly but the notification
>>>> handler,
>>>> HandleAeroGearNotification(), is NOT called. The app starts up as
>>>> normal as
>>>> if the notification had not been clicked. We would expect the
>>>> notification
>>>> handler to be called in iOS as it is in Android.
>>>> 2.
>>>>
>>>> All notifications are cleared on both Android and iOS correctly
>>>> when
>>>> the app is started up.
>>>> 3.
>>>>
>>>> We define HandleAeroGearNotification as
>>>>
>>>> var aeroGearPushConfig = {
>>>> pushServerURL: "https://push-jambuster.rhcloud.com/ag-push/",
>>>> ios: {
>>>> variantID: “variantid_obscured”,
>>>> variantSecret: “variant_secret_obscured”
>>>> } ,
>>>> android: {
>>>> senderID: "variantid_obscured" ,
>>>> variantID: "variant_id_obscured" ,
>>>> variantSecret: "variant_secret_obscured"
>>>> } ,
>>>> sendMetricInfo: true,
>>>> alias: alias1
>>>> };
>>>>
>>>> function HandleAeroGearNotification(event) {
>>>> console.log(“HandleAeroGearNotification: event => “ +
>>>> JSON.stringify(event));
>>>>
>>>> // Stuff cut for clarity
>>>> }
>>>>
>>>> // Slightly simplified registration event.
>>>> push.register(HandleAeroGearNotification , function () {
>>>> console.log(“Success”):
>>>> } , function () {
>>>> console.log(“Failure”);
>>>> } , aeroGearPushConfig);
>>>>
>>>> We cannot see any reference to this issue in the JIRA database and
>>>> wondered if it is a bug or not.
>>>>
>>>> If its a bug we are happy to raise it accordingly.
>>>>
>>>> Please let us know,
>>>>
>>>> Thanks
>>>> Rob
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> --
>>>> Cheers,
>>>> Erik Jan
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> --
>>>> Cheers,
>>>> Erik Jan
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>> ------------------------------
>>>>
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>>
>>>> _______________________________________________
>>>> Aerogear-users mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>>  Erik Jan
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>
>
>
> --
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users