[ikhare]

Seems like the author has only worked with iOS.

On Android push notifications are done through GCM (Google Cloud Messaging), when it's sent your application gets a callback (Intent). So it is up to the application to decide what to do with it, whether it is to show a notification or do something else entirely. So on Android you have a pretty good idea that the the user is actually getting a notification. Jelly Bean and up you can also do very rich notifications with images and actions built right into it.

On iOS when a remote push notification is received there is no indication sent to the application at all. The only way the application knows something has happened is if the user actually opens the notification.

I haven't programmed on windows phone, so I am not sure how much an app developer knows that a user is viewing a live tile or not. Maybe someone who's built one can chime in.

Overall it seems to me, that what the author is describing is Android, where the app developer has at least some feedback as to whether a user is seeing the notification (albeit not an exact: user has seen x notif).

Edit: Wording

[benjamincburns]

> On iOS when a remote push notification is received it there is not indication sent to the application at all.

I'm not well versed in push notifications, but I thought this was part of the value that a company like Urban Airship would provide?

[Groxx]

Only if you use their inbox-like thing, which will still not tell you deliverable rate, it just ensures the recipient can see a list of all attempts.

The actual push notification itself is entirely untrackable unless the recipient actually taps on it, or it is received while your app is running. IIRC you can read out the application's badge number, but that only shows you what the most-recently-received notification was (if it set a badge value), it implies nothing about any intermediate ones. There is no way to list the notifications, nor count them. You can do this with local ones you generated yourself, but not ones pushed to the device.

While someone is actively in your app, you do get a method called that gives you the notification as it arrives - which is handy, because the system entirely mutes it (doesn't go into the notification center, doesn't appear at the top of the screen). You can do that to do a negative tracking system ("they didn't receive this, don't count it in the stats"), or to show it yourself.

[rkoz]

The usual approach is to track acks or callbacks driven via user actions on the server-side. Adding a "guaranteed delivery" QoS will involve queuing, waiting and retrying on non-ack timers - and do so without abusing users' trust in your app.

[rubyrescue]

no it's a limitation of iOS - which you could argue is by design. the app is just not notified, no matter if it's urban airship or your_custom_app

[sumukh1]

Regardless, the application has to be opened to get information about click through/context.

The push notification can have a payload that your app uses when the app is opened via the notification.