iOS: Correct foreground behavoir following Apple guidelines?

[santekotturi]

I recently moved my app over to the #ios10 branch of the local-notification plugin. In previous versions of iOS docs and in the current ones, Apple says that if the app is in the foreground, localnotifications won’t fire; arguing that the app should be responsible for handling any events/behaviors when its open. Localnotifications then only trigger when the app is not-active. (I differentiate between "non-active" and "background" because some apps using the background thread permission are still active/alive in the background). Here I'm discussing an app whose thread has been put to sleep by the OS because it is not open and does not use the background-thread permission.

From Apple:

If the app is foremost and visible when the system delivers the notification, the app delegate’s application(_:didReceive:) is called to process the notification. Use the information in the provided UILocalNotification object to decide what action to take. The system does not display any alerts, badge the app’s icon, or play any sounds when the app is already frontmost.

However, with the #ios10 branch, local notifications are shown as banners when my app is "frontmost" aka "active".

Is this the correct intended behavior of the plugin?

Info: de.appplant.cordova.plugin.local-notification 0.8.5-dev "LocalNotification" └── cordova-android@6.1.0 └── cordova-ios@4.3.1 Cordova CLI: 6.4.0 Ionic CLI Version: 2.1.17 Ionic App Lib Version: 2.1.7 ios-deploy version: 1.9.0 ios-sim version: 5.0.13 OS: macOS Sierra Node Version: v4.6.2 Xcode version: Xcode 8.2.1 Build version 8C1002

[santekotturi]

Although, the docs I've been reading are all for UILocalNotification which Apple has deprecated in iOS10 so perhaps I should not worry my app being rejected for this?

This goes beyond concerns about having my app rejected by Apple because I'm currently providing the user instructions via a small audio recording. If the app is active, then my app plays the sound file via the Media player. If its not active, then the sound file gets played as the Notification sound. Currently, both are playing but with small lag between them which sounds horrible.

If the plugin has changed behavior and now triggers local notifications when the app is active, I'm happy to rip out the Media Player code and just use the Notification sound, I would just like to know if this is intended and will stick around?

[rwillett]

Our app uses the ios10 branch and had no issues going through the Apple store review and we use the local notifications plugin a lot.

I cannot speak for what the intended behaviour of the plugin was as I didn't write it.

Rob

[santekotturi]

@rwillett thanks for the quick reply!

Do you see the badges and sounds trigger for notifications scheduled while your apps are active?

Something must have changed with the plugin or with iOS (although I can't test this because previous plugin versions dont work on iOS 10) as this has definitely changed (I spent many hours hacking my way around how this used to work...dynamically figuring out which instructions had been sent in the background and if to use the Media player or not... and how to handle this differently on Android on which notifications trigger regardless of foreground or background)

[rwillett]

We don't set the badges or play sounds. We have a complex notification system and its impossible to keep the badges set to the right value, e.g. if we delete a notification from the drawer whilst the app is in the background, we don't get any trigger so we can't decrement the badge counter. This makes it annoying for the user as the badge count is wholly different to what it should be. We actually want the badge count to be a red blob indicating 1 or more notifications. That would do us!

Our notification system assumes the Apple or Google Notification system is basically just a transport layer to get data to us and we use the local notification system to display and manage the interface. We had so many issues with badges, sounds, silent notifications on IOS and different OS's we gave up and managed it all ourselves. Our notification sub-system is pretty big now, it has all sorts of different paths through the code depending on IOS version and Android and which notification provider we use, its pretty difficult. e.g. just clearing out the local notifications has five different versions.

We have done the same as you have, we have worked our way through this step by step to get the right result. We wrote a series of test cases and we work through them one by one.

[santekotturi]

Sorry, I meant Banners, not badges.

My app is active and the notification is triggered. This specifically did not happen previously and I had to hack my way around it. Nice to know I'm not the only one.

Do you see this same behavior?

[rwillett]

Yes, we get the banners, we like them so no need to hack around for us.

How did you stop them appearing?

Rob

[santekotturi]

I like them to, they're new and unexpected. ¯_(ツ)_/¯

Can't get them to stop.

-Sante

[rwillett]

If this is finished suggest you close the thread down.

Rob

[santekotturi]

@rwillett it still seems bizarre to me that this plugin behaves in a way that Apple says it shouldn't.

The system does not display any alerts, badge the app’s icon, or play any sounds when the app is already frontmost.

[rwillett]

The plugin works the way that IOS 8, 9 and 10 expect it to behave. Apple has changed the behaviour of notifications over the versions of IOS.

I'm unconcerned as I think it does what its supposed to.

Rob

[santekotturi]

Where do you see this?

From the docs published in Oct of 2016:

With local notifications, your app configures the notification details locally and passes those details to the system, which then handles the delivery of the notification when your app is not in the foreground. Local notifications are supported on iOS, tvOS, and watchOS.

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/

The way this plugin works makes my life easier, I don't have to deal with managing both foreground and background, however, its unclear to me how this working given it's not supposed to and if a minor ios update will break this.

[Edited for typos]

[rwillett]

Should this be closed now?

[santekotturi]

it's still the case that local notifications are triggered and shown when the app is in the foreground and is still the case that it isnt clear whether this correctly implements Apple's notification API. I know Apple recently made a lot of changes to this API so perhaps this is new, however, I cannot find any Apple docs supporting this.

[rwillett]

I think the behavior is correct. Unless somebody indicates otherwise, I'm closing this thread.

[katzer]

@skotturi @rwillett

With my last commit you have to set foreground: true or assign a priority greater than zero to see the alert on all platforms when the app is in foreground.

The property is similar to silent but it only applies to when the app is in foreground.