Quantcast

[Aerogear-users] Should the cordova push plugin start the App up if its not started?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Aerogear-users] Should the cordova push plugin start the App up if its not started?

Rob Willett

Hi,

We’re trying to work out if the Aerogear Cordova push notification should start the app if the app is not started. If the app is in the background than we get the notification but if the app is not started up we don’t seem to get anything happening.

It seems to work OK when the app is in the foreground or background, just not when its not started up?

Should it work when the app is not started on both iOS and Android?

Thanks,

Rob


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

Re: [Aerogear-users] Should the cordova push plugin start the App up if its not started?

Erik Jan de Wit
Hi Rob,

Currently this is how background notifications (content-available) should work on iOS, but on Android the notification doesn't start up the app only when the user 'touches' the notification is the app started. I think we could change this behaviour, for instance when you send a notification that doesn't contain any alert message. I think recently some more users have experimented with how to 'enable' background notifications on android. What do you think?

p.s. I like your email address 

On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett <[hidden email]> wrote:

Hi,

We’re trying to work out if the Aerogear Cordova push notification should start the app if the app is not started. If the app is in the background than we get the notification but if the app is not started up we don’t seem to get anything happening.

It seems to work OK when the app is in the foreground or background, just not when its not started up?

Should it work when the app is not started on both iOS and Android?

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
|  
Report Content as Inappropriate

Re: [Aerogear-users] Should the cordova push plugin start the App up if its not started?

Rob Willett
Erik,

Our focus has been on iOS and I realise that I should have stated this
in my mail message. Apologies.

Currently IOS does not start our app when the iPhone receives an
AeroGear notification with content-available = 1 in it AND (the app has
not been started OR is in the background). Basically we start the iOS
app, send a notification to check it works in the foreground. We then
swipe up to stop the app, send a new notification down, the new
notification is displayed BUT the AeroGear call back to handle the
notification is not called. If there is a a magic combination of alert
and content-available flags to make this happen we’d be happy to put
them in our code but we cannot see anything happening at all. We have
not checked Android for this behaviour, as for technical reasons we
<cough> I <cough> broke our last Nexus 5 phone on Friday and have not
replaced it yet. We’ll have a new one tomorrow.

What we have to do at the moment is check to see if the app has received
the silent notification as it will then make a callback to our server,
if there has been no callback wishing 60 secs, our server sends a full
notification with an alert in that is displayed by the device. The
downside to this method is that we lose the ability to clean out old
notifications using the silent notification AND a local cordova plugin,
local-notifications.

Our thinking is that both iOS and Android should start up in the
background when they receive a notification with an empty alert AND a
content-available = 1 flag AND the app is not running. We could use
Apple background-fetch to get 30 secs of processing and then shutdown
again. Unclear as to the system on Android.

We have also now seen that Apple very aggressively moves Apps from a
background state to a suspended state after not very long, which also
means that the app doesn’t respond to content-available = 1 flags. We
haven’t worked out how long this interval is, but its not hours. This
actually underscores the importance of handling the content-available =
1 flag working when apps are suspended or not started.

We are really starting to dislike Apples notification implementation.

Rob

The email address is list specific, we have our own mail servers so its
easy to simply use specific emails which we can then track. Its easy to
block as well if they get spammed.

On 14 Dec 2015, at 8:15, Erik Jan de Wit wrote:

> Hi Rob,
>
> Currently this is how background notifications (content-available)
> should
> work on iOS, but on Android the notification doesn't start up the app
> only
> when the user 'touches' the notification is the app started. I think
> we
> could change this behaviour, for instance when you send a notification
> that
> doesn't contain any alert message. I think recently some more users
> have
> experimented with how to 'enable' background notifications on android.
> What
> do you think?
>
> p.s. I like your email address
>
> On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett
> <[hidden email]
>> wrote:
>
>> Hi,
>>
>> We’re trying to work out if the Aerogear Cordova push notification
>> *should* start the app if the app is not started. If the app is in
>> the
>> background than we get the notification but if the app is not started
>> up we
>> don’t *seem* to get anything happening.
>>
>> It seems to work OK when the app is in the foreground or background,
>> just
>> not when its not started up?
>>
>> Should it work when the app is not started on both iOS and Android?
>>
>> 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
|  
Report Content as Inappropriate

Re: [Aerogear-users] Should the cordova push plugin start the App up if its not started?

