This post forms part of my tidbits series, a series of short posts outlining things that I have discovered whilst building various Double Negative products. These posts seek to:
- Remind me of technical intricacies (when I inevitably forget)
- Hopefully help others build top quality products
Re-register for APNS
When building products, I occasionally add
todo comments for non critical features.
When coming back to my todo list (remember - you do have to do that at some point ;) ), I encountered the following comment above a block of code related to APNS:
//todo - plausibly this can change.. update on server if it does
What I was doing was registering for APNS (with a call to
registerForRemoteNotifications) and upon receiving a response in my delegate method I was saving the received identifier to the server (such that I could send out the appropriate notifications). Upon successfully saving the APNS ID to the server I was setting a keychain boolean to indicate that I no longer needed to attempt to register the specific device for APNS.
Well.. it turns out that this is incorrect.
Upon re-reading the documentation, I encountered the following:
"If your app has previously registered, calling registerForRemoteNotifications results in the operating system passing the device token to the delegate immediately without incurring additional overhead. Also note that the delegate method may be called any time the device token changes, not just in response to your app registering or re-registering"
Now.. as the comment implies, I was always aware that APNS device IDs can change. Given that in practice is there is no negative impact in calling
registerForRemoteNotifications on every app launch, one should do so and then simply check as to whether the APNS ID passed to the
didRegisterForRemoteNotificationsWithDeviceToken delegate method differs to the one that the server is aware of. If it does, then you can inform the server of this change.
The result - you always have the most up to date APNS ID for a specific device saved on the server, whilst adding no uneccesary overhead.