search

urbanairship / android-samples

DEPRECATED - Use https://github.com/urbanairship/android-library instead
Other
33 stars 39 forks source link

UA overriding my GCM implementation #22

Closed humblerookie closed 8 years ago

humblerookie commented 8 years ago

I have both UrbanAirship and my own GCM integration set up. Of late a lot of my app users have been sending me NotRegistered tokens, these users have not uninstalled the app.

On further investigation, I figured that UA was using its own GCM implementation and at times the InstanceId token obtained by my implementation and that of UA don't match. In such a scenario my token is the invalid one whereas UA has the valid one . This I think is most likely because that UA Instance Id request happens post mine. This has started I believe since you guys updated to using the Instance Id architecture (6.2+).

This is creating a lot of non addressable user base and impacting my end user experience.

I need to be able unify these two GCM registration processes for which I need a callback from UA when it obtains the instance id token.

Could you guys fix this immediately.

PS: In case you are wondering of my use case, we work with a few other external integrations(Chat etc) which need gcm tokens. Additionally as a part of our practice we prefer maintaining a copy of push tokens on our server.

rlepinski commented 8 years ago

Did you follow http://docs.urbanairship.com/platform/android.html#multiple-gcm-senders ? Also, are you using two different GCM sender ID/project numbers (one for UA, one for your chat) ?

humblerookie commented 8 years ago

Thanks. We aren't using multiple GCM Sender IDs. However using a single InstanceIdListenerService seems to have resolved the NotRegistered token issue. Now even though at times the tokens are different but both seem to be valid tokens and are addressable. Can this part reflect in documentation under Implementing your own GCM instead of the Multiple GCM Senders.

rlepinski commented 8 years ago

We can definitely change the title of that section. Glad it fixed your issue :)

humblerookie commented 8 years ago

@rlepinski Thanks. But wouldn't it be cleaner don't you think if a GCM registration callback could be invoked in the register method of UA's GCMRegistrar class? This would notify the corresponding app of the same and would lead to only a single GCM implementation within an app. This would seem a naive request but do give it a thought. Apologies for reopening this issue accidentally.

rlepinski commented 8 years ago

@humblerookie We are open for suggestions. What were you thinking?

The InstanceIDListenerService class is required for instance ID registration. It does more than just notify the app when the token have been refreshed, so we will need to keep that. We can broadcast out when tokens need to be refreshed and when we have a new token. However that would still require apps to have a broadcast receiver and then they would probably also need an intent service to process the message. I guess that would give an app more options on how to implement multiple GCM receivers.

humblerookie commented 8 years ago

@rlepinski Sorry for the delayed response but this is precisely what's needed.

After the fix I implemented, I encountered the exact opposite scenario where my server had the updated token where as urbanairship had an outdated one, this happened on my test device and has not yet been observed in production(Keeping an eye for the same). I'm not sure I'd be able to reproduce this issue but I do believe you agree to the fact that we might need a single registration mechanism. The one you suggested works and seems to provide enough capability for developers to be incorporate their own secondary actions post registration.