Entwicklung einer mHealth-App zum Vergleich moderner Benachrichtigungstechniken

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 ge­zielt einsetzen möchte, steht vor der Frage, welche Push Technologien es zur Aus­wahl 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 ab­zuwä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 Techno­logien wie Remote Notifications mit FCM, HTTP Long Polling und einer eigenen offenen mobile notification server (MSN) Lösung im Vergleich zu Local Notificati­ons diskutiert, welche Push Technologie unter den Aspekten der Skalierbarkeit und Zuverlässigkeit des Dienstes und Verfügbarkeit der Push Nachrichten die bestge­eignete Push Technologie im App Kontext ist. Der jeweilige App Kontext und die Diskussion der am besten geeigneten Push Lösung werden mit einer selbst imple­mentierten 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. Ska­lierbarkeit 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 ha­ben gezeigt, dass lokale Push Lösungen unter den gegebenen Qualitätsanforde­rungen am besten im App Kontext geeignet sind. Der Vergleich und die Diskussi­on zur bestgeeigneten Push Lösung haben allgemeingültige Eigenschaften, Vor- und Nachteile der jeweiligen Push Technologien deutlich gemacht, so dass lo­kale 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 An­wendungen auf mobilen Endgeräten gemeint, die zur Fürsorge der Gesundheit ei­nes 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 zu­gänglich zu machen.

Angenommen es wird die Umsetzung einer mobilen Gesundheitsapp beabsichtigt, bei der ein Benachrichtigungsdienst zuverlässig und uneingeschränkt verfügbar an­geboten 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 Benachrichti­gung sich erschwert oder eine schwierige Entscheidung nach langen Abwägungen ist.

Kamath 10 zeigt auf, dass sog. Push Notifications als eine sehr effektive Mög­lichkeit 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. Beson­ders verwende man sie z.B. für Marketing Zwecke, um neue Angebote anzukündi­gen 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 Notificati­ons beachte und anklicke, in der Regel höher anzunehmen, da sie z.B. im Gegen­satz zu ungeöffneten E-Mails im Mailposteingang auf dem Bildschirm des Benut­zers 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 er­geben sich mehrere verschiedene Push Technologien, um Benachrichtigungen an das Endgerät zu pushen. Klare Antworten auf Fragen, welche Vorteile und Nach­teile die Push Technologien im gegenseitigen Vergleich haben, wie zuverlässig ein umgesetzter Dienst mit der ausgewählten Push Technologie ist, ob Push Notifi­cations 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 disku­tiert, welche Push Technologie unter den Aspekten der Skalierbarkeit und Zuver­lä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 Ein­stellung zu bestimmten Benachrichtigungen zur Diskussion der Push Technologien beiträgt. Zur Testung der Zuverlässigkeit wird diese App isolierten Tests vorgezo­gen, 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 Notificati­ons 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 Techni­ken untersucht werden, definiert und qualitative und evtl. quantitative Bewertungs­mö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 quantita­tiv und qualitativ untersucht. Anschließend erfolgt der gegenseitige Vergleich und die abschließende Diskussion im 7.Kapitel. Die Arbeit endet mit einem zusammen­fassenden Fazit.

2 Mobile Health App Reminder

In diesem Kapitel wird die im Rahmen dieser Arbeit entwickelte mHealth App „Re­minder“ kurz vorgestellt und außerdem auf ihren Benutzungskontext eingegangen. Zur Installation stehen APK¹ Dateien bereit, wobei die App in 4 verschiedenen Ver­sionen 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 Ge­sundheitsfürsorge und Erinnerung an eingetragene Termine. Sie richtet sich im All­gemeinen 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 ange­botenen 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 Funktio­nen sehen kann:

- Erinnerung an Medikamenteneinnahme: Der Benutzer kann Einträge zur Me­dikamenteneinnahme zu festen Uhrzeiten erstellen. Die Benachrichtigungen erfolgen täglich zu den eingetragenen Uhrzeiten.
- Erinnerung an Arzttermine: Der Benutzer kann Einträge zu festen Arztter­minen 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 Einstellungsfens­ter innerhalb des rechteckigen Kastens verfolgt und gelöscht werden. Durch die Lö­schung eines Eintrags wird auch die zugehörige Benachrichtigungsfunktion abge­brochen. 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 Benachrichtigungs­leiste 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 zumin­dest erwartet, dass Benachrichtigungen zu beliebigen Zeitpunkten empfangen wer­den.

Die Push Notifications werden in der jeweils benutzen App Version mittels der je­weiligen 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 beschrie­ben werden: Das Observer Pattern sei ein Software Pattern, um alle registrier­ten Observer mit Updates zur Zustandsänderung eines sog. Subjekts zu benach­richtigen. Bei ausbleibenden Benachrichtigungen könnten Inkonsistenzen zwischen Subjekt und Beobachter entstehen. Das beobachtete Subjekt biete eine Schnittstel­le zur Registrierung von Beobachtern an und speichere registrierte Observer bei sich ab. Observer hingegen stellten auch eine Schnittstelle bereit, um Informatio­nen zu Zustandsänderungen zu erhalten.

Eine Umsetzungsmöglichkeit zur Beobachtung des Subjekts bestehe darin, mög­liche Zustandsänderungen in zeitlich regelmäßigen Abständen zu erfragen. Dies sei jedoch im Allgemeinen nicht praxistauglich, da rechtzeitig benachrichtigt wer­den 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 ge­be 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 enthal­te 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 Pu­blikation dient, wie im Text ausdrücklich betont, lediglich dem Zweck der Informati­on 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 Ei­genschaften ursprünglich nicht vorgesehen war, zeigen jedoch auch die Nachteile von Short Polling bzw. von klassischem Polling wie z.B. Latenzen, Bandbreiten­verschwendung, 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ück­schicken und würde die Verbindung anschließend schließen. Durch das Offenhalten der Verbindung bis zum Eintreffen eines Events wirke die Client-Server Kommuni­kation 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ön­ne 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 ei­nem möglichen Timer Einsatz sowohl client- als auch serverseitig sei die Rede.

Abbildung 3.1 fasst alle Schritte eines HTTP Long Polling Lebenszykluses zusam­men. 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 Pu­sh 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 Benach­richtigung fokussiert. In der gesamten Arbeit schließen die Remote Push Notificati­ons 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ön­nen. So heißt es in der Dokumentation, dass Local Push Notifications lokal im mo­bilen Endgerät entstehen. Ein Server, der aktiv eine Benachrichtigung zum Endge­rä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 Infor­mationen 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 inter­essanten Daten benachrichtigt werden solle, eignen. Sie würden sich auch anbie­ten, 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 Vari­ante der Push Notifications eigne sich vor allem, wenn ein Server für das Datenma­nagement der App zuständig sei und den Client z.B. über neue Daten, Messages o.Ä. benachrichtigen solle. Sie könnten zu beliebigen Zeitpunkten verschickt wer­den 11. Anisimova 3 erklärt die allgemeine Architektur von Remote Push Tech­nologien. Ihre Architekturbeschreibung ist dabei unabhängig vom jeweiligen Drit­tanbieter 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 um­gesetzt werden, wie z.B. GCM für Android oder APNS für iOS. Die privaten Applika­tionsserver 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 Über­lieferung 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 Hin­tergrundverbindung 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 Pu­sh 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 geschilder­ten Sachverhalt grafisch dar:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Grundlegende Remote Notification Architektur

[...]

¹ https://praxistipps.chip.de/was-ist-ein-apk-einfach-erklaert_42098 (zuletzt be­sucht am 27.10.2021)