It is widely known that you can disable the reception of Apple notifications from the applications that allow it. But does anyone know if the disabling is made locally (ignoring the notifications Apple sends to the app), or does Apple stop sending you notifications from it's servers?
I've finally discovered in depth how Apple Push Notifications work: if you disable the notifications on one app, Apple does not know of this behavior instantly, so it keeps sending notifications to the device whenever they are created. These notifications will try to reach your app, but instead they will be sent back to Apple with an error code. That feedback will be sent to your servers (the ones that order Apple to distribute your app notifications). You will have to check that information regularly so that if one device has returned a certain amount of "errors", it means that the user has disabled the notifications (or has even uninstalled the app)
Further information: Local and Push Notification Programming Guide
Related
If the device is offline for some period, APNS will only keep the last notification and re-send it when the device is back-online. My question is, if Parse or any other Push serivces provider has a feature to re-send the notifications that I missed during the offline period. If not, is there any way I can achieve this with current Parse features?
You can configure parse to send notifications when they became available https://www.parse.com/tutorials/ios-push-notifications
When a user's device is turned off or not connected to the internet,
push notifications cannot be delivered. If you have a time sensitive
notification that is not worth delivering late, you can set an
expiration date.
Also check here
I have a few problems listening to incoming invitetions,
1) onInvitationReceived is not called when an invite is received when app on (i registerInvitationListener to my gamesClient in onSignInSucceeded)
2) no notification will pop up when the app isnt open aswell.
i was trying to add plusClient in the BaseGameActivity but still no change, is something need to be done to make the app listen to invites that im missing?
do i need to publish it to see invite notifications?
sending invites to someone that doesnt have the app should send him to google play?
Invitations are delivered via push notification (like GCM), so several factors may influence in the system's ability to deliver them. If you don't get invites through the notification bar, there is something wrong with the network or with the device. Push messages are somehow not getting through to it. Can you send a gtalk ping to the device, and does it appear on the notification bar?
Once you do get to a state where notifications via notification bar are showing, but are not able to receive them in your app, I'd check:
(1) Are you registering an anonymous listener as an invitation listener? That's problematic. Take a look at this tip.
(2) Are you waiting a sufficient amount of time? Sometimes it may take > 30sec before a notification arrives, depending on network connectivity. With good network it should be faster, though.
After the latest update of Whatsapp on Widows Phone Store, I have noticed that now, once they show the toast of message on my device, then they mark the message as delivered (notify the sender that the message has reached my device).
After I let the toast notification go away, I switched off all my data connection and opened Whatsapp and found that that particular message in my app. This is happening consistently on both wp7 and wp8 device. This was happening even when I had disabled background agent! Beside background agent of an app does not run all the time.
So my questions is, on windows phone platform, where the app is not allowed to run in background all the time, how is Whatsapp application getting those messages? Is it using any particular api/hack to get(in app) those messages when it's not on foreground.
The question you have asked has two parts: one for wp7 and the other for wp8. I will anser each one by one.
Windows phone 7
Based on my research, I have found that whatsapp is still using audio streaming api on wp7 devices to stream messages in the background i.e. when the app is not running. Whatsapp was criticized of using this API as constantly using this causes battery drainage as well as hampers the music experience of the user.
Windows Phone 8
Once whatsapp moved to wp8 they stopped using the Audio API and moved to VOIP API. Note that whatsapp doesn't use VOIP for any purpose but their manifest shows usage of VOIP api, and after reading many articles I have come to the conclusion that they are using this API to activate background agent and pool messages in the background.
While sending raw push of type 4, the background agent for VOIP is activated in which you can practically do anything from reading the payload to establishing a new socket connection subjected to restriction on usage of certain APIs
I have also found out that even if a user disables bg agents for an app some essential bg agent still continue to run for eg bg agents in audio stream API and VOIP API.
I hope this answers your question.
Go through this link
Push notification for Windows Phone
What will help you to understand is
The server maintains a maximum of 30 notifications (regardless of type) for each URI. Once the limit of 30 is reached, all new messages sent to the server are discarded until the device reconnects and the queue can be flushed.
In windows phone there is something called raw notifications, these are different from push notifications, push notifications display a notification, but raw notifications triggers a background task that can run under certain api restrictions for about 15 seconds. (I think, I'm not sure about the time duration), I think what whatsapp does is that it downloads the message and saves it in a local database which is maintained in the device. When whatsapp is opened it will read the local database and also sync with the server.
Please correct me if I am wrong.
We are developing a Newsstand app, and are currently working on the push notification to let users know a new issue has arrived. From the ambiguous Apple documentation it looks like we will need to send a separate push notification for each user that downloaded the app; each notification should contain a unique device token for each app instance.
The section titled Trust Components seems to imply that you can use the device token or the certificates to authenticate your push notification, but it also implies you need both.
Is it correct that we will need to send out a separate push notification for each installed instance? Can we really not send one push notification and have Apple notify all the users of the app that a new issue has arrived?
Short answer is YES the statement you made is correct.
You have to send out push notification to each device token which must be stored in your server (provider). The preferred way to send multiple notification is to not make multiple connections but reuse one to send multiple notifications. Below is the paragraph from Apple Doc
You should also retain connections with APNs across multiple
notifications. APNs may consider connections that are rapidly and
repeatedly established and torn down as a denial-of-service attack.
Upon error, APNs closes the connection on which the error occurred
Does APNS Feedback Service accounts all the reasons that could cause notifications delivery failure. There can be multiple reasons for failure like
a. The user has uninstalled the application.
b. The device is switched off for a longer duration.
c. The device does not have internet connection.
The apple doc on "Feedback Service" says that
"If a provider attempts to deliver a push notification to an application, but the application no longer exists on the device, the device reports that fact to Apple Push Notification Service. This situation often happens when the user has uninstalled the application"
This seems to suggest that APNS only invalidate the devices which have uninstalled the application. Can anyone please clarify if my assumption is correct?
How many times does APNS attempt to deliver the notification before it blacklist the device in the feedback service?
As you have correctly stated, the Feedback service will only return device tokens that have uninstalled the app.
Regarding situations b and c:
b) and c), taken from the Quality of Service section in the official Push Notification guide it states the following:
Apple Push Notification Service includes a default Quality of Service
(QoS) component that performs a store-and-forward function.
If APNs attempts to deliver a notification but the device is offline,
the QoS stores the notification.
It retains only one notification per application on a device: the last
notification received from a provider for that application.
When the offline device later reconnects, the QoS forwards the stored
notification to the device. The QoS retains a notification for a
limited period before deleting it.
I believe this answers those queries; in relation to "how many attempts before being blacklisted" - I sincerely doubt you will find any specific numbers for this. (else people would use them as workarounds)
After completing the delivery of a message, I would highly recommend connecting to the feedback service, seeing if any tokens were rejected and then immediately removing these from your database. Hope this helps!