iPhone的推送通知-接受的方法

Question

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?

Answer 1

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).