Notifications: executing NOTIFICATION_DISPLAYED listener when app is stopped

[maskagency]

Hi all,

first of all, let me thank you for developing great ANEs for us. I am sure they help many of us to get the targets easier. Today I was trying to implement the Notifications ANE for Android application. I develop in FB 4.7, SDK 4.13.0, FP 15.0, AIR 15.0. Debug directly on device with Android 4.4. Most of the methods, properties and events work fine. I have tried other ANEs for local notifications, but yours really works the best. It plays sound, it plays song, it fires regardless the app status (running in FG, running in BG, stopped) and phone status (switched on or off).

BUT: when I call the function onNotificationDisplayed() for NOTIFICATION_DISPLAYED event, it fires only when application is running (either in FG or BG). Since on Android repeatInterval method does not work, I use the function to schedule next notification postponed by desired interval in seconds. This function works great if the app is running. But if the app is stopped, the function does never start, because this event seems not to wake up the app like NOTIFICATION_SELECTED event does. And here my setting of the next notification fails if user does not select the notification and clear the notifications list instead.

My questions:

1. Is it possible to get onNotificationDisplayed function work even when the app is stopped?
2. Can I provoke the app to wake app on NOTIFICATION_DISPLAYED event similarly as it happens on NOTIFICATION_SELECTED event?
3. Is there any other recommended way of regular repeating notifications once the last notification was displayed?

Keep going with these great ANEs and improve the support, which I am missing yet .o)

Thank you in advance

[marchbold]

Hi, Thanks for the great feedback! Always good to hear!

Regarding the events, I definitely see your problem here. There is quite a distinction between displayed and selected. We had taken the decision not to start the application when a notification is received as this is not best UX practice so when the application isn't running we can't get any information back to the application. We rely on the user interaction and then the selected event.

Would implementing the repeatInterval option solve your problem? You still won't get events until the user starts your application again via selection, but we could display new notifications on the set interval?

[maskagency]

Hi Michael,

thank you for your lightning feedback - this is kind of support every developer dreams of.

I understand the logic not to open app on NOTIFICATION_DISPALYED event very well and I absolutely agree, that it wouldn't be just what user may expect. I am just trying to find a way of relatively exact notification repetition and therefore DISPLAYED event firing in just in the time of last notification seemed to be the right way to go, hence SELECTED event always comes with some delay or never at all if user just clear notification from the list. So it is not the method to rely on. I am thinking of scheduling more notifications at once for a reasonable period of time in which it is very likely that user opens the app himself. And then just schedule next group of notifications for some period again.

Yes, definitely - implementing repeatInterval method for Android would solve the problem. And if it's possible to add some arguments behind interval:Int, it would be great. I mean not only to be able to set the interval in seconds, which is fine of course, but to be able to define for example the number, how many times the notification should be repeated would be great. I also saw somewhere the option to set individual day (notification will be fired in non-regular intervals, e.g. every Monday, Tuesday and Friday, but not on other days).

Thank you for considering these ideas in the next Notifications update. If so, I join to those willing to pay year subscriptions if support works like this.

Best regards

[marchbold]

Hi, This is definitely what we are aiming for!

I'll do some research into implementing the repeatInterval on Android and get back to you.

Regards, Michael