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.
Related
I have a messaging service that I use for regular push notifications. For example, when one user sends a message, the other user receives a push notification with that message. I have noticed if the phone is on wifi and 3g / 4g, and the app is killed (and the screen is locked), the notification will be received. If the device is only on wifi and the app is killed (and the screen is locked), the notification is not received.
My assumption is that in order to conserve battery, the device disconnects from wifi after a certain time, and that is why push notifications are not received.
But when I use VOIP push notifications, the situation is different. Even if the app is killed and the device is on wifi (and the screen is locked), the notification will be received. So what does this mean? How is phone receiving this notification, if it disconnects from wifi?
What am I missing here?
Furthermore, to add to Sivajee Battina's answer, this is what you can read in the guidelines:
There are many advantages to using PushKit to receive VoIP pushes:
The device is woken only when VoIP pushes occur, saving energy.
Unlike standard push notifications, which the user must respond to before
your app can perform an action, VoIP pushes go straight to your app
for processing.
VoIP pushes are considered high-priority notifications
and are delivered without delay.
VoIP pushes can include more data than what is provided with standard push notifications.
Your app is automatically relaunched if it’s not running when a VoIP push is received.
Your app is given runtime to process a push, even if your
app is operating in the background.
So the third point confirms that your standard push notifications can be delayed in certain circumstances, while VoIP push notifications will always be delivered instantly.
Also, have a look at this question for reasons why standard push notifications are delayed or dropped.
You are almost correct in this - this is how voIP works. Excerpted from Apple Docs:
In the past, a VoIP app had to maintain a persistent network
connection with a server to receive incoming calls and other data.
This meant writing complex code that sent periodic messages back and
forth between the app and the server to keep a connection alive, even
when the app wasn’t in use. This technique resulted in frequent device
wakes that wasted energy. It also meant that if a user quit the VoIP
app, calls from the server could no longer be received.
Instead of persistent connections, developers should use the PushKit
framework—APIs that allows an app to receive pushes (notifications
when data is available) from a remote server. Whenever a push is
received, the app is called to action. For example, a VoIP app could
display an alert when a call is received, and provide an option to
accept or reject the call. It could even begin taking precursory steps
to initiate the call, in the event the user decides to accept.
I am trying to make an app where you could send a warning to other users which then will trigger an alarm on the receivers phone.
So my plan is to send a silent warning to the receiver, which then triggers sounds and vibrations on the receivers phone from the app.
So basically my question is, is it possible to open an app on a phone through a silent push?
This is done with push notifications in iOS. See Apple's description.
Apps must be configured appropriately before they can receive local or remote notifications. The configuration process differs slightly on iOS and OS X, but the basic principles are the same. At launch time, your app registers to receive notifications and works with the system to configure that notification support. Once registration is complete, you can start creating notifications for delivery to your app. Your app then handles these incoming notifications and provides an appropriate response.
But note that it is up to the receiving user to determine how he wants to be alerted.
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.
It is widely known that:
app doesn't receive push notification if it is in background or offline mode (app gets it once after user's action: tap on notification or app icon).
Apple push Notification service keep only ONE last notification when device is offline. Once device is connected to internet, APNs sends the last notification.
How to solve this?
very latest notification that just reached the app (not device) must reflect the actual number of notifications that are not implemented in the app yet. So, then I can download from the server last n notifications and implement them in the app at any time.
The question is:
How the server knows what notifications were implemented in the app, and which one not?
Notifications must be per device. Why? For instance, notification "remove object from Core Data" must be implemented in every device. Because only one user can be logged in on multiply devices at time.
You should track the state of the task (delete record or whatever your app needs to do) on the server and have the client report back when the task is done. Then flag the task as done.
Don't use push notifications as a reliable delivery method for your tasks, you will fail. Use the notifications as complementary part of your setup.
So for example when your app receives a notification, it can sync with the backend, to retrieve the tasks flagged as not done, execute them and then let the backend know that it's done.
The first solution I can think of for the incoming call notification is Apple's Push Notification service. However, it is not guaranteed.. there's a relatively high chance it may get lost.. and in a VoIP app, the incoming call notification is so important that I can't afford to miss it too often...
Thus, I followed the tips and enabled the Background Mode to keep the app alive and listening to any incoming call invite. By right, I should just show local notification when the app gets the incoming call invite. This works pretty well when the app is in background/inactive. HOWEVER, when user kills the app manually, no code will get executed, so the app won't get any incoming call invite in such a condition... And because of this particular scenario, I still have to rely on remote push notification.
What I'm trying to achieve is.. waiting for remote notification first, if it arrives, then do not show local notification anymore. If it's lost, then show local notification so that user will always get notified.
The problem is... I have no way to tell if a remote notification has arrived.
I want to know what is the best practice to handle incoming call notifications for a VoIP app?
From appleDoc Apple Developer Docs. (Updated link)
In iOS 8 and later, voice-over-IP (VoIP) apps register for UIRemoteNotificationTypeVoIP push notifications instead of using this method. Using push notifications eliminates the need for a timeout handler to check in with the VoIP service. Instead, when a calls arrives for the user, the VoIP service sends a VoIP push notification to the user’s device. Upon receiving this notification, the device launches or wakes the app as needed so that it can handle the incoming call.
Just play a very long duration audio when a APNS comes.