Notification - when app is killed - ios

I have implemented AWS SNS push notification service.
We have an issue which is explained below :
Scenario :
We are trying to save the notification message we receive as a part of requirement.
When the app is killed (swipe out from recent apps) we are able to receive notification, also we are able to save the notification message when we open the message directly from the notification panel it works fine,but when we open the app directly the notification message is not getting saved.
In short we are not able to know if we had received a notification message if we directly open the app rather than clicking the message from the notification panel.
Is this default behavior ? or is there any work around for this ?
Have looked into many posts on about Push Notifications but haven't seen any threads pointing to this scenario.

This is a normal behavior, and there is no workaround.
If your app is killed by the user, it won't be able to run ANY code before it's manually launched again.
If it's manually launched from a notification, this notification's payload will be handled by your AppDelegate.
On top of that, don't forget that Push notifications are Best Effort. That means that they are not reliable, they can be heavily delayed or never delivered at all. Don't rely on Push notifications to achieve any critical work.
If you need to keep a copy of your notifications in-app, keep them server side and fetch them as you would do with any other object.

In order to execute code when the app is killed by the user you need to implement VOIP using PushKit framework provided by apple.
VOIP push unlike regular push notification enables the app to become active even if the app is killed by user.

Related

How does WhatsApp bypass APNS restriction to display multiple push messages received while device was offline?

While working with APNS, I was able to have push notifications work flawlessly while device is online.
For any APNS push I send while device is offline, only the last one is received once the device is back online. This seems to be coherent with Apple's Store-and-Forward design.
However - I did notice, that when sending WhatsApp messages to an offline device, once this device goes online it receives all push notifications (one for each message). This is not something based on collapse identifier, but rather independent push notification for each message.
So how did WhatsApp do it?
Tried using Notification Extension and attempt to post multiple local notifications, but this also fails as extensions are not allowed to do that.
Instead of a normal push notification, use a Background Notification, which will not show anything visible, but wake up your app in background. Use this event, to make api call, get relevant data and generate multiple local notifications.
Note the following from the documentation when you implement application(_:didReceiveRemoteNotification:fetchCompletionHandler:) :
system calls this method when your app is running in the foreground or background
system does not automatically launch your app if the user has force-quit it
you must call the block in the handler parameter (fetchCompletionHandler) or your app will be terminated. Your app
has up to 30 seconds of wall-clock time to process the notification
and call the specified completion handler block
Apps that use significant amounts of power when processing remote notifications may not always be woken up early to process future
notifications
Please read relevant documentation completely before making ANY assumptions about how you think this should work.

Server sends data while iOS app is terminated

I have an application which has communication with a remote server. The server should push data into it using remote notification silently, and I need to get and store these data into a CoreData database. The user won't be aware of the whole process.
I can successfully get notified when the app receives a remote notification, while it is either in the foreground or background mode. However, I need to get data while the app is terminated as well.
I searched for the possible solutions. For example, this SO question was good if I don't tend to use silent notification. I also saw the PushKit capability, but I am not sure about the Apple Review result.
What is the possible solution?
If I want to use VoIP and PushKit to get notified when the app is terminated, would Apple reject my application?
If you’re not creating a VoIP app and you want your app to be in the App Store then the correct answer is: it is not possible. The only thing that can be done is adjusting your requirements in some way.
For instance you can send some notifications that will be visible for user in the Notification Center and wait until the user taps the notification or starts the app the usual way. Then the app will be able to do all the operations you need.
The delivery of push notifications is not guaranteed, so you should not rely on them to synchronise data.
For example, if multiple push notifications are sent while the device is offline, only the last notification is delivered when the device comes back online; the earlier notifications are lost.
When your app launches one of the first things it should do is check with your server for new data.

iOS Reachability when app not running