Erik Jan de Wit
Hi Rob,

First of all let's be clear that the 'content-available' flag is a iOS implementation (part of the background fetch) and that it should start your app [1], but this is handled by the OS and there are some heuristics involved that is why you have to set the NewData [2]. So you can't be certain that it will 100% of the time, will start your app.

For android we don't have any mechanism atm to enable background notifications, although I think we could add it.


On Mon, Dec 14, 2015 at 9:36 AM, Rob Willett <[hidden email]> wrote:
Erik,

Our focus has been on iOS and I realise that I should have stated this
in my mail message. Apologies.

Currently IOS does not start our app when the iPhone receives an
AeroGear notification with content-available = 1 in it AND (the app has
not been started OR is in the background). Basically we start the iOS
app, send a notification to check it works in the foreground. We then
swipe up to stop the app, send a new notification down, the new
notification is displayed BUT the AeroGear call back to handle the
notification is not called. If there is a a magic combination of alert
and content-available flags to make this happen we’d be happy to put
them in our code but we cannot see anything happening at all. We have
not checked Android for this behaviour, as for technical reasons we
<cough> I <cough> broke our last Nexus 5 phone on Friday and have not
replaced it yet. We’ll have a new one tomorrow.

What we have to do at the moment is check to see if the app has received
the silent notification as it will then make a callback to our server,
if there has been no callback wishing 60 secs, our server sends a full
notification with an alert in that is displayed by the device. The
downside to this method is that we lose the ability to clean out old
notifications using the silent notification AND a local cordova plugin,
local-notifications.

Our thinking is that both iOS and Android should start up in the
background when they receive a notification with an empty alert AND a
content-available = 1 flag AND the app is not running. We could use
Apple background-fetch to get 30 secs of processing and then shutdown
again. Unclear as to the system on Android.

We have also now seen that Apple very aggressively moves Apps from a
background state to a suspended state after not very long, which also
means that the app doesn’t respond to content-available = 1 flags. We
haven’t worked out how long this interval is, but its not hours. This
actually underscores the importance of handling the content-available =
1 flag working when apps are suspended or not started.

We are really starting to dislike Apples notification implementation.

Rob

The email address is list specific, we have our own mail servers so its
easy to simply use specific emails which we can then track. Its easy to
block as well if they get spammed.

On 14 Dec 2015, at 8:15, Erik Jan de Wit wrote:

> Hi Rob,
>
> Currently this is how background notifications (content-available)
> should
> work on iOS, but on Android the notification doesn't start up the app
> only
> when the user 'touches' the notification is the app started. I think
> we
> could change this behaviour, for instance when you send a notification
> that
> doesn't contain any alert message. I think recently some more users
> have
> experimented with how to 'enable' background notifications on android.
> What
> do you think?
>
> p.s. I like your email address
>
> On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett
> <[hidden email]
>> wrote:
>
>> Hi,
>>
>> We’re trying to work out if the Aerogear Cordova push notification
>> *should* start the app if the app is not started. If the app is in
>> the
>> background than we get the notification but if the app is not started
>> up we
>> don’t *seem* to get anything happening.
>>
>> It seems to work OK when the app is in the foreground or background,
>> just
>> not when its not started up?
>>
>> Should it work when the app is not started on both iOS and Android?
>>
>> 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



--
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
|  
Report Content as Inappropriate

Re: [Aerogear-users] Should the cordova push plugin start the App up if its not started?

Rob Willett

Erik,

We are aware that the content-available flag is IOS specific. We have also read [1], [2] along with lots the information we can find on background notifications for iOS. I will not say we have read everything as we always find other information buried from Apple :)

If we use Table 1 in https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/index.html#jumpTo_12 to make sure we have the same terminology.

We can get the iOS Aerogear notification handler to respond to notifications with content-available = 1 when the app is in the background and the foreground. This works very well.

We cannot get the iOS AeroGear notification handler to respond to a notification coming in with content-available = 1 when the app is suspended. As far as we can see there is no difference in code for the Aerogear handler to at least wake up and process the event that comes in. The logic to handle the event once woken up is different as there are different flags set. We understand the differences to do with that.

Our understanding is that:

