App erhält doppelte Benachrichtigung mit GCM nach der Neuinstallation von [duplicate]

8

Ich versuche derzeit, GCM zu verwenden, um eine Benachrichtigung an den Benutzer zu senden, und momentan studiere ich noch, wie ich es maximieren kann. Fürs Erste verwende ich nur das Beispielprojekt, das in der Dokumentation hier zur Verfügung gestellt wird, und verwende das gcm-client-Beispiel, um daran zu arbeiten .

Mit diesem Projekt von Git habe ich versucht, eine Nachricht mit der erstellten Registrierungs-ID zu versenden von der App und ja es liefert erfolgreich die Nachricht.

Jetzt ist das Problem, 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 sie nur eine erhält, da die App bereits die Registrierungs-ID ändert.

Ich erwarte, dass die App zwei oder mehr doppelte Apps erhält, wenn ich die App auch aktualisiert habe, da sich die Registrierungs-ID gemäß der Dokumentation in der Dokumentation ändern kann.

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

    
KaHeL 05.12.2014, 11:42
quelle

3 Antworten

3

Aus der offiziellen Dokumentation:

  

So funktioniert die Deinstallation der Client-App-Registrierung

     

Eine Client-App kann nach der Registrierung automatisch aus der Registrierung genommen werden   deinstalliert. Dieser Prozess passiert jedoch nicht sofort. Was?   passiert in diesem Szenario ist:

     
  1. Der Endbenutzer deinstalliert die Client-App.
  2.   
  3. Der App-Server sendet eine Nachricht an den GCM-Verbindungsserver.
  4.   
  5. Der GCM-Verbindungsserver sendet die Nachricht an den GCM-Client auf dem Gerät.
  6.   
  7. 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.
  8.   
  9. Der GCM-Client auf dem Gerät informiert die GCM-Verbindung   Server, auf dem die Client-App deinstalliert wurde.
  10.   
  11. Der GCM-Verbindungsserver   markiert das Registrierungs-Token zum Löschen.
  12.   
  13. Der App-Server sendet a   Nachricht an GCM.
  14.   
  15. Der GCM gibt eine NotRegistered-Fehlermeldung an die   Anwendungsserver
  16.   
  17. Der App-Server sollte das Registrierungs-Token löschen.
  18.   

Hinweis   Es kann eine Weile dauern, bis das Registrierungs-Token vollständig ist   aus GCM entfernt. So ist es möglich, dass Nachrichten während Schritt 7 gesendet wurden   oben erhalten Sie eine gültige Nachrichten-ID als Antwort, obwohl die Nachricht   wird nicht an die Client-App geliefert. Schließlich die Registrierung   Token wird entfernt und der Server erhält einen NotRegistered Fehler,   ohne dass weitere Schritte vom App-Server erforderlich sind.

Es kann jedoch vorkommen, dass Sie immer noch die Benachrichtigung für die alte Registrierungs-ID erhalten, wie die Benutzer in anderen Fragen angeben:

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

  

Kanonische IDs

     

Wenn ein Fehler in der Client-App mehrere Registrierungen für den   Gleiches Gerät, es kann schwierig sein, den Status und die Client-App abzustimmen   könnte zu doppelten Nachrichten führen.

     

Durch die Implementierung kanonischer IDs können Sie diese leichter wiederherstellen   Situationen. Eine kanonische Registrierungs-ID ist das Registrierungs-Token von   Die letzte von der Client-App angeforderte Registrierung. Dies ist die ID   die der Server verwenden sollte, wenn er Nachrichten an das Gerät sendet.

     

Wenn Sie versuchen, eine Nachricht mit einem alten Registrierungs-Token zu senden, wird GCM   Bearbeiten Sie die Anfrage wie gewohnt, aber es wird die kanonische ID enthalten   das Feld registration_id der Antwort. Stellen Sie sicher, dass Sie das ersetzen   Registrierungstoken, das auf Ihrem Server mit dieser kanonischen ID gespeichert ist, z   eventuell funktioniert das alte Registrierungs-Token nicht mehr.

    
Baris Akar 05.08.2015, 09:18
quelle
2

@KaHel Wenn die Client App deinstalliert wurde, wird regId einige Zeit gültig sein, Sie haben Recht. Wenn die Client-App jedoch erneut installiert wird und Ihr Push-Server versucht, eine Nachricht mit der alten Registrierungs-ID zu senden, wird die Nachricht erfolgreich gesendet, der GCM-Server jedoch als Antwort cannonical_id . Und Sie sollten diese Antwort mit cannonical_id korrigieren. Wie beschreibe ich in diesem Post und es gibt keine große Dokumentation über 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.

    
Samik 06.12.2014 11:21
quelle
0

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

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

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

Es gibt ein Problem: Nur ein Gerät erhält Push-Nachrichten (wenn Sie sich bei zwei Geräten mit demselben Konto anmelden). So können Sie nach dem Start der Anwendung an den Server GoogleId + RegId + DeviceId senden.

    
Suvitruf 05.12.2014 11:50
quelle