a simple question: is it possible to get a message, notification or similar when the internet connection is available when app is killed or not running?
For my purpose, I need a way to synchronize all my notifications because APNs can send only the last message.
EDIT:
I'm wondering how some apps (e.g. whatsapp) are able to sync their notifications when the internet connection is up. If I kill whatsapp, I can receive multiple notification when internet connection is reachable, but the APNS server provides only last message and, for this case, I'm not able to send silent notification. If I should develop a chat application, what are the best practices to work with Apple notifications?
If you send a push notification with a title, text, sound and/or badge property while the app is suspended (was killed / force closed), the device will still receive it, e.g. will show the text as a notification, play a sound and/or change the badge count.
However, your app won't be launched or woken up in the background in this case, so you have no way to handle the notification before the user taps on it. (See this question:
Will iOS launch my app into the background if it was force-quit by the user?)
So if the app was force closed by the user, your only option is to send a notification to be displayed as it is and if the device is offline, only the last notification will be received and displayed by the device.
For more control, you could use silent push notifications to implement "push-to-sync". In this case, the push notification only signals that there is new data to be fetched. The app (if not force closed) loads the data from the server then and triggers local notifications with the right data in the right order. But this won't work, if the app was force closed.
Apple push notifications have a lot of restrictions, so you won't be able to implement a perfect solution. In my opinion, it's fine if the user gets only the last notification when the device gets online after being offline for a while. At least he is informed that there is a new message and after opening the app, he can see the other new messages too. For the "push-to-sync" scenario, I would say that the user has no right to expect that the app works as desired, if he force-quits it.
Push notifications were never intended to be used in the way they are used by a lot of apps by now. E.g. they shouldn't contain sensitive data such as a chat message. They were intended to inform the user that there is new data for the app, so he can launch it to see the new data. E.g. instead of sending the actual chat message text a push notification should just contain the text "You have a new message". Then, you don't have the problem you described. Of course this is a terrible solution in terms of usability.

Callback function for push notifications while app is killed (titanium iOS)

I cant find a clear answer about this in the Titanium documentation. Is it possible to directly respond to a push notification while the app is killed ?
I know that the callback is called when you open the app trough the push notification. but is there a way to respond when the app is opened manually ?
I tried to use remote-notification as UIBackgroundModes, but this only helps for paused apps.
My goal is to show the push notification in a in-app message center.
You should never rely on push notifications to deliver you payloads, they are too limited for that. If the user receives 5 push notifications and opens the app via the app icon, you will never receive any of the payloads. If he opens the app via one of those notifications you will only receive that payload.
You could use silentpush:
http://docs.appcelerator.com/platform/latest/#!/guide/iOS_Background_Services-section-37539664_iOSBackgroundServices-SilentPush
But the app should always query a back-end to get the actual data. That's how WhatsApp does it as well, as you can see when you open it via a notification it will then still fetch the message(s) form the server.

How can I handle unread push notifications in iOS?

I have a iOS 5.1 application that registers to the APNS service to receive notifications. The register is successful and I receive the notifications correctly. The problem comes when I try to handle the notifications.
Once the application is running, the method didReceiveRemoteNotification in the AppDelegate is called correctly and so the notification is handled as intended. This, however, only happens when the application is running on the foreground.
However, when the application is running on the background or is simply stopped, that method is not called. I've read that you should add some lines to the method didFinishLaunchingWithOptions method to obtain the notification from the userInfo dictionary, and handle it. This works just fine, but ONLY when the application is opened by clicking on the notification at the Notification Center. This means that if you open the application by clicking on its badge, or simply by changing context if you were running it on the background, the app never realises that a notification came in. Additionally, if more than one notification was received, we can only handle one of them at once by clicking on the Notification Center, which is a pain :-)
Is there any way to read the pending notifications in the Notification Center? I know there is a way to flush them using the method cancelAllLocalNotifications but I haven't found a way to just read them. And I really need to handle all of them. I thought of implementing a communication protocol with the third-party notification server to retrieve the information again when the application comes to the foreground, but since the information is already in the operating system I would find it strange if it's impossible to access it somehow.
So, does anybody know a way to do it? Thanks in advance.
When a push notification arrives and the user clicks 'cancel', your app has no way to read that push notification again. You have to implement a separate functionality (most probably on server-side) to fetch a list of notifications sent to this device.
For example, if a chat functionality is provided in your app and you send chat messages via push notifications then you should also keep chat messages on the server. If a user clicks 'Cancel' on any push notification then that chat message will not be displayed on the iOS device. In that case when a app comes in foreground later, you make a call to the server and fetch all the past chat messages (sent via push notification).
Ok, So a possible solution would be to have another database table with the messages in with a 'read' flag and a messageID field? Which by default the read flag is NO, then when the app successfully reads this and displays, it updates the flag to YES?
And with only 256 bytes to play with, what sort of ID field length would be necessary?
Edit,
Executed this plan and its working successfully.

Resources