IF the iOS app is suspended AND a notification comes in with content-available = 1 
THEN
    Wake the app up
    Pass control to the app through the function defined as the callback in push.register(handleNotification , successHandler) 
    Within the notification handler callback, check to see if the content-available flags is set AND the event.foreground value set.
    Do something for short while such as get stuff from a server
     Finish with calling setContentAvailable() with NewData, NoData or Failed depending on what we have done. 
END 

Our code for handling the Aerogear notification is very simple, the first thing the Handler does is send a tiny HTTP POST call to our REST server so we can see that the notification handler is being called. Its easy enough to see the Xcode console output when the app is in the foreground or background, but more difficult to track what is happening when the app is starting up. We don’t want to put an alert on the screen as that changes the behaviour of the app, the same for doing a beep or a sound to let us know that the app is starting up. So a simple HTTP POST call to a server with a tiny bit of debugging information is fine. We can see in the server logs this REST call being made in the foreground and in the background but not when the app is suspended. We think we have written the code appropriately but cannot seem to get it to work (if it is supposed to).

So we would like to be able to call setContentAvailable(NewData) but we never get the Aerogear handler started to do so. Now we may have missed something vital but the code is pretty simple and works very well in the foreground and background, just not when the app is suspended.

So should the AeroGear notification handler be called when the iOS app is suspended as opposed to just in the background? If the notification handler should be called, then we’ll keep digging into our code as it’s a bug with our system. If the Aerogear notification handler is NOT called when the app is suspended and thats by design then we will work out a different mechanism. We are still unclear as to what the Aerogear behaviour should be.

Rob

On 14 Dec 2015, at 10:03, Erik Jan de Wit wrote:

Hi Rob,

First of all let's be clear that the 'content-available' flag is a iOS
implementation (part of the background fetch) and that it should start your
app [1], but this is handled by the OS and there are some heuristics
involved that is why you have to set the NewData [2]. So you can't be
certain that it will 100% of the time, will start your app.

For android we don't have any mechanism atm to enable background
notifications, although I think we could add it.

[1]
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/index.html#jumpTo_12
[2]
https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification

On Mon, Dec 14, 2015 at 9:36 AM, Rob Willett <[hidden email]

wrote:

Erik,

Our focus has been on iOS and I realise that I should have stated this
in my mail message. Apologies.

Currently IOS does not start our app when the iPhone receives an
AeroGear notification with content-available = 1 in it AND (the app has
not been started OR is in the background). Basically we start the iOS
app, send a notification to check it works in the foreground. We then
swipe up to stop the app, send a new notification down, the new
notification is displayed BUT the AeroGear call back to handle the
notification is not called. If there is a a magic combination of alert
and content-available flags to make this happen we’d be happy to put
them in our code but we cannot see anything happening at all. We have
not checked Android for this behaviour, as for technical reasons we
<cough> I <cough> broke our last Nexus 5 phone on Friday and have not
replaced it yet. We’ll have a new one tomorrow.

What we have to do at the moment is check to see if the app has received
the silent notification as it will then make a callback to our server,
if there has been no callback wishing 60 secs, our server sends a full
notification with an alert in that is displayed by the device. The
downside to this method is that we lose the ability to clean out old
notifications using the silent notification AND a local cordova plugin,
local-notifications.

Our thinking is that both iOS and Android should start up in the
background when they receive a notification with an empty alert AND a
content-available = 1 flag AND the app is not running. We could use
Apple background-fetch to get 30 secs of processing and then shutdown
again. Unclear as to the system on Android.

We have also now seen that Apple very aggressively moves Apps from a
background state to a suspended state after not very long, which also
means that the app doesn’t respond to content-available = 1 flags. We
haven’t worked out how long this interval is, but its not hours. This
actually underscores the importance of handling the content-available =
1 flag working when apps are suspended or not started.

We are really starting to dislike Apples notification implementation.

Rob

The email address is list specific, we have our own mail servers so its
easy to simply use specific emails which we can then track. Its easy to
block as well if they get spammed.

On 14 Dec 2015, at 8:15, Erik Jan de Wit wrote:

Hi Rob,

Currently this is how background notifications (content-available)
should
work on iOS, but on Android the notification doesn't start up the app
only
when the user 'touches' the notification is the app started. I think
we
could change this behaviour, for instance when you send a notification
that
doesn't contain any alert message. I think recently some more users
have
experimented with how to 'enable' background notifications on android.
What
do you think?

p.s. I like your email address

