Before you start integrating the Notificare SDK into your mobile application, chances are you are already using another Push Messaging provider. Luckily, Notificare offers you the option to import user devices and their Push Tokens from a CSV file. The import process is pretty straight-forward and will allow you to retain important data for each user device, like tags and user data fields. It also allows you to keep devices linked to a specific user.
However, there are a couple of important limitations and caveats that we would like to emphasize.
Push Tokens
A Push Token is a unique identifier that is used by the various platforms to deliver messages to a specific app on a specific device. They come in various shapes and sizes, but will be independent of the Push Messaging Provider, be it Notificare or otherwise.
Nevertheless, it is important to understand how these Push Tokens are being used by each Push Messaging SDK that is included in your app.
Scenarios for different SDKs
Let's assume you have 2 versions of your app, version 1.0 which includes the ACME Push SDK, and an enhanced version 2.0 which uses the Notificare SDK. We also assume all Push Tokens exist in both Push Providers.
Let's highlight the differences between iOS, Android and Web Push when a message is sent to the different versions of the app.
iOS
In iOS, there is a standard implementation of Push Messaging by the platform itself. Messages that are sent to a Push Token will appear in the lock screen and notification center, regardless of the SDK being used.
Whenever a notification is sent from Notificare to version 1.0 of your app, the message will appear in the notification center, but it will not be handled by the app for displaying rich content or handling actions. It will also not show up in stats, open rates, etc. in Notificare.
The other way around, if a notification is sent from ACME to version 2.0 of your app, it will show in the notification center, but the Notificare SDK can not handle it, so the SDK will tell your app it came from another Push Provider, still allowing your app to handle it in a different way. It will also not show up in stats in Notificare.
Android
In Android, there is no standard implementation of Push Messaging, so it depends on your app and the Push Provider's SDK what happens.
Whenever a notification is sent from Notificare to version 1.0 of your app, the message will not appear in the notification manager, and it will also not be handled by your app. It will also not show up in stats and open rates.
The other way around, if a notification is sent from ACME to version 2.0 of your app, it will be recognized by the Notificare SDK as coming from another Push Provider, still allowing your app to handle it. If not handled, it will also not show up in the notification manager.
Web Push
In Web Push, the situation is similar to Android. There is no standard implementation of Push Messaging, so it depends on your app and the Push Provider's SDK what happens.
Whenever a notification is sent from Notificare to version 1.0 of your web app, the message will not show as a notification to the user, and it will also not be handled by your web app. It will also not show up in stats and open rates.
The other way around, if a notification is sent from ACME to version 2.0 of your web app, it will be recognized by the Notificare SDK as coming from another Push Provider, still allowing your web app to handle it. If not handled, it will also not show up in the notification manager.
Firebase Push Tokens
One important caveat is importing from Firebase. Firebase will not provide you with the actual iOS APNS tokens, so it is impossible to import iOS devices from Firebase into other Push Providers. If you do import these tokens, sending push to them will deactivate them as invalid tokens. Also, they will never register again with that token from the Notificare SDK, so they will linger on in your Notificare's app and never be reachable anymore.
Filtering devices
As the overview above shows, using a mix of Push Providers and SDKs leads to unwanted behaviour in the different platforms. iOS devices will run the risk of receiving duplicate messages, Android and Web Push devices run the risk of not receiving messages.
To prevent this from happening, you should filter your audiences whenever you send a push in both Push Providers. In Notificare, you could do this in 2 ways:
Filter on App Version
When sending messages, you can filter devices that have an older version.
The best result you will get by importing the devices into Notificare with the exact same app version set in the CSV file.
Of course, you can also filter to include only the newer version, whatever suits your situation best.
Filter imported devices
When a device is imported in Notificare, it is flagged as imported until it registers itself again with Notificare.
This means that you can use this device property to filter out devices that have not migrated yet to Notificare (i.e, they are still running the older version)
Not Importing ?
Perhaps the easiest and safest way to migrate is not importing devices at all. When users upgrade the app, they will register in Notificare anyway, so you can reach them in the new version.
Older versions can still be reached by the old provider, so you could send one final message just after your updated app version went live on the app stores. After that, only new app versions will receive notifications (through Notificare).
Conclusion
As demonstrated in this blog post, importing Push Tokens from another provider to Notificare is possible, but not without limitations. It can be done effectively when planned ahead and executed with these limitations in mind.
Most importantly, you understand the implications and limitations of importing data and be sure to test the migration with known devices before launching your new app version.
As always, if you need assistance or have any questions, we are available via our Support Channel.