Leseprobe
Inhaltsverzeichnis
Abstract
1 Einleitung
2 Mobile Health App Reminder
3 Grundlagen
3.1 HTTP Long Polling
3.2 Push Notifications
3.2.1 Local Push Notifications
3.2.2 Remote Push Notifications
4 Entwurf
4.1 Local Push Notifications
4.2 Remote Push Notifications
4.2.1 HTTP Long Polling
4.2.2 FCM
4.2.3 PMNS
5 Methodik
5.1 Vergleichsmerkmale und Messung
5.1.1 Zuverlässigkeit
5.1.2 Verfügbarkeit
5.1.3 Skalierbarkeit
5.2 Testung der Zuverlässigkeit
6 Ergebnisse
6.1 Tabellarische Auswertung Inhaltsverzeichnis
6.2 Quantitative und Qualitative Analyse
6.2.1 Local Push Variante Mittlere Verzögerungszeit Auffälligkeiten Begründung in der Implementierung
6.2.2 Remote FCM Variante Mittlere Verzögerungszeit Auffälligkeiten Begründung in der Implementierung
6.2.3 Remote Push Variante mit PMNS Mittlere Verzögerungszeit Auffälligkeiten Begründung in der Implementierung
6.2.4 HTTP Long Polling Mittlere Verzögerungszeit Auffälligkeiten Begründung in der Implementierung
7 Diskussion
7.1 Zuverlässigkeit
7.2 Skalierbarkeit
7.3 Verfügbarkeit
7.4 Bestgeeignete Push Technologie für die Reminder App
8 Zusammenfassung und Fazit
Literatur
Abstract
Push Notifications haben sich als eine sehr effektive Benachrichtigungsmöglichkeit etabliert. Ein Entwickler, welcher Push Notifications z.B. in einer mHealth App gezielt einsetzen möchte, steht vor der Frage, welche Push Technologien es zur Auswahl gibt und wie sie im gegenseitigen Vergleich unter wichtigen Qualitätsaspekten wie Zuverlässigkeit und Skalierbarkeit des Push Dienstes und Verfügbarkeit von Push Notifications stehen, um die für ihn Bestgeeignete unter allen Alternativen abzuwägen und zu implementieren.
In dieser Arbeit ist das Ziel, ausgewählte Push Technologien Implementierungen anhand einer selbst entwickelten mHealth App auf Zuverlässigkeit, Verfügbarkeit und Skalierbarkeit zu untersuchen. Es wird mit einer Auswahl von Push Technologien wie Remote Notifications mit FCM, HTTP Long Polling und einer eigenen offenen mobile notification server (MSN) Lösung im Vergleich zu Local Notifications diskutiert, welche Push Technologie unter den Aspekten der Skalierbarkeit und Zuverlässigkeit des Dienstes und Verfügbarkeit der Push Nachrichten die bestgeeignete Push Technologie im App Kontext ist. Der jeweilige App Kontext und die Diskussion der am besten geeigneten Push Lösung werden mit einer selbst implementierten Motivationsapp unterstützt.
Um zur Forschungsfrage der geeigneten Push Technologie eine Antwort zu geben, wurde mit Hilfe der App die Zuverlässigkeit der Push Technologien getestet. Skalierbarkeit und Verfügbarkeit der jeweiligen Push Technologien wurde außerdem mit Hilfe dieser App bewertet.
Die Vorteile und Nachteile im gegenseitigen Vergleich der Push Technologien haben gezeigt, dass lokale Push Lösungen unter den gegebenen Qualitätsanforderungen am besten im App Kontext geeignet sind. Der Vergleich und die Diskussion zur bestgeeigneten Push Lösung haben allgemeingültige Eigenschaften, Vor- und Nachteile der jeweiligen Push Technologien deutlich gemacht, so dass lokale Push Lösungen unter diesen Qualitätspunkten zur Umsetzung eines App- Abstract
Benachrichtungsdienstes mit Push Notifications empfehlenswert sind.
1 Einleitung
Im Online-Artikel 12 zum Thema Mobile Health sind unter mHealth mobile Anwendungen auf mobilen Endgeräten gemeint, die zur Fürsorge der Gesundheit eines Benutzers z.B. eines Arztpatienten oder einer Privatperson unterstützen sollen. Darüber hinaus brauche es zur Umsetzung einer mHealth Anwendung bestimmte Technologien, um den gesamten mobilen Gesundheitsdienst dem Endbenutzer zugänglich zu machen.
Angenommen es wird die Umsetzung einer mobilen Gesundheitsapp beabsichtigt, bei der ein Benachrichtigungsdienst zuverlässig und uneingeschränkt verfügbar angeboten werden soll. Alternativen zur Umsetzung sind altbewährte Technologien wie z.B. SMS-Nachrichten oder E-Mails, jedoch bringt jede Technologie Vorteile und Nachteile mit sich, so dass die Wahl einer geeigneten Technologie zur Benachrichtigung sich erschwert oder eine schwierige Entscheidung nach langen Abwägungen ist.
Kamath 10 zeigt auf, dass sog. Push Notifications als eine sehr effektive Möglichkeit zur mobilen Benachrichtigung etabliert sind und geht ausführlich auf Push Notifications ein. Außerdem macht sie auf den Trend im Marketing aufmerksam, dass in Apps oder Webseiten gezielt Push Notifications eingesetzt werden. Dabei handele es sich um Nachrichten, die direkt an das Handy oder an den Desktop des Benutzers gesendet und auf dem Gerätedisplay aufpoppen würden, um zu einer bestimmten Handlung zu motivieren. Zudem würden sie Benutzer Personalisierung der Message ermöglichen und könnten auch Bilder, Videos o.Ä. enthalten. Besonders verwende man sie z.B. für Marketing Zwecke, um neue Angebote anzukündigen oder Kunden wieder einzubeziehen.
Kamath nennt auch Vorteile von Push Notifications gegenüber SMS Nachrichten oder E-Mails. So sei die Wahrscheinlichkeit, dass der Benutzer die Push Notifications beachte und anklicke, in der Regel höher anzunehmen, da sie z.B. im Gegensatz zu ungeöffneten E-Mails im Mailposteingang auf dem Bildschirm des Benutzers erschienen. Zudem fielen geringere Kosten bei der Benachrichtigung an als bei SMS Nachrichten. Bei den Push Notifications habe der Benutzer auch jederzeit die Möglichkeit, die Benachrichtigung ein- und auch abzustellen.
Setzt man die Annahme der Entwicklung einer solchen mHealth App fort und die Benachrichtigung des Endnutzers erfolgt mit Hilfe von Push Notifications, so ergeben sich mehrere verschiedene Push Technologien, um Benachrichtigungen an das Endgerät zu pushen. Klare Antworten auf Fragen, welche Vorteile und Nachteile die Push Technologien im gegenseitigen Vergleich haben, wie zuverlässig ein umgesetzter Dienst mit der ausgewählten Push Technologie ist, ob Push Notifications des jeweiliger Technologie auch offline zur Verfügung stehen und wie gut die Technologien skalieren, sind bei einer Auswahlentscheidung von mobilen Push Technologien z.B. zur Umsetzung einer mHealth App sehr hilfreich für Entwickler. Im Rahmen dieser Bachelorarbeit wird mit einer Auswahl von Push Technologien wie Remote Notifications mit FCM, HTTP Long Polling und einer eigenen offenen mobile notification server (MSN) Lösung im Vergleich zu Local Notifications diskutiert, welche Push Technologie unter den Aspekten der Skalierbarkeit und Zuverlässigkeit des Dienstes und Verfügbarkeit der Push Nachrichten die bestgeeignete Push Technologie im App Kontext ist. Der jeweilige App Kontext und die Diskussion der am besten geeigneten Push Lösung werden mit einer selbst implementierten Motivationsapp unterstützt. Es zeigt sich, dass die mHealth App zur manuellen Einstellung zu bestimmten Benachrichtigungen zur Diskussion der Push Technologien beiträgt. Zur Testung der Zuverlässigkeit wird diese App isolierten Tests vorgezogen, da die Testung an der App einem realen Einsatz der Push Technologien in der Praxis entspricht. Darüber hinaus kann mit ihr die Verfügbarkeit von Push Notifications beobachtet werden. Die Software Architektur der mobilen App unterstützt auch Ansätze in der Diskussion zur Skalierbarkeit der Push Technologien.
In Kapitel 2 wird die mHealth Android Anwendung Reminder vorgestellt. Kapitel 3 behandelt die theoretischen Grundlagen zu den ausgewählten Push Techniken. Die Software Architektur von Reminder wird in Kapitel 4 beschrieben und gerechtfertigt. Im 5.Kapitel werden die Qualitätsmerkmale, auf die die ausgewählten Push Techniken untersucht werden, definiert und qualitative und evtl. quantitative Bewertungsmöglichkeiten aufgezeigt. Das Test Setting zur Testung der Zuverlässigkeit mit Hilfe der App wird ebenfalls in Kapitel 5 detailliert beschrieben und die Ergebnisse aus den Testwiederholungen in Kapitel 6 tabellarisch ausgewertet und zudem quantitativ und qualitativ untersucht. Anschließend erfolgt der gegenseitige Vergleich und die abschließende Diskussion im 7.Kapitel. Die Arbeit endet mit einem zusammenfassenden Fazit.
2 Mobile Health App Reminder
In diesem Kapitel wird die im Rahmen dieser Arbeit entwickelte mHealth App „Reminder“ kurz vorgestellt und außerdem auf ihren Benutzungskontext eingegangen. Zur Installation stehen APK1 Dateien bereit, wobei die App in 4 verschiedenen Versionen je für eine Push Technologie zur Verfügung steht. Reminder kann auf einem Smartphone bzw. Emulator mit Android Betriebssystem von API Level 26 bis 29 installiert werden. Beim Einsatz eines Emulators kann sie z.B. per Drag & Drop heruntergeladen werden.
Reminder ist eine mobile Gesundheits-App mit dem Ziel der Motivation zur Gesundheitsfürsorge und Erinnerung an eingetragene Termine. Sie richtet sich im Allgemeinen an gesunde Bürger, die für ihre allgemeine Gesundheit etwas Gutes tun möchten und nicht an bestimmte Patientengruppen. Aus dem Grund sind die angebotenen Funktionen in der App nicht krankheitsspezifisch.
Vom Hauptmenü (siehe Abbildung 2.1) aus gelangt man mit dem Menü-Button ins Einstellungsfenster (siehe Abbildung 2.2), so dass man die unterstützten Funktionen sehen kann:
- Erinnerung an Medikamenteneinnahme: Der Benutzer kann Einträge zur Medikamenteneinnahme zu festen Uhrzeiten erstellen. Die Benachrichtigungen erfolgen täglich zu den eingetragenen Uhrzeiten.
- Erinnerung an Arzttermine: Der Benutzer kann Einträge zu festen Arztterminen erstellen. Die Benachrichtigung wird rechtzeitig eine Stunde vor dem geplanten Arzttermin eintreffen.
- Erinnerung an Blutdruckmessung: Der Benutzer wird regelmäßig im Abstand von einer Stunde an die Blutdruckmessung erinnert.
- Erinnerung an Wasser Trinken: Der Benutzer wird regelmäßig im Abstand von einer halben Stunde an das Trinken von Wasser erinnert.
Die Medikamenteneinnahme und Arzttermin Einträge können im Einstellungsfenster innerhalb des rechteckigen Kastens verfolgt und gelöscht werden. Durch die Löschung eines Eintrags wird auch die zugehörige Benachrichtigungsfunktion abgebrochen. Benachrichtigungen an die Blutdruckmessung und an das Wasser Trinken können über die oberen Toggle Buttons im Einstellungsfenster eingestellt werden. Die Benachrichtigungen erhält der App Benutzer als Push Notifications auf seinem Endgerät. Mit einer Vibration einhergehend werden sie in der Benachrichtigungsleiste angezeigt (siehe Abbildung 2.3), auch während die App im Hintergrund läuft, so dass der Benutzer ungestört andere Anwendungen benutzen kann oder das Endgerät nicht in aktiver Benutzung ist. Grundsätzlich wird gefordert oder zumindest erwartet, dass Benachrichtigungen zu beliebigen Zeitpunkten empfangen werden.
Die Push Notifications werden in der jeweils benutzen App Version mittels der jeweiligen zugrundeliegenden Push Technologie gepusht. Reminder wird in späteren Kapiteln dazu eingesetzt, um die ausgewählten Push Technologien zu testen, die im nachfolgenden Kapitel in der Theorie beschrieben werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Hauptmenü von Reminder
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Einstellungsfenster von Reminder
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3: Beispiel einer Push Notification in der Benachrichtigungsleiste
3 Grundlagen
Das Push Model, das die theoretische Grundlage der Implementierung darstellt, auf dem die betrachteten Push Techniken aufbauen, kann folgendermaßen beschrieben werden: Das Observer Pattern sei ein Software Pattern, um alle registrierten Observer mit Updates zur Zustandsänderung eines sog. Subjekts zu benachrichtigen. Bei ausbleibenden Benachrichtigungen könnten Inkonsistenzen zwischen Subjekt und Beobachter entstehen. Das beobachtete Subjekt biete eine Schnittstelle zur Registrierung von Beobachtern an und speichere registrierte Observer bei sich ab. Observer hingegen stellten auch eine Schnittstelle bereit, um Informationen zu Zustandsänderungen zu erhalten.
Eine Umsetzungsmöglichkeit zur Beobachtung des Subjekts bestehe darin, mögliche Zustandsänderungen in zeitlich regelmäßigen Abständen zu erfragen. Dies sei jedoch im Allgemeinen nicht praxistauglich, da rechtzeitig benachrichtigt werden solle und Benachrichtigungen sich je nach zeitlichem Abstand stark verzögern könnten. Außerdem sei diese Variante bei zeitlich sehr kurzen Abfragefenster sehr ressourcenintensiv. Zur Kommunikation von Zustandsänderungen des Subjekts gebe es das Pull und das Push Model:
Beim Pull Model erhalte ein Observer eine Benachrichtigung über eine Zustandsänderung, jedoch müsse er selber in einem nächsten Schritt weitere Informationen zum neuen Zustand des Subjekts erfragen. Beim Push Modell hingegen sei der 2. Schritt nicht nötig, da eine Art Zustandsobjekt an die registrierten Beobachter mitgepusht werde, das alle nötigen Informationen zur Zustandsänderungen enthalte 7.
Die konkrete Umsetzung des abstrakten Push Models in Form von Push Techniken zur Benachrichtigung in Reminder sind Gegenstand nachfolgender Abschnitte. Die Implementierung und der Vergleich der ausgewählten Push Techniken können so in der Theorie und Praxis verstanden werden.
3.1 HTTP Long Polling
HTTP Long Polling (kurz: Long Polling) wird im RFC Beitrag 6202 14, das vom Internet Engineering Task Force, kurz IETF veröffentlicht wurde, definiert. Die Publikation dient, wie im Text ausdrücklich betont, lediglich dem Zweck der Information und erhebt keinen Anspruch auf Standardisierung von HTTP Long Polling oder HTTP Streaming.
In dieser Arbeit wird der Inhalt in diesem RFC Beitrag als Referenz und Grundlage zur Beschreibung, zur Diskussion und zur Implementierung der Long Polling Push Technik verwendet und in diesem Abschnitt näher erklärt.
Die Autoren räumen ein, dass das Anwendungsprotokoll HTTP für Server Push Eigenschaften ursprünglich nicht vorgesehen war, zeigen jedoch auch die Nachteile von Short Polling bzw. von klassischem Polling wie z.B. Latenzen, Bandbreitenverschwendung, usw. auf, welche bei der Entstehung des Server Push Features offensichtlich eine Rolle spielten.
Die Besonderheit von Long Polling sei, dass die Verbindung eines HTTP Requests offen gehalten werde und der Server erst eine Antwort an den Client sende, falls ein Event eingetroffen sei. Beim klassischen HTTP Polling Mechanismus würde der Server im Fall eines ausstehenden Events sofort eine leere HTTP Antwort zurückschicken und würde die Verbindung anschließend schließen. Durch das Offenhalten der Verbindung bis zum Eintreffen eines Events wirke die Client-Server Kommunikation nach Außen wie ein Server Push Verhalten, obwohl der Client den Server wie beim klassischen Polling mit HTTP Requests für Updates anfragen müsse.
Der RFC Beitrag lässt einen gewissen Implementierungsspielraum offen. Man könne z.B. selber entscheiden, ob man persistente HTTP Verbindungen benutze, um mehrere Requests über diesen abzuwickeln und so den Initialisierungsaufwand beim erneuten Verbinden für jede einzelne Anfrage zu reduzieren. Auch von einem möglichen Timer Einsatz sowohl client- als auch serverseitig sei die Rede.
Abbildung 3.1 fasst alle Schritte eines HTTP Long Polling Lebenszykluses zusammen. Zur Erstellung wurde der RFC 6202 Beitrag 14 als Grundlage herangezogen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: HTTP Long Polling Lebenszyklus
3.2 Push Notifications
Push Notifications werden in Local und Remote Push Notifications unterteilt. Diese Unterscheidung ist im Hinblick auf die Implementierung und Diskussion wichtig und wird in den nachfolgenden Unterabschnitten näher behandelt. Im Prinzip sind Push Notifications durch HTTP Long Polling auch Remote Push Notifications, da sie durch einen entfernten Server versendet werden, wobei HTTP Long Polling eine allgemeine Server Push Technik darstellt, welches in erster Linie nicht auf Benachrichtigung fokussiert. In der gesamten Arbeit schließen die Remote Push Notifications und Remote Push Lösungen auch HTTP Long Polling mit ein.
3.2.1 Local Push Notifications
In der Entwickler-Dokumentation von Apple 11 werden Local Push Notifications beschrieben und Beispiele genannt, in denen sie passend eingesetzt werden können. So heißt es in der Dokumentation, dass Local Push Notifications lokal im mobilen Endgerät entstehen. Ein Server, der aktiv eine Benachrichtigung zum Endgeräts abschickt, sei somit nicht nötig. Somit werde im mobilen Gerät, auf dem eine entsprechende App installiert sei, das Betriebssystem mit den dazu nötigen Informationen zur Benachrichtigung angesprochen und beauftragt.
Lokale Push Notifications würden sich, z.B. wenn im App Hintergrund neue Daten vom Server einträfen und der Benutzer lokal durch den Client im Fall von interessanten Daten benachrichtigt werden solle, eignen. Sie würden sich auch anbieten, wenn beispielsweise zu festen Zeiten an Termine o.Ä. erinnert werden solle.
Die Unterscheidung zwischen lokalen und entfernten Push Notifications ist auch auf Android Apps anwendbar. Je nach Betriebssystem werden unterschiedliche APIs zur Umsetzung von lokalen Push Notifications angeboten.
3.2.2 Remote Push Notifications
Im Gegensatz zu Local Push Notifications würden Remote Push Notifications durch einen entfernten Server z.B. ein Firmenserver an die Clients gepusht. Diese Variante der Push Notifications eigne sich vor allem, wenn ein Server für das Datenmanagement der App zuständig sei und den Client z.B. über neue Daten, Messages o.Ä. benachrichtigen solle. Sie könnten zu beliebigen Zeitpunkten verschickt werden 11. Anisimova 3 erklärt die allgemeine Architektur von Remote Push Technologien. Ihre Architekturbeschreibung ist dabei unabhängig vom jeweiligen Drittanbieter eines proprietären Push Dienstes. Ihr Blog schafft somit eine Grundlage zur Implementierung einer offenen Lösung von Remote Push Notifications:
Remote Push Notifications könnten mit verschiedenen proprietären Diensten umgesetzt werden, wie z.B. GCM für Android oder APNS für iOS. Die privaten Applikationsserver schickten Push Requests an die sog. mobile notification server (MNS). Diese Serverinstanz, welche z.B. konkret GCM für Android sein könne, sei dafür zuständig, diesen Push Request an das mobile Endgerät weiterzuleiten. Die Überlieferung der Push Notification erfolge über eine offene Verbindung zwischen des MNS und des Endgeräts, die mit der Installation der App unbemerkt vom Benutzer im Hintergrund offen gehalten werde. Die Benachrichtigung werde über diese Hintergrundverbindung empfangen, so dass das Betriebssystem laut Beitrag anschließend eine neue und stärkere Verbindung zur MNS aufbaue, um weitere Daten zur Push Notification beim Server anzufragen.
Dieser Punkt ist jedoch eine Frage der konkreten Umsetzung. Wie bereits in der Beschreibung des Observer Patterns am Anfang des Kapitels erwähnt, können Push Notifications an dieser Stelle mit dem Pull oder dem Push Modell umgesetzt werden. Die Autorin bezieht sich hier auf das Pull Model. Weiter heißt es in ihrem Blog, dass für das Anzeigen der Benachrichtigung der Client und die clientseitige Applikationslogik letztendlich zuständig sind.
Abbildung 3.2 auf Grundlage des Beitrags von Anisimova 3 stellt den geschilderten Sachverhalt grafisch dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: Grundlegende Remote Notification Architektur
[...]
1 https://praxistipps.chip.de/was-ist-ein-apk-einfach-erklaert_42098 (zuletzt besucht am 27.10.2021)