Eine App fürs Handy: React Native und Expo

Als die Verwaltungsschnittstelle als eigene Anwendung lief, ergab sich eine Möglichkeit fast von selbst: Wenn es eine saubere Schnittstelle gibt, die nichts mit der Weboberfläche zu tun hat, kann auch etwas anderes sie benutzen. Zum Beispiel eine App.

Der Anlass war praktisch. Ich wollte unterwegs sehen, ob alles läuft, und im Zweifel etwas neu starten können — ohne Laptop, ohne SSH-Verbindung vom Handy aus.

Warum React Native und Expo

Ich hatte drei Möglichkeiten und habe sie gegeneinander abgewogen.

Eine Webseite auf dem Handy. Kostet nichts, gibt es schon. Was fehlt: Benachrichtigungen, die ankommen, wenn die Seite nicht offen ist. Genau das war der Hauptzweck.

Nativ bauen, also einmal für jedes System. Am besten integriert, doppelte Arbeit, und ich kann weder Swift noch Kotlin.

React Native. Eine Codebasis, JavaScript und React — beides kannte ich. Der Zugriff auf Systemfunktionen läuft über Brücken zur jeweiligen Plattform.

Expo obendrauf war die Entscheidung, die den Einstieg tatsächlich möglich gemacht hat. Es nimmt einem den gesamten Aufbau der nativen Projekte ab, liefert eine Testumgebung auf dem eigenen Gerät und einen Baudienst, der die fertigen Pakete erzeugt.

Was anders ist als im Web

Es gibt kein CSS. Man schreibt Stilobjekte, die einer Teilmenge von CSS ähneln. Kein Kaskadieren, keine Selektoren, kein Vererben.

Es gibt kein div. Sondern View für Container, Text für Text — und zwar zwingend: Text muss in einer Textkomponente stehen, sonst gibt es einen Fehler.

Layout ist immer Flexbox, und flexDirection steht standardmäßig auf column statt row. Das ist der erste Stolperstein für jeden, der aus dem Web kommt.

Navigation ist eine Bibliothek, kein Browserverhalten. Zurück-Gesten, Bildschirmverlauf, Tab-Leisten — alles ausdrücklich zu bauen.

Der Zustand überlebt Wechsel in den Hintergrund. Eine App wird nicht neu geladen, wenn man sie wegklickt. Sie liegt im Hintergrund und kommt zurück — möglicherweise nach Stunden, mit veralteten Daten und abgelaufener Sitzung. Das ist ein Fall, den es im Web so nicht gibt und den man behandeln muss.

Der Teil, der wirklich Arbeit war

Nicht die Oberfläche. Es war alles, was mit dem Ausliefern zu tun hat.

Signierung. Beide Plattformen verlangen signierte Pakete, mit Schlüsseln, die man verwalten muss. Verliert man den Schlüssel, kann man keine Aktualisierung mehr ausliefern.

Berechtigungen. Benachrichtigungen brauchen Zustimmung, und die Abläufe unterscheiden sich je nach System.

Store-Regeln. Bei einer App, die ich nur selbst benutze, umgeht man das über direkte Installation oder interne Verteilung. Sobald sie in einen Store soll, kommt ein eigener Themenkomplex dazu.

Aktualisierungen über die Luft. Expo kann JavaScript-Änderungen ausliefern, ohne ein neues Paket zu bauen — solange sich am nativen Teil nichts ändert. Das ist ein enormer Vorteil und braucht Disziplin: Man muss wissen, welche Änderung nativ ist und welche nicht.

Was die App am Ende kann

Bewusst wenig, und das war die richtige Entscheidung:

• Zustand aller Dienste auf einen Blick — läuft, wie lange schon, letzte Meldung.
• Die letzten Fehlermeldungen aus dem gemeinsamen Protokoll.
• Neustart auslösen, mit Rückfrage.
• Benachrichtigungen bei kritischen Meldungen.

Kein Bearbeiten von Einstellungen, keine Nutzerverwaltung, keine Statistiken. Alles, was in Ruhe passieren kann, gehört an den Rechner. Die App ist für die Situation gebaut, in der ich nicht am Rechner bin — und dann will ich sehen, was los ist, und im Notfall einen Knopf drücken.

Was der Betrieb einer App vom Betrieb eines Webdienstes unterscheidet

Der Punkt, den ich am stärksten unterschätzt hatte: Bei einer App kann man nicht einfach ausliefern.

Eine Webseite ändert man, und beim nächsten Aufruf sehen alle die neue Fassung. Bei einer App liegt eine Kopie auf jedem Gerät, und dort bleibt sie, bis jemand aktualisiert.

Daraus folgen drei Dinge, die es im Web so nicht gibt:

Alte Fassungen bleiben in Betrieb. Manchmal monatelang. Die Schnittstelle muss also abwärtskompatibel bleiben oder eine Fassungsprüfung haben, die klar sagt „bitte aktualisieren".

Ein Fehler ist nicht sofort behebbar. Wenn ein Fehler nur im nativen Teil behoben werden kann, braucht es ein neues Paket und dessen Verteilung. Bei Änderungen im JavaScript-Teil geht es schneller — das ist der Hauptgrund, warum ich diesen Weg gewählt habe.

Man weiß nicht, wer welche Fassung hat, außer man erfasst es. Meine App meldet ihre Fassung bei jedem Start mit, und in der Geräteliste steht sie daneben.

Die Entscheidung, die App klein zu halten

Rückblickend ist die wichtigste Entscheidung dieses Projekts, was die App nicht kann.

Sie kann keine Einstellungen ändern, keine Nutzerdaten bearbeiten, nichts löschen. Sie zeigt Zustand und kann drei Aktionen auslösen, jede mit Rückfrage.

Der Grund ist nicht technische Bequemlichkeit, sondern eine Überlegung zum Zusammenhang: Ein Handy ist ein Gerät, das man unterwegs benutzt, oft nebenbei, manchmal in Eile. Das ist kein guter Zustand für Entscheidungen mit Folgen.

Alles, was in Ruhe passieren sollte, gehört an den Rechner. Die App ist für die Frage „ist alles in Ordnung?" und für den seltenen Fall, dass die Antwort nein lautet und man sofort etwas tun muss.

Was ich mitnehme

Der Aufwand für die App war überschaubar, und der Grund dafür liegt ein halbes Jahr früher: Die Schnittstelle existierte bereits, sauber getrennt, mit einheitlichen Antworten und einer Authentifizierung, die nicht an Browser-Sitzungen hängt.

Hätte ich die Verwaltung nicht vom Bot entkoppelt, hätte diese App entweder gar nicht existiert oder ich hätte eine zweite Schnittstelle bauen müssen. Das ist der beste Beleg dafür, dass eine saubere Grenze mehr wert ist als das Feature, für das man sie ursprünglich gezogen hat.