Push Notifications mit dem Google-Cloud-Messaging-Service

Push me if you can

Arne Limburg, Lars Röwekamp


Warum sollte eine mobile App in regelmäßigen Abständen bei einem Server nach neuen Daten fragen, wenn der Server dies der App bzw. einer bestimmten App-Instanz auch proaktiv mitteilen kann? Für uns alle sind Push Notifications für E-Mails oder Social-Media-Apps mittlerweile das Normalste der Welt. Trotzdem finden sich immer noch sehr viele Anwendungen am Markt, die regelmäßig den Server nach neuen Daten fragen – und das wieder und wieder. Möchte man in einem solchen Szenario einigermaßen aktuelle Daten garantieren, muss das Pollen des Servers entsprechend häufig passieren. Und das ist teuer. Sehr teuer.

Warum verwendet also nicht jede Anwendung automatisch Push Notifications? Der Knackpunkt liegt in der Kommunikation. Zwar kennt der mobile Client den Server und kann diesen direkt aufrufen, umgekehrt ist dies aber nicht so einfach möglich. Was fehlt, ist ein Bindeglied zwischen Client und Server, das die Vermittlung der Notifications übernimmt und – wie wir später sehen werden – auch noch einiges darüber hinaus.

Neben etlichen proprietären und teilweise plattformübergreifenden Push Notification Services, wie zum Beispiel Urban Airship [1] oder Pushwoosh [2], liefert auch Google eine einfach zu integrierende Variante eines solchen Vermittlers namens Google-Cloud-Messaging-Service.

Google-Cloud-Messaging-Service

Google bietet mit dem Google-Cloud-Messaging-Service (kurz: GCM [3]) genau einen solchen Mittler an und ersetzt damit den im Sommer 2012 als deprecated markierten Dienst Google Cloud to Device Messaging (kurz: C2DM). Die Idee ist denkbar einfach: Jede Anwendung verfügt über eine eindeutige ID (Sender-ID), die vorab via Google APIs Console [4] erzeugt wurde. Einmal auf dem Device gestartet, verbindet sich die Anwendung bzw. die Instanz der Anwendung mit dem GCM-Service und registriert sich dort mithilfe dieser ID (Abb. 1, [a]). Google bietet dafür ein eigenes API, das sich als Library in die App einbinden lässt. Im Gegenzug erhält die Anwendung vom GCM-Service eine eindeutige Registration-ID (Abb. 1, [b]). Diese ID sendet die App nun wiederum an den Server, der für die Aktualisierung der App-Daten zuständig ist (Abb. 1, [c]). Und schon ist eine – wenn auch indirekte – 1:1-Verbindung zwischen Anwendungsinstanz und Server hergestellt. Neben der eigentlichen Registration-ID können auch zusätzliche Parameter, wie zum Beispiel ein Username, an den Server geschickt werden, die es dem Server erleichtern, einen Account eindeutig zu identifizieren und einem b...

Push Notifications mit dem Google-Cloud-Messaging-Service

Push me if you can

Arne Limburg, Lars Röwekamp


Warum sollte eine mobile App in regelmäßigen Abständen bei einem Server nach neuen Daten fragen, wenn der Server dies der App bzw. einer bestimmten App-Instanz auch proaktiv mitteilen kann? Für uns alle sind Push Notifications für E-Mails oder Social-Media-Apps mittlerweile das Normalste der Welt. Trotzdem finden sich immer noch sehr viele Anwendungen am Markt, die regelmäßig den Server nach neuen Daten fragen – und das wieder und wieder. Möchte man in einem solchen Szenario einigermaßen aktuelle Daten garantieren, muss das Pollen des Servers entsprechend häufig passieren. Und das ist teuer. Sehr teuer.

Warum verwendet also nicht jede Anwendung automatisch Push Notifications? Der Knackpunkt liegt in der Kommunikation. Zwar kennt der mobile Client den Server und kann diesen direkt aufrufen, umgekehrt ist dies aber nicht so einfach möglich. Was fehlt, ist ein Bindeglied zwischen Client und Server, das die Vermittlung der Notifications übernimmt und – wie wir später sehen werden – auch noch einiges darüber hinaus.

Neben etlichen proprietären und teilweise plattformübergreifenden Push Notification Services, wie zum Beispiel Urban Airship [1] oder Pushwoosh [2], liefert auch Google eine einfach zu integrierende Variante eines solchen Vermittlers namens Google-Cloud-Messaging-Service.

Google-Cloud-Messaging-Service

Google bietet mit dem Google-Cloud-Messaging-Service (kurz: GCM [3]) genau einen solchen Mittler an und ersetzt damit den im Sommer 2012 als deprecated markierten Dienst Google Cloud to Device Messaging (kurz: C2DM). Die Idee ist denkbar einfach: Jede Anwendung verfügt über eine eindeutige ID (Sender-ID), die vorab via Google APIs Console [4] erzeugt wurde. Einmal auf dem Device gestartet, verbindet sich die Anwendung bzw. die Instanz der Anwendung mit dem GCM-Service und registriert sich dort mithilfe dieser ID (Abb. 1, [a]). Google bietet dafür ein eigenes API, das sich als Library in die App einbinden lässt. Im Gegenzug erhält die Anwendung vom GCM-Service eine eindeutige Registration-ID (Abb. 1, [b]). Diese ID sendet die App nun wiederum an den Server, der für die Aktualisierung der App-Daten zuständig ist (Abb. 1, [c]). Und schon ist eine – wenn auch indirekte – 1:1-Verbindung zwischen Anwendungsinstanz und Server hergestellt. Neben der eigentlichen Registration-ID können auch zusätzliche Parameter, wie zum Beispiel ein Username, an den Server geschickt werden, die es dem Server erleichtern, einen Account eindeutig zu identifizieren und einem b...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang