I am developing a messenger app like whatsapp, it has to notify the server that the message is received, I am sending the status to server when didReceiveRemoteNotification is called. But when the app is not in foreground, it is calling only when the user taps on the notification. How to make server calls even when the app is in background or not running?
To receive a remote notification when your app is in background or suspended mode first your server should send special parameter in notification payload called content-available = 1. to learn more about that look the documentation: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/PayloadKeyReference.html#//apple_ref/doc/uid/TP40008194-CH17-SW5
Also turn on this switch in the project settings:
With this parameters when your app will receive a push notification it will be waken up for some small time to background mode and call didReceiveRemoteNotification. Don't forget to call completionHandler(<some enum parameter>) in the end of your task, or your process can be killed by iOS unexpectedly, for example when you're trying to perform async server requset. So when your async method completes call completionHandler closure argument of didReceiveRemoteNotification.
Actually there is no managed code can be run when your app is completely thrown away from the app switcher. As far as I know to perform that you should use VOIP push messages - but that kind of messages is only for apps with voice calls, like Skype or WhatsApp. This kind of apps has some code to perform even if they are completely turned off. iOS gives this ability to them to prepare to voice call. That's why all these messengers use Voice calls - to make instant delivery status for example. If you want that kind of interaction you should google more about VOIP. But your app should really have some voice calls function or it will be rejected by the app store.
Related
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.
Right now I have a framework that receives a silent notification, get the data from it (custom data) and translate it into a local notification to show the alert to the user (this is donde in didReceiveRemoteNotification:fetchCompletionHandler method). I have implemented this framework on an app and everything seems to be working correctly, silent notifications are being process when the app is in background and foreground. However, when the app is killed by the user or it is not running, I cannot receive notifications because of this:
Use this method to process incoming remote notifications for your app.
Unlike the application:didReceiveRemoteNotification: method, which is
called only when your app is running in the foreground, the system
calls this method when your app is running in the foreground or
background. In addition, if you enabled the remote notifications
background mode, the system launches your app (or wakes it from the
suspended state) and puts it in the background state when a remote
notification arrives. However, the system does not automatically
launch your app if the user has force-quit it. In that situation, the
user must relaunch your app or restart the device before the system
attempts to launch your app automatically again.
The reason I use this method for showing notifications is because the payload I sent to APNS has custom data with key-values that indicate how the notification must behave.
I've been doing some research and I found that Pushkit for VoIP can do the job. However, many post suggest that this can cause app rejection.
So my question is, how can I achieve receiving remote notifications even if my app was killed and considering that data in the payload has custom information to build the notification?
Silent push notifications are unreliable: they might get delayed, delivered in groups or even not delivered at all.
If you need to modify the content of the notification before presenting a banner for the user, you should use a Notification Service App Extension. You can also share some information between your app and this extension - using app groups or the keychain - if it needs something from your app to process the notification data.
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.
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.
I have a VoIP app, where the incoming call notification is very important.
The problem is, sometimes I don't get the push notification (even Apple said it's not guaranteed). But, I do have a mechanism to notice that an call is coming while the app is in the background.
So, what I want to do is.. still use Push Notification as the main handler for incoming call (because it handles the situation when app is closed). However, if the push notification failed to deliver and my app gets the call invite, I will raise a local notification, telling user that you have an incoming call.
My question is... how can I check if a notification is showing before I decide whether to fire a local notification?
AFAIK you can only detect the notification when the user taps on the banner OR if the app is open when the notification comes. So I can't see a way to detect if the notification has come yet or not. Just adding to the pain, push notification is famous for its unreliability.
There’s no API to get any information about the state of your notifications. Since you’re making a VoIP app, you have the option to have it get woken up for incoming data, which would let you post your “incoming call” notification whenever you need it—see the “Configuring Sockets for VoIP Usage” section here.