Apple push notification - Feedback Service
How do you know when the user uninstalls your application? so that you can remove their devicetoken from the push server.
You simply don't know. You can grab device identification string which is presumably identical for the same application token string, and track if a token has changed for the specific device. So you can update the device token with a new one, but there is no way to find out if your app was removed from a device.
Update:
You are correct. You can get this information from the feedback service, however there is a caveat. You need to have at least one push-messaging enabled application installed to maintain persistent feedback connection. I'd mark these customers as potentially non-existant, but I wouldn't remove these folks from a customer DB. Who knows why your push message can be rejected. Your device may be in inconsistent state and you remove your subscriber forever. If you have 10k zombie clients it is a pocket change for a DB. If you lost 100k clients you have much serious problems than that.
Related
We are developing an iPhone application that allow users to send messages to others via Apple Push Notification Service when the target user have installed our application or SMS when haven't.
We want to get notified immediately when our app is uninstalled so that we can decide how to send the message to the target user.
We find the APNS feedback server have a long time delay that doesn't agree with our requirement. So we use another way: when our server recorded the target user have installed our application, we send him message via APNS, if he haven't read the message in 30 minutes, we believe that he has uninstalled the application, so we send the message via SMS.
Is there any way better?
As Oleg said, there is no way to accurately detect if your app was uninstalled.
The APNS feedback service returns a timestamp and a push token for messages it was not able to deliver. Sometimes, this indicates an uninstallation but it can also simply indicate a user that was simply offline at that moment. The Feedback service does have some lag so can not be used for time-sensitive intel gathering.
Based on your requirements, I'd say you're doing it right.
One suggestion that may or may not work for you would be to include a link (via url handler) to your app when you resort to sending an SMS. If it makes sense for the user to return to your app, clicking on that link should launch the app and you'll have a trace on your server if you make a simple call. If, however, after sending the SMS the user is not detected as coming back into the app, chances are highly likely that the app was indeed uninstalled or that the user is offline for an unusually long amount of time which may require some other type of action on your part.
I’m looking at the designing and developing a service for Push notifications, and am trying to understand the order of processing in the Apple App when it comes to Registering for Push Notifications and storage of the Token.
What I’m developing currently is a service that allows subscription to individual changes that happen to particular processing on our server.
When they happen, the phone user may receive a message of type “A”, “B”, or “C”.
The phone user has to “subscribe” to each of these types individually if they want them. Otherwise they can ignore it and not subscribe.
So User Fred, on Phone #4, starts our App, logs in, and then has the ability to turn on or off subscriptions to events that are sent as Push Notifications.
So I need to tie details from Fred’s login, to Phone #4’s device Token, with particular subscriptions.
So my particularly important questions are.
When the Phone connects to the APNS server to get its device token, is this automatic on app start? Or can this be initiated at a later step? Ie, after going through a loging screen on our app.
Can we (are we allowed to) store the device token on the phone in the App's data store?. Or, should the App be connecting to the APNS server every time the app is run?
How does the App know if it as already called the APNS server and retrieved a token, or as above, should it call the APNS server time the app is run?
Can we (are we allowed to) store the token in the App’s memory as it runs, so we can properly subscribe and unsubscribe for particular messages?
We need also to be able to list all the subscriptions that a particular user may have across all their devices so the user can remove old devices (if they change phones). Or can we rely upon data back from calls to the APNS – when we attempt to push a notification - to inform us that a device token is no longer valid?
Or is there some better way of tying this all together?
When the Phone connects to the APNS server to get its device token, is
this automatic on app start? Or can this be initiated at a later step?
Ie, after logging into our app.
After the app has started, the app gets the token by calling registerForRemoteNotificationTypes. This will prompt the user for permission, and call a callback with the device token if permission is granted.
Can we (are we allowed to) store the device token on the phone in the
Apps data store?. Or, should the App be connecting to the APNS server
every time the app is run?
You'll need to build an APN provider, which is a web server that calls apple to send the pushes. The thing to do with the token is post it to your server that uses the APN provider. The app doesn't connect to APNS, your provider does, and it does it when it has pushes to send.
Can we (are we allowed to) store the token in the App’s memory as it
runs, so we can properly subscribe and unsubscribe for particular
messages?
You can keep the token on the client, but you don't really need to. It's your web service that calls APN, so it needs to be kept aware of your users' subscription prefs.
We need also to be able to list all the subscriptions that a
particular user may have across all their devices so the user can
remove old devices (if they change phones). Or can we rely upon data
back from calls to the APNS – when we attempt to push a notification -
to inform us that a device token is no longer valid?
APN also provides a feedback service that you call in batch which returns the device tokens that are no longer valid. Not only can you use this service, but you must. Apple will get mad at apps that repeatedly send to no longer valid devices.
Or is there some better way of tying this all together?
Yes! Parse.com provides a nice wrapper on the client code, does the provider and feedback service, abstracts the idea of single devices to the idea of a "channel" which sounds like just what you need for multiple notification types A, B, C, provides a super-easy step by step setup, and loads of other useful cloud services for iOS. (I'm not affiliated, but a big fan).
We have two versions of our app (free and paid-for), and we want to support push notifications for both of them, and they are both using the same server.
So far we can update the user data on the server, so if the user changes from the free to the paid version, we update the server and the user will start receiving push notifications to the paid-for version.
However, I've seen updates for apps in the past, that had a negative impact on the paid-for version, and people have downgraded to the free version.
It's a rare situation, however how can this be handled?
The logic we use to register the token is as follows:
We store the token and a confirmation in the user settings (AppDefaults).
When the user enables push notifications, we check if the app have these settings registered (notification_token and notification_token_confirmed_by_server).
If we have a token, but it's not confirmed by the server (as in the first time you enable push notification for the app) we send the token to the server along with what version of the app it is.
So if the user have both the paid for version on their phone, and the free version, and choose to use the free version for whatever reason, after upgrading the paid-for version, what is the best way to handle a scenario like this?
I saw one app called Draw Something, that was asking the user to uninstall the free version, but I think that's a terrible solution (you can't 'ask' your user to do anything and base your logic on that!)
The solution in the end was to send push notifications to the app version the user last signed in with.
You could alternatively update the server every time the user makes a request assuming you include the application version in the request, however this becomes "chatty" so in the interest of not hitting the database constantly it's a small price to pay
I saved users' device tokens in database.
At the time to push notifications,I loaded all device tokens from database,then in a loop,I send push message to one user one time.
Now there are about 300 thousands users,I want to know,is there any other better way?
Thanks
There is no better way with Apple. You need to send the same message to each device token. Services like Parse.com will mask this behind the scenes dirty work for you by letting you broadcast to groups of devices, however you still need to subscribe each device token to the group initially...
So, to answer your question, no there is no better way, you must loop and send to all device tokens :(.
How to test feedback.sandbox.push.apple.com? Everything goes right, but I receive empty list.
How to make it consider the device token as inactive?
I installed the application to iPhone using Xcode, received some push notifications, then removed it from iPhone and send some more notifications. But even on the next day feedback.sandbox.push.apple.com returns just empty set.
Issues with Using the Feedback Service
If you remove your app from your device and then send a push notification to it, you would expect to have the device token rejected, and the invalidated device token should appear on the feedback service. However, if this was the last push-enabled app on the device, it will not show up in the feedback service. This is because deleting the last app tears down the persistent connection to the push service before the notice of the deletion can be sent.
You can work around this by leaving at least one push-enabled app on the device in order to keep the persistent connection up. Just install any free push-enabled app from the App Store and you should then be able to delete your app and see it appear in the feedback service.
source:
http://developer.apple.com/library/ios/technotes/tn2010/tn2265.html#TNTAG34
I far as I found, Apple push notification feedback service doesn't work properly on sandbox mode. You should try it on ad-hoc or production mode.