Search code examples
androidiospushandroid-c2dmurbanairship.com

Registering APID's with Urbanairship though device or server


I have an application setup where both Android and IOS devices are configured with UA libraries. The issue I'm having is in understanding the purpose of some of these steps or if I am duplicating work. I'll explain the process I have setup first.

  1. On application start-up the devices seem to be registering with UA successfully.

  2. The devices then post their apid's and information to my own service (on a different server).

  3. My server stores the device id information and everything required for push.

  4. For every push enable device that comes in, my server performs a subscribe call to UA. "/api/device_tokens/" for IOS and "/api/apids" for Android.

  5. This server is designed so that when it wants to send push notifications, it queries the list of device id's and tokens it has and sends this information to UA's push api service. "/api/push/" etc...

There is a step which is confusing me however. What is the difference between step 1 and step 4. Am I basically registering the device tokens and information twice? Once from the devices and once from my own server?

In short, what is the difference between the registration that the Devices perform (as per their relevant libraries) and the registration from my server to UA's api "/api/device_tokens"

Also, where does this come into play: https://docs.urbanairship.com/display/DOCS/Server%3A+Subscription+API


Solution

  • The term "subscriptions" in the UA system refers to recurring content subscriptions, such as with a magazine-type app. Whereas "registration" is a device registation in the system. The apps do register themselves with the UA servers every time the app is started up (more-or-less). There is generally not a need to re-register the devices before every push, however it should not be harmful to do so. If you are maintaining a list of device ids on your servers, you should be using the Feedback API regularly to prune your list. This will return a list of "deactivated" device ids, so you are not storing unaddressable device ids in your system.

    You do not need to worry about the Subscriptions API unless your app is selling subscriptions.