Push-Notifications mit hybridem Beigeschmack

Abstract
Auf dem Veranstaltungsportal Watogo (www.watogo.ch) können Benutzer mittels Umfragen mit Ihren Freunden über öffentliche wie auch private Veranstaltungen diskutieren und dabei passende Termine finden. Der Benutzer möchte bei neuen Aktivitäten auf seinen Umfragen sofort informiert werden. Dazu wird der jeweilige Push-Notification Mechanismus auf der entsprechenden Mobile-Plattform verwendet.

Dieser Artikel zeigt die Hürden der Realisierung im Zusammenhang mit dem hybriden Architekturansatzes durch Apache Cordova (https://cordova.apache.org/) und der Cloud Plattform Amazon Web Services (http://aws.amazon.com/de/) sowie die Lessons Learnt dieser plattformübergreifenden Push-Notification Implementierung.

Übersicht – beteiligte Systeme und eingesetzte Technologien
Die folgende Grafik zeigt die beteiligten Systeme und dient als Basis für den folgenden Artikel.

Watogo Push-Notification Systeme

Grün = Watogo, Rot = Amazon Dienst, Blau = proprietärer Benachrichtigungsdienst

Folgende Systeme sind für die Implementierung von Push-Benachrichtigungen beteiligt:
Watogo Mobile-App realisiert mit Apache Cordova für die Zielplattformen Android und iOS. Die Apps kommunizieren für die plattformspezifische Dienst-Registrierung direkt mit ihrem entsprechenden Push-Notification Service und für die applikationsspezifische Interaktion mit dem Applikationsserver von Watogo via HTTP. Um native Unterstützung im Bereich Push-Notifications zu erhalten wurde das offizielle Push-Plugin (https://github.com/phonegap-build/PushPlugin) eingesetzt.
Watogo Web-Client realisiert mit AngularJS und Twitter Bootstrap sowie diversen JQuery-Plugins. Der Web-Client wird nicht benachrichtigt – er löst Benchrichtigungen über den Applikationsserver aus.
Watogo Application Server realisiert mit Java, läuft auf einem Tomcat in einem Amazon EC2 Container und bietet für verschiedene Clients eine HTTP RESTful API an.
Amazon Simple Notification Service (SNS) fungiert als Fasade für das Senden von Push-Benachrichtigungenen und bietet diverse Möglichkeiten für das Verwalten von Push-Endpunkten (u.A. Mobile, E-Mail, HTTP, …). Der SNS ist die einzige Schnittstelle für das Auslösen von Benachrichtigungen. Er bindet die plattformspezifischen Benachrichtigungsdienste an. Der Dienst bietet verschiedene Konstrukte für die Gruppierung von plattformspezischen Endgeräten an.
Diverse proprietäre Benachrichtigungsdienste wie z.B. Google Cloud Messaging, Apple Push Notification Service, E-Mail Service oder das Auslösen von HTTP-Hooks. Diese Dienste Benachrichtigen die entsprechende Zielplattform.

In den folgenden Kapiteln wird auf die einzelnen Ausführungsschritte – von der Registrierung bis zur Benachrichtigung – konkret auf die Implementierung eingegangen.

Registrierung für Push-Notifications
Es werden grundsätzlich zwei Arten von Registrierungen für den Erhalt von Push-Benachrichtigungen unterschieden:
Die technische Registrierung – beim plattformspezifischen Benachrichtigungsdienst, wie z.B. Google Cloud Messaging Service (GCM) oder Apple Push Notification Service (APNS)
Die fachliche Registrierung – beim applikationsspezifischen Server, der die Gruppierung der verschiedenen Benachrichtigungsendpunkten vornimmt

Die folgenden zwei Kapitel beschreiben die beiden Registrierungsverfahren.

Die technische Registrierung
Die mobile App registriert sich anhand ihrer Plattform beim entsprechenden Dienst. Bei der Registrierung enthält die mobile App ein Registrierungs-ID bzw. ein Token, welche die App als eindeutiger Endpoint für Push-Benachrichtigungen legitimiert. Der folgende Ausschnitt aus der obigen Grafik zeigt den entsprechenden Kontext für die Registrierung:

Technische Registrierung

Da die Watogo App mit Apache Cordova, d.h. mit standard Web-Technologien wie HTML, CSS und Javascript gebaut wurde, braucht es ein entsprechendes Cordova-Plugin, das die jeweiligen Plattformen im Kontext von Push-Notifikationen unterstützt. Da die Implementierung von Push-Benachrichtigungen ein häufiger Anwendungsfall ist, gibt es von Phonegap bereits ein ausgereiftes Push-Plugin (https://github.com/phonegap-build/PushPlugin) dazu. Dieses Plugin enthält plattformspezifische Implementierungen für die technische Registrierung beim jeweiligen Dienst.

Das Push-Plugin lässt sich mittels Cordova CLI einfach einbinden:

Die technische Registrierung beim entsprechenden Dienst wird sobald in der WebView das Event ‚deviceready‘ ausgelöst wurde, durchgeführt. Hier wird auch die plattformspezifische Unterscheidung gemacht, wie der folgende Code zeigt:

Wie im obigen Code ersichtlich, muss für die Registrierung beim Google Cloud Messaging Dienst eine Sender-Id mitgegeben werden. Diese wird dann entsprechend im Javascript Code hinterlegt (siehe Property „senderID“). Die Sender-Id bekommt man über die Android Developer Konsole indem man den GCM-Dienst für die eigene Android-App freischaltet. Google beschreibt den Vorgang in einem eigenen Artikel (https://support.google.com/googleplay/android-developer/answer/2663268?hl=de). Der folgende Screenshot zeigt, wo man diese Sender-Id für GCM findet:

GCM Sender ID

Für den Apple Push Notification Dienst muss eine Aktivierung auf der App in der Developer Konsole von Apple (https://developer.apple.com/account) erfolgen. Hier kann man den Push-Notification Dienst aktivieren, wie der folgende Screenshot zeigt.Registrierung Push-Notification bei Apple

Damit die iOS Mobile App sich bei der entsprechenden APNS Plattform (Development oder Distribution) registrieren kann, muss die bauende Instanz ein entsprechendes Zertifikat eingespielt haben. Dieses muss für die Development wie auch für die Distribution Umgebung erstellt werden (dieser Schritt muss auch ohne Verwendung des Push-Dienstes durchgeführt werden). Die Apps sollten sich nach der Generierung des Zertifikates beim entsprechendem Dienst registrieren können. Mit dem Beispiel im git Repository vom Phonegap Push-Plugin kann dies entsprechend gut getestet werden (https://github.com/phonegap-build/PushPlugin/tree/master/Example/www).

Die fachliche Registrierung
Die fachliche bzw. die applikationsspezifische Registrierung für Push-Notifikation ist abhängig von die fachlichen Benachrichtigungsanforderungen an die entsprechende Mobile App. Die folgende Darstellung zeigt die Funktionsweise von Benachrichtigungen im Fall von Watogo.

Watogo Benachrichtigungen

Auf Watogo können mit Freunden zu öffentlichen wie auch privaten Veranstaltungen Umfragen gestartet werden. In den Umfragen können dann einzelne Terminvorschläge publiziert werden. Der Link zur Umfrage kann mit den eingeladenen Gästen geteilt werden. Diese können die Umfrage kommentieren und bestimmen, ob sie teilnehmen möchten oder nicht. Bei jeder Aktivität, d.h. Kommentar oder Teilnahme, wird eine Benachrichtigung ausgelöst. Benutzt man Watogo via App, erhält man in seinen Umfragen eine entsprechende Benachrichtigung. Das fachliche Datenmodell (Entitäten mit Relvanz zur Push-Benachrichtigung) des Umfragen-Konstruktes sieht wie folgt aus:
Fachliches Modell

Dabei gibt es folgende drei relevante Entitäten und Abhängigkeiten untereinander:
Umfrage: Wird verwendet, um einen passenden Termin von öffentlichen oder privaten Veranstaltungen mit seinen Freunden zu finden.
Benutzer: Nimmt an einer Umfrage teil, kommentiert diese und teilt sie u.U. auch mit anderen Freunden
Kommentar: Notiz oder Meinung eines Benutzers zu einer bestimmten Umfrage

Die Entität ‚Umfrage‘ wird als Container für eine bestimmte Empfängerschaft verwendet. Jeder Benutzer, der die Umfrage öffnet, registriert sich automatisch für die Benachrichtigungen und somit im Container ‚Umfrage‘ als potentieller Empfänger. Durch dieses Konstrukt bekommt man aus Sicht des Software-Entwicklers eine zusätzliche Komplexität bei der Verwaltung von Empfänger (sogn. Endpoints).
Wie in der Übersicht bereits aufgezeigt, wird für die Verwaltung der Empfänger sowie für den Versand von Benachrichtigungen der Amazone Simple Notification Service (SNS) verwendet. Dieser unterstützt bei der Realisierung des obengenannten Gruppierungs- und Benachrichtigungskonstruktes. Der SNS bringt ein eigenes Modell mit. Die folgende Grafik zeigt dieses Modell.

SNS Modell

Folgende Elemente gibt es beim SNS:

Plattform Application: Repräsentiert einen Benachrichtigungsdienst wie z.B. GCM oder APNS / APNS_Develop. Pro angebundener Push-Dienst muss eine Plattform Application erstellt werden. Aktuell unterstützte Push-Dienste:
– Amazon Device Messaging (ADM)
– Apple Production (APNS)
– Apple Development (APNS_Develop)
– Baidu Cloud Push for Android in China
– Google Cloud Messaging (GCM)
– Microsoft MPNS for Windows Phone 7+
– Microsoft WNS for Windows Phone 8+ & Windows Phone 8.1+

Im Kontext von Watogo wurden APNS, APNS_Develop und GCM als Platform Application eingerichtet.  Der folgende Artikel von Amazon beschreibt wie die einzelnen Platform Applications eingerichtet werden können: http://docs.aws.amazon.com/sns/latest/dg/mobile-push-send-register.html

Platform Endpoint: Repräsentiert ein Empfängergerät einer bestimmten Plattform Application. Ein Platform Endpoint ist im Kontext von Watogo ein Android- oder ein iOS-Gerät. Die Registrierung von Platform Endpoints an der entsprechenden Plattform Application soll automatisiert über das Amazon SDK laufen.
Topic: Ist eine Gruppierung von einer bestimmten Empfängerschaft (Subscriptions) und ermöglicht so diesen Empfängern gezielt eine Benachrichtigung zu senden. Die Erstellung eines Topics soll automatisiert über das Amazon SDK laufen.
Subscription:  Abonnement eines Topics, d.h. wird in einem Topic eine Benachrichtigung gesendet, wird diese Nachricht an den entsprechenden Endpoint weitergeleitet. Der Endpoint kann u.A. ein Platform Endpoint sein. In diesem Artikel werden nur die Plattform Endpoints besprochen. Die Erstellung einer Subscription soll automatisiert über das Amazon SDK laufen.

Da nun beide Modelle bekannt sind, können diese relativ einfach aufeinander gemappt werden. Das folgende Modell zeigt das Mapping der beiden Modelle.

Mapping der ModelleGrün = Fachliches Modell von Watogo, Rot = Modell von SNS

Aus dem obigen Modell geht folgendes hervor:

– Pro Umfrage muss ein Topic erstellt werden. (automatisiert)
– Pro Teilnehmer muss eine Subscription auf dem entsprechenden Topic erstellt werden. (automatisiert)
– Pro Gerät muss ein Plattform Endpoint erstellt werden. (automatisiert)
– Pro angebundener Benachrichtigungsdienst  muss eine Platform Application erstellt werden (manuell)

Sämtliche anwendungsspezifischen Registrierungen laufen über den Watogo Applikationsserver. In den folgenden Abschnitten wird dabei folgendes behandelt:

Watogo fachliche Registrierung

 

Es wird aufgezeigt wie sich die Geräte anwendungsspezifisch für Benachrichtigungen registrieren sowie diese Elemente auf dem Amazon SNS erstellt bzw. verwaltet wird.

Für die automatisierte Erstellung der Amazon SNS Elemente wird das Amazon SDK for Java (http://aws.amazon.com/de/sdk-for-java/) verwendet. Dieses kann in einem Maven-Projekt als Maven-Dependency (com.amazonaws.aws-java-sdk) referenziert werden.

Tipp: Amazon bietet ein Beispiel-Projekt, welches aufzeigt wie die einzelnen Elemente automatisiert erstellt werden können (Sns-Mobile-Push-Example.zip).

Platform Application(s) manuell erstellen
Pro unterstützte Benachrichtigungsplatform muss eine Platform Application im Amazon SNS erstellt werden.

Apple Push Notification Service (APNS und APNS_Sandbox): Das Einrichten der jeweiligen Platform Application und die Generierung der benötigten Zertifikate für eine APNS oder APNS-Develop Platform Application ist unter dem folgenden Link detailliert beschrieben: http://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html

Google Cloud Messaging (GCM): Das Einrichten und die Generierung des benötigten API-Keys ist ebenfalls bei Amazon detailliert beschrieben: http://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html

SNS Client initialisieren
Bevor auf dem SNS Elemente automatisiert erstellt werden können, braucht es ein initialisiertes AmazonSNSClient Objekt. Um das Objekt zu erstellen, müssen folgende Attribute gesetzt sein:

AWSAccessKeyId: Benutzer-ID (mit entsprechenden SNS-Rechten) um auf den SNS-Dienst zugreifen zu können
AWSSecretKey: Benutzerspezifischer Schlüssel um auf den SNS-Dienst zugreifen zu können
Endpoint: SNS-Endpoint (Spezifikation der Region)

Die Benutzerdaten (Accesskey und Secretkey) erhält man, in dem man für den SNS-Dienst einen eigenen Benutzer im AWS IAM erstellt.

Der Code für das Aufsetzen des AmazonSNSClient sieht wie folgt aus:

Topic erstellen
Um einen Container für potentielle Empfänger von Push-Notifications zu erhalten, muss pro Umfrage ein entsprechendes SNS Topic erstellt werden. D.h. sobald ein Benutzer eine Umfrage erstellt, muss automatisch im SNS ein Topic erstellt werden. Der Watogo Anwendungsserver bietet eine Schnittstelle um Umfragen zu erstellen. Dort kann man sich jetzt einhängen und beim Erstellen einer Umfrage ein entsprechendes SNS Topic erstellen. Der Code für das Erstellen eines SNS Topics sieht wie folgt aus.

Die Erstellung eines Topics ist relativ einfach. Man muss lediglich den Namen des gewünschten Topics angeben. In Watogo haben wir die Benennung des Topics mit der Id der Umfrage verknüpft, um das Mapping zwischen Topic und Umfrage herstellen zu können. So ist es auch möglich nicht mehr verwendete  Topics bzw. nicht mehr gültige Umfragen nach einer bestimmten Zeit wieder aufräumen zu können. Bei einer erfolgreichen Erstellung des Topics erhält man im Result-Objekt eine Topic-ARN. Das ARN steht für Amazon Resource Name und ermöglicht eine eindeutige Referenzierung des entsprechenden Amazon Objektes (egal ob Topic, Platform Endpoint, Platform Application, etc.). Dieses Topic-Arn wird bei der Erstellung der Subscription relevant sein.

Platform Endpoint erstellen
Um ein Abonnement bzw. Subscription einem bestimmten Topic anhängen zu können, muss zuerst das Gerät des Benutzers bzw. der Platform Endpoint registriert werden. Im Kapitel „technische Registrierung“ hat das Gerät bei der Initialisierung bereits ein eindeutiges Token bzw. eine Device-Id vom passenden Push-Notification Dienst erhalten. Dieses wird nun verwendet, um einen Platform Endpoint innerhalb einer bereits eingerichteten Platform Application beim Amazon SNS erstellen zu können. Um einen Platform Endpoint erstellen zu können, benötigt man zuerst der ARN der entsprechenden Platform Application (= des Benachrichtigungsdienstes). In Watogo wurde die ARN der pro Platform Application einfach in einem Setting-File hinterlegt. Die mobile App gibt in Watogo über die API mit um welche Schnittstelle es sich beim entsprechenden Gerät handelt. Der folgende Code zeigt die Erstellung eines Platform Endpoint innerhalb einer bestimmten Platform Application anhand der übergebenen Platform von der Mobile-App:

Folgendes wird beim obigen Code ausgeführt:

1. Eintrittsmethode createPlatformEndpoint
Die HTTP REST API ruft beim Registrieren eines mobilen Gerätes bei einer Umfrage diese Methode mit Zielplatform (Parameter Platform – androidos oder ios), mit dem Devicenamen (Hardware-ID des Gerätes) sowie mit dem Token für den entsprechendem Push-Notification Dienst (dieses wurde vorgängig vom Device beim Benachrichtigungsdienst bereits abgeholt). Die Eintrittsmethode createPlatformEndpoint versucht lediglich den Parameter platform zu interpretieren und sucht dabei den richtigen Wert im Enumerator Platform. Falls der Wert gefunden wurde, delegiert sie diesen Wert weiter an die Methode createEndpoint.

2. Methode createEndpoint
Die Methode holt nun den ARN der entsprechenden Platform Application (Methode getArn) aus dem SNS (APNS, APNS_Sandbox oder GCM) und ruft die Methode requestPlatformEndpoint mit der korrekten Platform Application ARN auf.

3. Methode requestPlatformEndpoint
Diese Methode stellt den Request mit den entsprechenden Parametern (Platform Application Arn, Device-Token und Name des Edpoints) und setzt nun diesen Request an den SNS ab. Das Resultat gibt sie dann an die aufrufende Methode (insb. den ARN der erstellten oder bereits existierenden Endpoints) zurück.

So ist es nun möglich, pro Gerät im Amazon SNS ein entsprechender Platform Endpoint zu erstellen. Da nun der ARN des Topics (= Umfrage) sowie der entsprechenden Platform Endpoints (Geräte der Umfrage-Teilnehmer) erstellt sind, müssen lediglich auf dem Topic noch entsprechende Subscription(s) erstellt werden.

Subscription erstellen
Die Subscription ermöglicht die Benachrichtigung über Aktivitäten in einem bestimmten Topic. Die Subscriptions von einem Topic erhalten sämtliche Nachrichten. Deshalb wurde auch in Watogo für eine Umfrage ein entsprechendes Topic erstellt. Alle Aktivitäten wurden im Topic veröffentlicht und so die Geräte via Push-Notification informiert. Durch eine Subscription wird man über alle Topic relevanten Nachrichten entsprechend benachrichtigt. Der folgende Code zeigt, wie man für einen PlatformEndpoint eine Subscription an einem bestimmten Topic macht.

Da der Platform Endpoint innerhalb einer registrierten Platform Application läuft, verläuft die Subscription via Typ ‚Application‘. Es können folgende verschiedene Arten von Subscriptions erstellt werden:

– HTTP
– HTTPS
– E-Mail
– E-Mail-json
– Amazon SQS
– Application
– AWS Lambda

In Watogo wird aktuell lediglich der Typ Application für eine Subscription verwendet.

Benachrichtigungen auslösen
Die Subscriptions auf einem bestimmten Topic wurden erstellt – nun möchte man in einem bestimmten Topic eine Benachrichtigung auslösen. Der SNS bietet hier eine offene Schnittstelle um plattformspezifische Nachrichten zu senden. Jede Plattform erwartet eine spezifische Nachricht (typischerweise im JSON-Format). In der AWS Konsole können diese Nachrichten plattformspezifisch generiert werden, wie der folgende Screenshot zeigt:

Send a Push Notification to a specific message

Wenn nun die JSON-Datei generiert wird, sieht diese so aus:

Wichtig ist hier, dass der SNS lediglich das Nachrichten-Property auf der entsprechenden Plattform abfüllt. Je nach Plattform werden aber noch weitere Attribute unterstützt. Es können auch anwendungsspezifische Daten mitgegeben werden, welche dann von der App entsprechend ausgelesen werden. Der folgende Code zeigt wie man nun eine Nachricht in einem SNS-Topic publiziert:

Benachrichtigungen interpretieren
In der Cordova basierten Mobile-App muss nun die entsprechende Push-Benachrichtigungen interpretiert werden. Hier kommt wieder das Push-Plugin ins Spiel bzw. die anfänglich beschriebene Registrierung. Nachfolgend nochmals der Registrierungscode des Plugins:

Auf Zeile 16 (‚onNotification‘ für GCM) sowie Zeile 26 (‚onNotificationAPN‘ für APNS / APNS_Sandbox) sieht man die Registrierung von Callback-Funktionen für die Interpretation von Push-Benachrichtigungen. Die Interpretation von GCM-Nachrichten verläuft nun wie folgt:

In der Interpretation der Push-Benachrichtigungen muss beachtet werden, ob die App im Vordergrund ist oder nicht. Ist die App im Vordergrund braucht es keine Push-Benachrichtigung sondern einen sogn. Confirmation-Dialog. Die Information, ob eine App im Vordergrund ist oder nicht, wird im Event-Argument mitgeliefert (siehe Zeile 12). Ist die App nicht im Vordergrund, der Benutzer klickt aber auf die Push-Benachrichtigung, muss dies ebenfalls in der App behandelt werden. In Watogo wird die Id der Umfrage in der Nachricht mitgeschickt, damit man beim Klick auf die Nachricht direkt auf die entsprechende Umfrage gelangt. Die Herausforderung bei diesem Fall ist, vom spezifischen Cordova-Plugin Code in die AngularJS basierende SPA zu gelangen und dort ein Event auslösen zu können. Die Lösung des Problems zeigt Zeile 24 – 26. Hier wird das ng-app Element geholt und der entsprechende Injector dazu. Dazu wurde eine Factory ‚cordovaPush‘ erstellt, welche die Notifikationen entgegennimmt und dann in der SPA entsprechende Vorkehrungen trifft (im Fall von Watogo wird die location verändert). Der folgende Code zeigt die Factory.

Die onNotification-Funktion wird vom Plugin spezifischen Code aufgerufen.

Der folgende Code zeigt die Interpretation von APNS-Nachrichten:

Fazit & Lesson learnt
Die Implementierung von Push-Notification auf einem hybriden Stack ist aufwändig, da viele verschiedenen Technologien (HTML, Javascript, CSS, Java) und verschiedene Plattformen involviert sind (Tomcat Applikationsserver, Amazon Web Services, Amazon Simple Notification Service, Android mit verschiedenen Versionen und Geräte,  iOS mit verschiedenen Versionen). Die Fehlersuche bzw. das Debugging ist ebenso aufwändig wie auch Schwierig (lokales Debugging der App und des lokalen Applikationsservers). Auf der positiven Seite erhält man dadurch eine sehr grosse Flexibilität für die Anbindung von neuen bzw. weiteren Platformen .

In Zukunft würden wir das Feature für eine Platform (z.B. GCM) implementieren, anschliessend die Benutzung messen und dann anhand der Benutzer-Daten entscheiden, ob eine Ausweitung auf eine weitere Plattform Sinn macht.