App empfängt doppelte Benachrichtigung mit GCM nach der Neuinstallation

Question

Ich versuche derzeit, GCM zu verwenden, um eine Benachrichtigung an den Benutzer zu senden, und derzeit studiere ich noch, wie ich es maximieren kann. Fürs Erste verwende ich nur das Beispielprojekt, das in der Dokumentation here bereitgestellt wird, und ich benutze das gcm-Client-Beispiel, um daran zu arbeiten.

Jetzt mit dieser project from Git Ich habe versucht, eine Nachricht mit der Registrierungs-ID, die von der App erstellt und ja die Nachricht erfolgreich übermittelt.

Jetzt ist das Problem, dass, nachdem ich die Anwendung deinstalliert habe. Nachdem ich es neu installiert habe, wird es eine neue Registrierungs-ID erzeugen, wobei ich es zusammen mit dem vorherigen auf einem Server speichern kann, außer dass ich die vorherige Registrierungs-ID nicht markieren kann, da die Deinstallation passieren kann, wenn der Benutzer kein Internet hat Verbindung. Danach sende ich eine Nachricht an zwei Registrierungs-IDs, die die ID ist, bevor ich die App und die ID nach der Neuinstallation der Anwendung deinstalliere. Was passiert, ist, dass ich zwei Push-Nachrichten erhalte, obwohl ich erwartet habe, dass es nur einen bekommt, da die App bereits die Registrierungs-ID ändert.

Ich erwarte, dass die App zwei oder mehr doppelte Apps erhalten könnte, wenn ich auch die App aktualisiert habe, da die Registrierungs-ID bei der Aktualisierung möglicherweise geändert wird.

Jede Problemumgehung, die ich tun kann, um diese doppelten Nachrichten zu behandeln?

Answer 1

Von der offiziellen Dokumentation:

How uninstalled client app unregistration works

Eine Client-Anwendung automatisch abgemeldet werden kann, nachdem er deinstalliert wird. Dieser Prozess passiert jedoch nicht sofort. Was in diesem Szenario passiert ist:

1. Der Endbenutzer deinstalliert die Client-Anwendung.
2. Der App-Server sendet eine Nachricht an den GCM-Verbindungsserver.
3. Der GCM-Verbindungsserver sendet die Nachricht an den GCM-Client auf dem Gerät.
4. Der GCM-Client auf dem Gerät empfängt die Nachricht und erkennt, dass die Client-App deinstalliert wurde. Die Erkennungsdetails hängen von der Plattform ab, auf der die Client-App ausgeführt wird.
5. Der GCM-Client auf dem Gerät informiert die GCM-Verbindung Server, dass die Client-App deinstalliert wurde.
6. Der GCM-Verbindungsserver markiert das Registrierungs-Token zum Löschen.
7. Der App-Server sendet eine Nachricht an GCM.
8. Das GCM gibt eine NotRegistered-Fehlermeldung an den Anwendungsserver zurück.
9. Der App-Server sollte das Registrierungs-Token löschen.

Hinweis , dass es eine Weile dauern könnte für das Registrierungstoken zu sein, um vollständig von GCM entfernt. Daher ist es möglich, dass Nachrichten, die während Schritt 7 oben gesendet wurden, eine gültige Nachrichten-ID als Antwort erhalten, obwohl die Nachricht nicht an die Client-App übermittelt wird. Schließlich wird das Token der Registrierung entfernt und der Server erhält den NotRegistered-Fehler , ohne dass weitere Schritte vom App-Server erforderlich sind.

Allerdings kann es offenbar sein, dass Sie immer noch die Meldung für das alte Registrierungs-ID erhalten, wie Nutzer in anderen Fragen angeben:

• Android GCM and multiple tokens
• Unregistering and re-registering for GCM messages causes two regId's to be valid. Is this as intended?
• Do old GCM tokens live on even after an uninstall?

Für dieses Problem gibt es eine Funktionalität namens "kanonische IDs":

Canonical IDs

Wenn ein Fehler in der Client-Anwendung mehrere Anmeldungen für die gleichen Gerät auslöst, kann es schwierig sein Zustand und die Client-Anwendung in Einklang zu bringen könnten sich mit doppelten Nachrichten beenden.

Die Implementierung kanonischer IDs kann Ihnen dabei helfen, leichter von diesen Situationen zu erholen. Eine kanonische Registrierungs-ID ist das Registrierungs-Token von die letzte von der Client-App angeforderte Registrierung. Dies ist die ID , die der Server beim Senden von Nachrichten an das Gerät verwenden sollte.

Wenn Sie versuchen, eine Nachricht mit einem alten Registrierungstoken, GCM wird Prozess wie üblich die Anfrage zu senden, aber es wird die kanonische ID in die registration_id Feld der Antwort enthalten. Achten Sie darauf, das Registrierungs-Token , das auf Ihrem Server gespeichert ist, durch diese kanonische ID zu ersetzen, da schließlich das alte Registrierungs-Token nicht mehr funktioniert.

Answer 2

Nach der Neuinstallation erhalten Sie neue RegId und prev nicht mehr gültig. Also, auch wenn Sie Push an beide RegIds senden, wird nur der letzte empfangen.

Sie können Logik für Konten in der Anwendung implementieren.

Zum Beispiel, wenn Benutzer in Anwendung anmelden Sie senden seine GoogleId + RegId. Nach Neuinstallation der Anwendung und Neuanmeldung aktualisieren Sie einfach RegId auf dem Server. Sie können also nur einen RegId für jeden Benutzer haben.

Es gibt ein Problem: Nur ein Gerät wird Push-Nachricht erhalten (wenn Sie sich in 2 Geräte mit demselben Konto anmelden). Sie können also nach dem Start der Anwendung den Server GoogleId + RegId + DeviceId senden.

Answer 3

@KaHel Wenn die Client-App deinstalliert wurde, wird regId während einiger Zeit gültig sein, Sie haben Recht. Wenn die Client-App jedoch erneut installiert wird und der Push-Server versucht, eine Nachricht mit der alten Registrierungs-ID zu senden, wird die Nachricht erfolgreich gesendet, aber der GCM-Server setzt cannonical_id als Antwort. Und Sie sollten diese Antwort mit cannonical_id korrigieren. Wie beschreibe ich dies at this post und es gibt keine große documentation about cannonical_id. I.e. Sobald Sie cannonical_id vom GCM-Server erhalten, sollten Sie sofort alte reg_id durch einen neuen Wert ersetzen. Dadurch können Sie nicht viele RegIds für einen Client erstellen, nur eins zu eins.