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).
Related
I have an ios app.
In which i have multi user account.So multiple user can Login.
When one user see other user profile and if that user is also online i want to notify him.
I can't get how to implement it.
If i have to continuously check some flag value on server if someone has checked their profile or how can i handle it?
Remote notifications is the way to do it. The logic on when and who has to be notified can be handled at the server.
You may have seen lots of apps asking for permissions to send notification. The downside being if the user denies that permission.
Polling from client side can also be one of the methods which can be used and but would require the client to do most of the computation.
So all in all, its a call you got to take considering what you are building.
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.
In my app, for first time push notification registration, I call didRegisterForRemoteNotificationsWithDeviceToken and save the device token in persistence as well as update my server list for device token. Now afterwards if somebody turns the push notification settings off from iPhone Settings how can I determine it from my app so that I can remove the device token from server as well. I know APNS provides a feedback list, but other than that is there a way to determine it in App programmatically? Thanks for any help!
I believe you do not want to manage tokens this way.
Your app should always be asking Apple for an APNs token. You should always then send that token to your own server, likely associating the token with your user (if you have one). You do this because the token could change, so you want to make sure you always have up-to-date tokens.
The Feedback service will tell you (actually, you poll it at some interval of your choosing) which tokens have become invalid. At this point, you remove the tokens from your server-side database. To be clear, you need a server-side process that polls Apple's feedback service and then updates your server-side database.
You will not receive feedback about invalid tokens until you try to send a notification using the token. The notification will (I believe) be accepted by Apple when you send it, but when Apple discovers it's for an invalid token, the message is dropped, and the token is added to your feedback.
Now, if the user of your app accepts push notifications when your app first asks about it, but later turns off notifications via the Settings app for your app, you will not get any feedback about it. What happens, near as I can tell, is that any notification you send to that device will be sent to the device, but the OS drops it, honoring the user's ultimate choice in the Settings app for your app and notifications.
Finally, there is an API you can call in your app to get a bitmask of which kinds of notifications are enabled for your app on the device. Here's a method I wrote for this purpose; adjust as needed:
+(BOOL)acceptsPushNotifications
{
UIRemoteNotificationType mask = [[UIApplication sharedApplication] enabledRemoteNotificationTypes];
return (mask & UIRemoteNotificationTypeAlert) == UIRemoteNotificationTypeAlert;
}
But I would not recommend using this to decide if you app should tell your server to delete the token from your database. That's not how the whole APNs system is intended to work... I believe.
The app is for a Gym. I would like it to allow individual push notifications to be sent from trainers to their clients. Is this possible? Would registering the app with user name and trainer after downloading have any effect?
If your goal is to initiate a push message from one iphone app and have it delivered to another iphone, then yes it is possible. Typically in this type of scenario, your application would upload an APN device token to a backend server for each client that logs into your application. The backend server would then associate that token to that particular user. If you want to be able to handle multiple devices per user, then you will want to also include a unique device id with this registration.
When the trainers are using the application, they would tell the backend server to send a push message to one or more clients. Your backend would then retrieve the tokens associated with the clients to which the message is to be sent and use the retrieved token to send the message(s) to Apple's APN interface.
Remember the APN token is specific to the mobile device and application.
In the Apple documentation you can find the following sentence :
An application should register every time it launches and give its provider the current token. It calls registerForRemoteNotificationTypes: to kick off the registration process.
So when I implemented the push notification in my app I had to register the device, and I did what they said in that documentation: registering every time a user launch my app.
The token that I receive from the APNS is always the same for a given user.
My question is: why do I need to register everytime if the APNS gives me always the same token?
I read somewhere than a token can change if a user swipe his iPhone or the app. Is it the only case?
Thank you !
The token that I receive from the APNS is always the same for a given user.
Except it isn't, basically because there's nothing you can hang onto as being "a user" in the iPhone setup. The device token is always the same for each app for each device. So different apps on the same device get different tokens. The same app on two different devices gets two different tokens.
The crucial thing to note, and this is mentioned in the APNS guide, is that a user may back up their apps, settings, everything. Then they can drop their phone down the toilet. When they get their replacement phone, they can take their backup and restore it onto their new phone. Bingo - same app, same user, different device, and different token.
As far as your app is concerned, nothing has changed since the last time it ran - it doesn't know that it's actually running on a different device now. The only way it knows is because it asks for the 'current' device token, and hey presto it's a different token to last time.
You can choose to cache the token and check it against the token you just received (e.g. save it in your NSUserDefaults) - that way you don't have to communicate it back to the server unless it has changed since the last run, but you absolutely do have to check, otherwise your users will come complaining that they don't get push notifications any more since they replaced their phone.