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

Mon Dec 14 05:58:31 EST 2015

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 
> <rob.aerogear at robertwillett.com
>> 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
>>> <rob.aerogear at robertwillett.com
>>>> 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
>>>> Aerogear-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>>  Erik Jan
>>> _______________________________________________
>>> Aerogear-users mailing list
>>> Aerogear-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>> _______________________________________________
>> Aerogear-users mailing list
>> Aerogear-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>
>
>
> -- 
> Cheers,
>     Erik Jan
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151214/fcb0bdcb/attachment-0001.html 