On Fri, Dec 11, 2015 at 6:59 PM, Rob Willett
<[hidden email]

wrote:

Hi,

We’re trying to work out if the Aerogear Cordova push notification
should start the app if the app is not started. If the app is in
the
background than we get the notification but if the app is not started
up we
don’t seem to get anything happening.

It seems to work OK when the app is in the foreground or background,
just
not when its not started up?

Should it work when the app is not started on both iOS and Android?

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

--
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
|  
Report Content as Inappropriate

Re: [Aerogear-users] Should the cordova push plugin start the App up if its not started?

Erik Jan de Wit
Hi Rob,

Yes it should also start your app when the app is not running or suspended, but it depends on heuristics of how much the user uses your app also something to keep in mind is that:

If the user rebooted his device and never launched the app since the reboot, the app will never wake up remotely and if the user killed the app manually from the app switcher, the app will also never wake up remotely.

I created a small app similar to your use-case where I do a http request when the content-available flag is set:

onNotification: function(event) {
    if (event['content-available'] === 1) {
        ajax({
            url: "http://192.168.0.30:8888/index.php",
            dataType: "text"
        })
        .then( function( result ) {
            console.log(result);
            push.setContentAvailable(push.FetchResult.NewData);
        });
    }

When I send a message with only content-available set like this:
~/w/t/background-fetch ❯❯❯ curl -u "73795055-123-462d-a6dd-4ad514c3afbf:123456-617f-47d4-a03b-f9ce89b7ec2b"  \
-v -H "Accept: application/json" -H "Content-type: application/json"  \
-X POST  -d \
'{
"message": {
"content-available" : true
}
}'  \
https://ups-me.rhcloud.com/ag-push/rest/sender

It sometimes calls my server, but not always and sometimes takes some time to activate the app. Again this is something that apple implemented the app is woken up / started by the os and there is nothing we can do about this.

You could also send a notification + content-available that way the notification can be used to start the app or if there was no network the app will react before the user 'touches' the app.

Hope this clears things up.


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

Re: [Aerogear-users] Should the cordova push plugin start the App up if its not started?

Rob Willett

On 15 Dec 2015, at 12:43, Erik Jan de Wit wrote:

> Yes it should also start your app when the app is not running or suspended,
> but it depends on heuristics of how much the user uses your app also
> something to keep in mind is that:

These heuristics seem arbitrary and undefined to us.

> If the user rebooted his device and never launched the app since the
> reboot, the app will never wake up remotely and if the user killed the app
> manually from the app switcher, the app will also never wake up remotely.

So basically the user has to start the app and never kill it. Just put it to the background and leave it there.

> I created a small app similar to your use-case where I do a http request
> when the content-available flag is set:
>
> onNotification: function(event) {
>   if (event['content-available'] === 1) {
>       ajax({
>           url: "http://192.168.0.30:8888/index.php",
>           dataType: "text"
>       })
>       .then( function( result ) {
>           console.log(result);
>           push.setContentAvailable(push.FetchResult.NewData);
>       });
>   }

> When I send a message with only content-available set like this:
>
> ~/w/t/background-fetch ❯❯❯ curl -u
> "73795055-123-462d-a6dd-4ad514c3afbf:123456-617f-47d4-a03b-f9ce89b7ec2b"
> \
> -v -H "Accept: application/json" -H "Content-type: application/json"  \
> -X POST  -d \'{"message": {"content-available" : true}}'
> \https://ups-me.rhcloud.com/ag-push/rest/sender
>
>
> It sometimes calls my server, but not always and sometimes takes some time
> to activate the app. Again this is something that apple implemented the app
> is woken up / started by the os and there is nothing we can do about this.
>
> You could also send a notification + content-available that way the
> notification can be used to start the app or if there was no network the
> app will react before the user 'touches' the app.

Mmmm this is similar to what happens to our code. We have had things happen in the background or suspended state (or what we thought was suspended), but its not clear whats going on. We haven’t had success recently hence our e-mail, we’ll keep looking into this and see if we can get anything clearer. One option was to look at doing an explicit background fetch every hour or so, to see if we can jiggle the app into a better state or to clear out local notifications. It may well be that we are pushing Apples idea of what notifications can or should do just too far and we should accept the limitations and work with them.

We had tried the content-available AND a notification but that didn’t seem to work. We’ll try again now we have a better understanding.

Thanks again.

Rob


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