Servicio de notificación push de Apple: múltiples tokens de dispositivo son válidos para el mismo dispositivo

Para que podamos enviar notifications de iOS a los usuarios, se produce el siguiente flujo: un usuario instala nuestra aplicación, se registra con APNS y envía el token de logging a nuestro server para utilizarlo más adelante para enviar notifications.

El process anterior se repite para cada dispositivo en el que el usuario instala nuestra aplicación; nos gustaría recibir notifications en todos sus dispositivos.

Además de esto, el process se repite cuando un usuario desinstala nuestra aplicación y la vuelve a instalar en el mismo dispositivo.

Cada vez que se repite el process obtenemos un nuevo token de logging distinto. Todo esto está bien, sin embargo, notamos que solo recientemente cuando se desinstala nuestra aplicación, el token de dispositivo sigue siendo válido después de que se reinstala y se genera un nuevo token. Entendemos que un solo token único puede existir para un dispositivo.

La documentation de Apple parece sugerir esto también ( https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW12 )

La forma de esta fase de confianza de tokens garantiza que solo los APN generen el token que luego honrará, y puede asegurar que un token que le fue entregado por un dispositivo es el mismo token que provisionó previamente para ese dispositivo en particular, y solo para ese dispositivo

Cuando se genera un token nuevo después de reinstalarlo y se lo envía a nuestro back-end, tenemos dos tokens de dispositivo que apuntan al mismo dispositivo y, como resultado, enviamos varias notifications a ese dispositivo. ¿Estamos mal entendiendo la documentation? Si es así, ¿cuál es la forma típica de lidiar con el escenario de reinstallation?

¡Gracias!

Acabamos de hacer una testing aquí. En nuestro dispositivo de testing iOS 8.4.1 después de volver a instalar nuestra aplicación, hemos recibido el mismo token, mientras que en iOS 9.1 siempre recibimos un token nuevo después de volver a instalarlo. Esto no sería un problema si APNS invalida los tokens de dispositivo anteriores, pero por lo que puedo decir que no lo hace. El resultado es que estamos enviando notifications duplicadas a nuestros usuarios al mismo dispositivo. ¿Tal vez demore algo de time para invalidar un token antiguo?

Decidimos hacer una solución del lado del server para esto y eliminar los tokens duplicates para un usuario de nuestra database. No es una solución buena y permanente, sino una solución a corto ploop para nosotros, ya que nuestros usuarios usan la aplicación generalmente en un solo dispositivo.

Sí, veo un único dispositivo con la misma aplicación (mi aplicación), que ha recibido diferentes APNS a lo largo de su corta vida, muchos de los cuales aún son capaces de recibir una notificación push (desde el server APNS de producción).

La solución fácil sería simplemente tener nuestro service de envío APNS de backend solo para honrar el último token de APNS recibido. Esto es factible, suponiendo que hay otra key primaria que es exclusiva de cada dispositivo iOS. Bueno, dado que UUID ya no está disponible, tenemos que confiar en la ID de proveedor de Apple. Ese problema con la ID de proveedor de Apple es que ese valor también puede cambiar con el time, así que asegúrese de tener en count eso.

Actualmente, solo enviamos notifications push a los dispositivos que tienen nuestro único miembro / ID de usuario. Esto es conocido por nuestra aplicación, una vez que un usuario ha iniciado session en nuestra aplicación. Entonces, podríamos usar nuestro miembro / ID de usuario, pero si un miembro / usuario tiene múltiples dispositivos, eso significa que si usamos el último valor de token de APNS como el que gana, que el mismo miembro NO podría tener múltiples dispositivos de iOS que reciban notifications de inserción (piense en iPad y iPhone, bastante común en estos días).

Entonces, dicho esto, cuando la administración superior quiere enviar notifications push a dispositivos en los que ningún miembro / usuario único realmente haya iniciado session, existe el riesgo de que las secuencias se crucen.

Tenemos el mismo problema que encontramos 2 tokens de dispositivo válidos para 1 dispositivo. Sin embargo, cuando intentamos verificar que "la desinstallation y la reinstallation generarían un token de dispositivo nuevo y el token de dispositivo anterior sigue siendo válido", obtuvimos el resultado opuesto. Es decir, se generó el token de dispositivo nuevo, pero el toke de dispositivo anterior se convirtió en inválido. Lo comprobé el 9/03/2016 y 10/03/2016.

No estoy seguro si Apple ha reparado parcialmente este error:

a) cuando la aplicación se desinstala y vuelve a instalar desde ahora, el dispositivoToken antiguo se vuelve inválido. (no hay nuevos problemas)

b) los tokens de dispositivo actualmente válidos seguirán siendo válidos. (los problemas anteriores no se pueden solucionar, el dispositivo seguirá recibiendo notifications múltiples de cada token de dispositivo válido)

Parece que tendremos que usar "identifierForVendor" para distinguir un dispositivo único: limpiar nuestra tabla de logging (y mantener el último deviceToken solamente) si vemos 2 deviceTokens comparten el mismo identificador ForVendor.

"Cada vez que se repite el process obtenemos un nuevo token de logging distinto".

¿Está usted seguro de eso? ¿100% seguro?

En mi experiencia, si desinstala la aplicación, luego la reinstalo y luego el 99,99% del time obtendrá el token del mismo dispositivo. Si está obteniendo un nuevo token de dispositivo único cada vez que desinstala y luego vuelve a instalar la aplicación, eso es algo que nunca había visto en múltiples años y múltiples aplicaciones. Por lo tanto, tal vez algo extraño está sucediendo.

Hay casos en que se generará un token de dispositivo nuevo pero son raros, ¿estás seguro de que no estás haciendo algo más entre la desinstallation / reinstallation?

PS hay un token de dispositivo diferente para las comstackciones de producción y las comstackciones de lanzamiento, elimine este factor de sus observaciones, es decir, asegúrese de que no está haciendo algo así como instalar una compilation de prod, desinstalarlo y volver a instalar una compilation de desarrollo o viceversa. Incluso si está haciendo esto, el número total de tokens de desarrollo único seguiría siendo solo dos (aunque solo uno es válido por entorno).