Push-Benachrichtigungen, die auch ankommen
Eine Meldung aufs Handy zu schicken klingt einfach. Zwischen dem Auslöser und dem Vibrieren liegen ein Token, ein Dienst, eine Batterieoptimierung und einige Fälle, in denen nichts passiert.
980 Wörter · 5 Min. Lesezeit
- app
- mobile
- api
Der Hauptzweck meiner App war, mich zu benachrichtigen, wenn etwas kaputt ist. Nicht per E-Mail, die ich nachts nicht sehe, sondern als Meldung, die vibriert.
Der Weg dorthin ist länger, als er aussieht, und besteht aus mehr Beteiligten, als man erwartet.
Der Weg einer Benachrichtigung
Mein Server ──► Vermittlungsdienst ──► Plattformdienst ──► Gerät
Der wichtigste Punkt daran: Man schickt nichts direkt an ein Handy. Man übergibt eine Nachricht an einen Dienst der jeweiligen Plattform, und der stellt sie zu — irgendwann, vielleicht sofort, vielleicht mit Verzögerung, vielleicht gar nicht.
Das ist der grundlegende Unterschied zu allem, was ich vorher gebaut hatte: Es gibt keine Zusicherung. Eine Benachrichtigung ist ein Versuch.
Das Token, und warum es sich ändert
Jede Installation der App bekommt ein Gerätetoken. Das ist die Adresse, an die zugestellt wird.
Was ich zunächst nicht verstanden hatte: Dieses Token ändert sich. Bei einer Neuinstallation, gelegentlich bei Systemaktualisierungen, manchmal ohne erkennbaren Grund. Wer es einmal speichert und für ewig hält, schickt nach ein paar Monaten ins Leere.
Die Folge für den Aufbau:
CREATE TABLE geraete (
id INTEGER PRIMARY KEY,
token TEXT NOT NULL UNIQUE,
plattform VARCHAR(10) NOT NULL,
besitzer VARCHAR(40) NOT NULL,
aktiv BOOLEAN NOT NULL DEFAULT 1,
zuletzt_ok DATETIME NULL,
fehlschlaege INT NOT NULL DEFAULT 0
);Die App meldet ihr Token bei jedem Start. Der Server aktualisiert oder legt an. Und — das ist der Teil, den man leicht vergisst — die Antwort des Zustelldienstes wird ausgewertet: Meldet er ein Token als ungültig, wird es abgeschaltet. Ohne diese Auswertung sammelt man tote Adressen und wundert sich, warum Zustellraten sinken.
Was ich bei den Meldungen selbst gelernt habe
Der Text muss ohne Öffnen der App verständlich sein. Auf dem Sperrbildschirm stehen zwei Zeilen. „Fehler aufgetreten" ist wertlos. „yurna-bot: seit 6 Min. keine Verbindung" sagt alles, was man um drei Uhr nachts braucht.
Es braucht eine Sammlung statt Einzelmeldungen. Als mein Bot einmal in einer Schleife neu startete, kamen vierzig Benachrichtigungen in zehn Minuten. Seitdem gilt: Gleiche Meldungen innerhalb eines Zeitfensters werden zusammengefasst.
Nicht jede Meldung ist dringend. Die Plattformen kennen Prioritäten. Eine niedrige Priorität wird gebündelt und zu einem passenden Zeitpunkt zugestellt, eine hohe sofort. Wer alles als dringend markiert, wird irgendwann gedrosselt — und nervt sich selbst.
Stille Zeiten sind ein Feature. Zwischen 23 und 7 Uhr kommt nur durch, was ich als kritisch eingestuft habe. Alles andere wartet bis zum Morgen. Das war die Änderung, nach der ich Benachrichtigungen überhaupt erst angelassen habe.
Warnung
In eine Benachrichtigung gehören keine sensiblen Inhalte. Sie erscheint auf dem Sperrbildschirm, wird vom Betriebssystem verarbeitet und läuft über einen fremden Dienst. Bei mir stehen dort Dienstname, Zustand und Zeit — nie Nutzerdaten, nie Auszüge aus Protokollen, nie Fehlermeldungen im Wortlaut.
Die Fälle, in denen nichts ankommt
Diese Liste habe ich mir zusammengesucht, nachdem ich zweimal geglaubt hatte, mein Code sei kaputt:
- Die App wurde vom System beendet und aggressive Energiesparoptionen verhindern die Zustellung. Auf manchen Geräten ist das der Normalfall, wenn man nichts einstellt.
- Das Token ist abgelaufen, weil die App länger nicht geöffnet wurde.
- Der Nutzer hat Benachrichtigungen abgelehnt — die Erlaubnis kann jederzeit entzogen werden.
- Kein Netz zum Zeitpunkt der Zustellung. Die Plattformdienste heben Nachrichten eine Weile auf, aber nicht unbegrenzt.
- Drosselung, weil zu viele Nachrichten in kurzer Zeit kamen.
Der Umgang damit ist derselbe wie bei allem, was unzuverlässig ist: Eine Benachrichtigung darf nie der einzige Weg sein. Bei mir schreibt jede kritische Meldung zusätzlich in ein Protokoll und in einen Kanal, den ich ohnehin lese. Die Meldung aufs Handy ist die schnelle Variante, nicht die einzige.
Was in eine Meldung gehört
Nach ein paar Monaten mit Benachrichtigungen hat sich ein Format herausgebildet, das ich nicht mehr ändere.
Titel: Was und wo. „yurna-bot: keine Verbindung" — nicht „Warnung" oder „Systemmeldung".
Text: Seit wann und wie schlimm. „Seit 6 Minuten, 3 Prüfungen fehlgeschlagen."
Keine Zahlenkolonnen. Auf einem Sperrbildschirm sind zwei Zeilen sichtbar. Alles darüber hinaus gehört in die App.
Eine Gruppierung. Meldungen zum selben Dienst werden zusammengefasst, statt sich zu stapeln.
Und eine Regel, die mir wichtiger geworden ist als alle Formatfragen: Zu jeder Alarmmeldung gehört eine Entwarnung. Ohne sie weiß man nie, ob ein Problem noch besteht — und dann bleibt ein unangenehmes Gefühl zurück, auch wenn längst alles wieder läuft.
Was ich abgeschaltet habe
Nach den ersten Wochen habe ich mehr Meldungen entfernt als hinzugefügt.
Erfolgsmeldungen für geplante Vorgänge. „Sicherung erfolgreich" jede Nacht. Das ist keine Information, das ist Rauschen — die Abwesenheit einer Fehlermeldung sagt dasselbe.
Meldungen über Werte in der Nähe einer Schwelle. Sie kamen mehrmals täglich und führten nie zu einer Handlung.
Meldungen über einzelne Fehler. Ein einzelner Fehler in einem Protokoll ist normaler Betrieb.
Was geblieben ist, sind ungefähr fünf Meldungsarten, und sie treten selten auf. Genau das ist die Absicht: Eine Benachrichtigung soll etwas bedeuten. Wenn das Handy dreimal am Tag vibriert, ist die vierte Meldung nichts wert — auch wenn sie die wichtige ist.
Der Fall, den ich zuerst nicht bedacht hatte
Eine Meldung erreicht ein Gerät. Was passiert, wenn dieses Gerät jemand anderem gehört?
Bei einer App, die nur ich benutze, ist das eine theoretische Frage. Sobald mehrere Personen Zugang haben, ist es keine mehr:
Ein Gerätetoken gehört zu einer Installation, nicht zu einer Person. Wer sich abmeldet und jemand anderes meldet sich an, bleibt das Token dasselbe.
Ohne Behandlung bekommt die zweite Person die Meldungen der ersten.
Die Lösung ist einfach und muss ausdrücklich gebaut werden: Beim Abmelden wird das Gerät abgemeldet, und beim Anmelden neu registriert. Dazu die Regel, dass eine Meldung immer an ein Gerät geht, das aktuell einer bestimmten Person zugeordnet ist — nicht an eine Liste von Token, die irgendwann einmal registriert wurden.
Was am meisten geholfen hat
Eine Testfunktion in der App. Ein Knopf, der eine Meldung an das eigene Gerät auslöst, und eine Anzeige, wann die letzte Meldung erfolgreich zugestellt wurde.
Klingt banal. Er beantwortet die Frage, die man sonst nie beantworten kann: Kommt gerade nichts, weil nichts passiert ist — oder weil die Zustellung nicht funktioniert? Ohne diese Unterscheidung wiegt man sich in Sicherheit, und zwar genau so lange, bis man sie braucht.