Frontend ¶

Inhaltsverzeichnis ¶

• Ziel und Zweck
• Umfang und Abgrenzung
• In Scope
• Out of Scope
• Systemkontext der Anwendung
• Architekturübersicht der Anwendung
• Architektur-Übersicht
• Datenmodell und Datenstruktur
• Implementierung der App
• Technologiestack und Technologiewahl
• Repository-Struktur
• Coding-Standards
• WebSockets und REST-API
• Umgesetzte Plugins
• Custom Hooks
• Lokales Setup und Entwicklung
• Voraussetzungen für die Entwicklung
• Installation der Anwendung für iOS und Android
• Deployment und Betrieb
• Lokale Entwicklungsumgebung
• Release-Prozess
• Monitoring und Alerting
• Backup und Restore
• Roll-out und Vorbereitung
• Anhang
• Glossar
• Abbildungsverzeichnis
• Literaturverzeichnis

Link zum Frontend: https://gitlab.sw2e-lab.de/finish-ing-2026/frontend
Link zur Präsentation: https://fh-swf.sciebo.de/s/zBmEWtD6HAtm2mS?dir=%2F&editing=false&openfile=true

Ziel und Zweck¶

Ziel des „Action-Connect-Hub“ Frontends ist die Bereitstellung einer plattformübergreifenden Benutzeroberfläche, über die physische IoT-Geräte einheitlich dargestellt, überwacht und gesteuert werden können. Es abstrahiert gerätespezifische Unterschiede auf Darstellungsebene und ermöglicht so eine konsistente Nutzererfahrung, unabhängig von der zugrunde liegenden Hardware. Damit entfällt die Notwendigkeit separater Anwendungen pro Produkt — ein Ansatz, der modernen IoT-Plattformkonzepten entspricht.

Die Anwendung ist auf Basis von React Native und dem Expo-Framework realisiert. Durch die Kombination mit React-Native-Web wird aus einer einzigen Codebasis heraus sowohl eine native Mobilapplikation für iOS und Android als auch eine webbasierte Variante erzeugt, die stets denselben Funktionsstand abbilden.

Das zentrale Designprinzip ist die Modellierung aller angebundenen Geräte über ein einheitliches „Thing Model“. Jedes Gerät trägt eine Liste typisierter „Capabilities“, die einzelnen Funktionen oder Sensorwerte beschreiben. Zur Laufzeit löst eine Plugin-Registry für jede „Capability“ dynamisch die passende UI-Komponente auf. Neue Gerätetypen lassen sich dadurch integrieren, ohne bestehenden Code zu verändern — die Erweiterbarkeit ist damit strukturell verankert und nicht nur konzeptionell angestrebt.
nach oben

Umfang und Abgrenzung¶

In Scope¶

1. Cross-plattform-Applikation
   • Entwicklung einer mobilen und webbasierten Anwendung auf Basis von React Native und Expo
   • Unterstützung der Zielplattformen Web, iOS und Android aus einer gemeinsamen Codebasis
   • Lokale Persistenz der ausgewählten Geräte-UUIDs mittels AsyncStorage
2. Navigation und Struktur
   • Startmenü (Dashboard) mit dynamisch geladenem Geräte-Raster oder -Liste
   • Detailansicht einzelner Geräte mit Telemetrieanzeige und Steuerungselementen
   • Responsives Layout mit optimierter Darstellung für Tablet- und Desktop-Bildschirme
3. UI-Komponenten
   • „DeviceCard“ zur kompakten Darstellung eines Geräts inklusive Verbindungsstatus und direkt steuerbarer featured „Capabilities“
   • „DevicePickerOverlay“ zur Auswahl und Verwaltung der angezeigten Geräte
   • Toast-Benachrichtigungen als visuelles Feedback nach Datenübertragungen
4. Schnittstellenkommunikation
   • REST-basierte API-Aufrufe über Axios zum Laden von Gerätedaten
   • „WebSocket“-Verbindung über Socket.IO für Echtzeit-Telemetrie, Statusänderungen und Invalidierungsereignisse
5. „Capability“-System
   • Plugin-Registry zur dynamischen Auflösung von UI-Komponenten anhand des „Capability“-Typs zur Laufzeit
   • Implementierung der „Capability“-Typen „ON_OFF“, „NUMBER“ (inklusive Graph- und Sliderdarstellung), „IMPULSE“, „ENUM“, „TEXT“, „MESSAGE“
   • Darstellung und direkte Steuerung von als „featured" markierten Capabilities auf der Startseit
6. Design und Theme
   • Zentrales Design-System mit Farbpalette, Typografie, Abständen und Schatten
   • Responsives Layout-System mit dynamischer Anpassung an die jeweilige Bildschirmgröße
   • Unterstützung von Hell- und Dunkelmodus
7. Lieferumfang
   • lauffähiger Quellcode
   • Inline-Dokumentation
   • Technische Dokumentation

Out of Scope¶

1. Bluetooth Low Energy (BLE)
   • BLE-Provisioning und -Konfiguration von Geräten
   • „BleContext“ und zugehörige Komponenten
2. Automationen und Regelwerk
   • Erstellung, Verwaltung und Ausführung von Automationsregeln
   • „RuleBuilder“-Komponenten und zugehörige API-Aufrufe
3. „ControllerCapability“
   • Joystick-basierte Steuerungskomponente für Geräte
4. Authentifizierung und Sicherheit
   • Login-Systeme und Benutzerkonten
   • Token- oder rollenbasierte Authentifizierung
5. Backend-Entwicklung
   • Keine Implementierung von Backend-Endpunkten
   • Keine Definition der finalen API-Spezifikation

nach oben

Systemkontext der Anwendung¶

flowchart TB

    A["Nutzer"]
    B["Action Connect App<br/>Web iOS Android (Expo)"]
    C["Connect Hub Backend<br/> hub.finishing2026.sw2e-lab.de"]
    D["IoT Geräte<br/> ESP32-basierte Produkte"]

A -- Interaktion (UI) --> B
B -- Anzeige/ Feedback --> A
C -- WebSocket<br/>(Telemetrie, Status, Events) --> B
B -- REST-API<br/>(Gerätedaten) --> C
C -- Gerätekommunikation<br/>(außerhalb des Scopes) --> D

sequenceDiagram
    participant N as Nutzer
    participant A as App
    participant D as Datenschicht<br/>(REST-APIs + sockets.ts)
    participant B as Backend

    N->>A: Interaktion auslösen
    A->>A: Optimistic Update
    A->>D: sendCommand(...)
    D->>B: s.emit("command", {...})

    alt Erfolg
        B-->>D: 200 OK
        D-->>A: success
        A-->>N: Toast (Erfolg)
    else Fehler
        B-->>D: error / offline
        D-->>A: throw Error
        A-->>N: Toast (Fehler)
    end

    B-->>D: emit "telemetry"
    D-->>A: onTelemetry(data)
    A-->>N: UI aktualisiert

Die „Action Connect App" ist als zentrale Interaktionsschicht zwischen Endnutzer und IoT-Plattform positioniert. Das System setzt sich aus vier wesentlichen Akteuren zusammen: dem Nutzer, der App selbst, dem „Connect-Hub Backend" sowie den angeschlossenen IoT-Geräten. Abbildung 1 zeigt den Systemkontext und die Kommunikationsbeziehungen der Anwendung zu ihren externen Partnersystemen. Die gestrichelte Umrandung markiert dabei die Systemgrenze dieser Dokumentation: Beschrieben wird ausschließlich das Frontend. Das Backend sowie die IoT-Geräte sind externe Systeme, die im Kontextdiagramm lediglich als Kommunikationspartner dargestellt werden.

Der Nutzer interagiert ausschließlich mit der App über deren grafische Benutzeroberfläche. Eingaben erfolgen in Form von Steuerungsaktionen — etwa das Betätigen eines Schalters, das Verschieben eines Sliders oder das Auslösen eines zustandslosen Impulsbefehls. Die App stellt dabei sicher, dass jede Eingabe visuell unmittelbar rückgekoppelt wird: Zustandsänderungen werden sofort in der Benutzeroberfläche sichtbar, unabhängig davon, ob die Übertragung zum Backend bereits abgeschlossen ist. Im Gegenzug erhält der Nutzer Rückmeldungen in Form aktualisierter Gerätezustände, Verbindungsstatusinformationen sowie Toast-Benachrichtigungen, die über den Erfolg oder das Scheitern einer Aktion informieren. Die Oberfläche ist responsiv gestaltet und ist gleichermaßen für Smartphones, Tablets und Desktop-Browser entwickelt.

Die App kommuniziert mit dem „Connect-Hub Backend" über zwei komplementäre Kanäle, die sich in ihrer Funktion und Kommunikationsrichtung bewusst unterscheiden. Für anfragenbasierte Operationen, insbesondere das initiale Laden von Gerätedaten sowie das „Thing Model“ mit den „Capabilities“ beim Start der App wird eine REST-Schnittstelle über HTTP genutzt. Hierbei initiiert stets die App die Kommunikation durch Anfragen an das Backend, das mit den entsprechenden Nutzdaten antwortet. Dieser Kanal ist somit einseitig und anfragengesteuert.

Für Updates im Betrieb hingegen wird eine persistente „WebSocket“-Verbindung eingesetzt, die bidirektionale Kommunikation ohne den Overhead einzelner HTTP-Anfragen ermöglicht. Über diesen Kanal werden Steuerbefehle — etwa das Einschalten eines Geräts oder das Setzen eines Wertes — als strukturierte Nachrichten an das Backend übermittelt. Gleichzeitig empfängt die App über dieselbe Verbindung kontinuierlich drei Arten von Ereignissen: Telemetriedaten mit aktuellen Sensorwerten, Statusänderungen, die signalisieren ob ein Gerät online oder offline ist, sowie Invalidierungssignale die einen Datenabruf für ein bestimmtes Gerät anstoßen. Diese Kombination aus gesendeten Befehlen und empfangenen Ereignissen über einen einzigen persistenten Kanal reduziert die Verbindungslatenz und ermöglicht eine reaktive Benutzeroberfläche ohne aktives Polling. Die Kommunikation zwischen dem Backend und den physisch angebundenen IoT-Geräten erfolgt über ein separates Protokoll und liegt außerhalb des Scopes dieser Dokumentation.

Abbildung 2 konkretisiert den Ablauf eines Steuerbefehls als Sequenzdiagramm und zeigt das Zusammenspiel der beteiligten Schichten des Frontends. Nachdem der Nutzer eine Interaktion auslöst — beispielsweise das Umlegen eines Toggle-Elements — führt die App zunächst ein lokales Zustandsupdate durch: Der angezeigte Wert der entsprechenden „Capability“ wird sofort angepasst, noch bevor eine Rückmeldung des Backends vorliegt. Dies verbessert die wahrgenommene Reaktionsfähigkeit der Anwendung erheblich, da der Nutzer keine durch Netzwerklatenzen bedingte Verzögerung bemerkt. Anschließend wird der Steuerbefehl über die Datenschicht des Frontends als „WebSocket“-Nachricht an das Backend übermittelt, die die betroffene UUID, die ID der „Capability“ sowie den neuen Wert enthält.

Im Erfolgsfall bestätigt das Backend den Eingang des Befehls mit einem Acknowledgment über denselben „WebSocket“-Kanal, woraufhin die App dem Nutzer eine visuelle Erfolgsbenachrichtigung in Form eines Toast-Elements anzeigt. Tritt hingegen ein Fehler auf — etwa durch einen Netzwerkausfall, eine Zeitüberschreitung oder einen Verarbeitungsfehler im Backend — wird eine entsprechende Fehlermeldung ausgegeben. In diesem Fall verbleibt der lokal gesetzte Zustand auf dem neuen Wert, da kein Rollback-Mechanismus implementiert ist.

Unabhängig von aktiven Steuerbefehlen empfängt die App Telemetrieereignisse vom Backend über denselben WebSocket-Kanal. Sobald ein solches Ereignis eintrifft, wird der lokale Gerätezustand im Frontend aktualisiert und die Benutzeroberfläche automatisch neu gerendert, ohne dass eine Nutzerinteraktion erforderlich ist. Eingehende Rohdaten des Backends werden dabei zunächst durch eine Normalisierungsfunktion in den internen „Thing"-Typ überführt, bevor sie in den Anwendungszustand übernommen werden. Dieses Muster stellt sicher, dass die dargestellten Sensorwerte und Verbindungsstatus stets dem tatsächlichen Gerätezustand entsprechen und Änderungen ohne Verzögerung sichtbar werden.
nach oben

Architekturübersicht der Anwendung¶

Architektur-Übersicht¶

flowchart TB

subgraph P["Präsentationsschicht"]
    direction LR
    A["Expo Router<br/>Navigation"]
    B["Screens<br/>Startmenü · Detail"]
    C["UI-Elemente<br/>Cards · Grid · Picker"]
    D["Theme<br/>Farben · Typo"]

    A---B---C---D
end

subgraph D1["Domänenschicht"]
    direction LR
    E["Plugin-Registry<br/>registerPlugin()"]
    F["CapabilityRenderer<br/>Laufzeit-Auflösung"]
    G["Capability-Plugins<br/>8 Capability-Typen"]
    H["Hooks<br/>Logik & State"]

    E---F---G---H
end

subgraph D2["Datenschicht"]
    direction LR
    I["REST (Axios)<br/>Gerätedaten"]
    J["socket.ts<br/>Befehle + Events"]
    K["Normalisierung<br/>Thing-Typ Mapping"]
    L["Persistenz<br/>UUID-Liste"]

    I---J---K---L
end

P --> D1
D1 --> D2

Die „Action Connect App“ ist als cross-plattformfähige Frontend-Anwendung auf Basis von React Native und dem Expo-Framework realisiert. Aus einer einzigen TypeScript-Codebasis heraus wird sowohl eine native mobile Applikation für iOS und Android als auch eine webbasierte Variante erzeugt. Das Routing innerhalb der Anwendung basiert auf dem dateibasierten Ansatz von Expo Router, bei dem die Verzeichnisstruktur unter „app/“ die Navigationsstruktur direkt definiert. Wie in Abbildung 3 gezeigt ist die Anwendung intern in drei logisch getrennte Schichten gegliedert: die Präsentationsschicht, die Domänenschicht sowie die Datenschicht.

Die Präsentationsschicht umfasst alle Benutzeroberflächen und Navigationsstrukturen. Der Einstiegspunkt ist das Startmenü, über das der Nutzer Geräte auswählen und koppeln kann. Außerdem ist es dem Nutzer bereits hier möglich, mit den wichtigsten vordefinierten Funktionen eines Gerätes zu interagieren und die wichtigsten Sensordaten einzusehen. Vom Startmenü aus navigiert er zur Detailansicht eines einzelnen Geräts, in der alle Telemetriedaten visualisiert und Steuerbefehle ausgelöst werden können. Wiederverwendbare UI-Elemente wie „DeviceCard“, „DevicesGrid“ und „DevicePickerOverlay“ sind im Verzeichnis „components/elements/“ organisiert. Ein zentrales Design-System in „theme/“ definiert Farben, Abstände, Typografie und Schatten einheitlich für alle Plattformen. Die Datei „theme/responsive.ts“ passt Layouts dynamisch an die jeweilige Bildschirmgröße an, sodass die Anwendung auf Smartphones, Tablets und Desktop-Geräten gleichermaßen nutzbar ist.

Die Domänenschicht bildet die zentrale Logikebene der Anwendung. Ihr wichtigstes Strukturelement ist die Plugin-Registry: Jeder „Capability“-Typ registriert sich zur Laufzeit eigenständig über die Funktion „registerPlugin()“. Der „CapabilityRenderer“ löst anhand des Typs einer „Capability“ dynamisch die passende UI-Komponente auf und delegiert die Darstellung an diese weiter. Dieses Muster entkoppelt die Logik vollständig von der Darstellung und folgt dem „Open-Closed-Prinzip“ — neue Capability-Typen können integriert werden, ohne bestehenden Code zu verändern. Ergänzend dazu kapseln React Hooks die Anwendungslogik ab. Der Hook „useStartmenu“ verwaltet das Laden und Live-Aktualisieren der Geräteliste. Der „TelemetryProvider“ kombiniert initiale HTTP-Abfragen mit eingehenden „WebSocket“-Ereignissen zu einer konsistenten Telemetriehistorie.

Die Datenschicht abstrahiert sämtliche Kommunikation mit externen Systemen. Die Datei „components/RestAPI.ts“ bündelt HTTP-basierte Operationen über Axios — ausschließlich für das Laden von Gerätedaten und die Telemetriehistorie. Die Datei „hooks/socket.ts“ verwaltet die persistente „WebSocket“-Verbindung, über die sowohl Steuerbefehle an das Backend gesendet als auch eingehende Ereignisse wie Telemetrie, Statusänderungen und Invalidierungssignale empfangen werden. Eingehende Rohdaten des Backends werden durch „normalizeThingRecord“ in den internen „Thing“-Typ überführt, sodass die darüberliegenden Schichten unabhängig vom konkreten Backend-Format bleiben. Die lokale Persistenz der ausgewählten Geräte-UUIDs erfolgt über „hooks/LocalStorage.ts“ mittels „AsyncStorage“.

Datenmodell und Datenstruktur¶

flowchart TB

    A["Thing<br/>device_id, connection"]
    B["Metadata<br/>label, category"]
    C["capabilities[]<br/>Liste von Funktionen"]
    D["State<br/>aktueller Zustand"]
    E["ON_OFF<br/>Schalter"]
    F["NUMBER<br/>Wert 1-100/ slider"]
    G["IMPULSE<br/>einmalige Auslösung"]

    A-->B
    A-->C
    A-->D
    C-->E
    C-->F
    C-->G

Die Datenkommunikation zwischen der „Action Connect App“ und dem Backend erfolgt auf Basis eines „Thing Models" im JSON-Format. Dieses Modell stellt eine klar strukturierte, einheitliche Repräsentation eines IoT-Geräts dar und bildet die zentrale Grundlage für die Abbildung, Steuerung und Darstellung sämtlicher Geräte innerhalb der Anwendung. Da unterschiedliche Geräte mit unterschiedlicher Sensorik und Funktionalität ausgestattet sein können, ermöglicht diese gemeinsame Datenstruktur, dass das Frontend Geräte abstrahieren kann, ohne für jeden Gerätetyp eine eigene Logik implementieren zu müssen. Jede Instanz des „Thing Models“, die vom Backend empfangen wird, durchläuft dabei eine Normalisierungsfunktion, die das Rohformat des Backends auf die intern verwendete Datenstruktur abbildet und so Inkonsistenzen frühzeitig abfängt.

Zunächst umfasst das „Thing Model“ grundlegende Identifikationsdaten, namentlich eine eindeutige UUID sowie eine gerätespezifische „device_id“. Diese beiden Kennungen erfüllen unterschiedliche Aufgaben: Die UUID referenziert das Gerät innerhalb des Backends eindeutig und wird automatisch bei der Registrierung generiert. Die „device_id“ hingegen wird verwendet, damit die Geräte besser durch Menschen verwaltet und gelesen werden können. Die UUID ist notwendig, um Steuerbefehle korrekt zuzuordnen und eingehende Telemetriedaten dem richtigen Gerät zuzuweisen — insbesondere bei parallellaufenden „WebSocket“-Subscriptions mehrerer Geräte ist diese eindeutige Zuordnung unverzichtbar. Daher kommt ein Gerät theoretisch auch ohne „device_id“ aus.

Darüber hinaus enthält das Modell Metadaten, die nicht-funktionale Informationen zum Gerät bereitstellen. Hierzu zählen insbesondere ein für den Nutzer lesbares Label sowie eine Gerätekategorie. Diese Metadaten besitzen selbst keinerlei funktionale Bedeutung für die Steuerung des Geräts, sind jedoch maßgeblich für die Verständlichkeit und intuitive Einordnung innerhalb der App verantwortlich — ein Nutzer soll ein Gerät auf den ersten Blick erkennen und einordnen können, ohne technische Details wie die UUID interpretieren zu müssen.

Den funktional bedeutsamsten Bestandteil des „Thing Models“ bildet die Liste der sogenannten „Capabilities". Jede „Capability“ beschreibt eine einzelne, klar abgegrenzte Funktion oder eine Eigenschaft eines Geräts und definiert damit, welche konkreten Interaktionsmöglichkeiten dem Nutzer in der Anwendung zur Verfügung gestellt werden. Neben dem „Capability-Typ“, der über die einzusetzende UI-Komponente entscheidet, enthält jede „Capability“ zusätzliche Parameter wie ein Anzeige-Label, optionale Wertebereichsgrenzen (Minimum und Maximum), eine Schrittweite sowie eine physikalische Einheitsbezeichnung. Ein weiterer zentraler Parameter ist die Kommunikationsrichtung, die festlegt, ob eine „Capability“ lediglich lesend (etwa ein reiner Sensorwert), ausschließlich schreibend (etwa ein einmaliger Auslösebefehl) oder bidirektional sowohl lesend als auch schreibend genutzt werden kann. Auf Grundlage dieser Parameter entscheidet die Plugin-Registry des Frontends zur Laufzeit dynamisch, welche konkrete UI-Komponente zur Visualisierung und Steuerung der jeweiligen „Capability“ eingesetzt wird, ohne dass hierfür gerätespezifischer Code notwendig ist.
nach oben

Implementierung der App¶

Technologiestack und Technologiewahl¶

Repository-Struktur¶

frontend/
├── babel.config.js
├── package-lock.json
├── package.json
├── components/
│   ├── plugins/
│   ├── elements/
│   ├── screens/
│   │   ├── start-menu.tsx
│   │   ├── device-detail.tsx
│   ├── types.ts
│   ├── CapabilityRenderer.tsx
│   ├── registry.ts
│   └── RestAPI.ts
├── theme/
├── assets/
│   └── images/
├── hooks/
│   ├── socket.ts
│   ├── start-menu.ts
│   ├── AppContext.tsx
│   ├── selectedThingContext.tsx
│   └── device-detail.ts
└── app/

Coding-Standards¶

Allgemeine Strukturprinzipien¶

Die Codebasis folgt einem klaren Strukturprinzip zur Sicherstellung von Übersichtlichkeit und Wiederverwendbarkeit.

Jede Komponente wird in einer eigenen Datei definiert. Darstellung, komponentenspezifische Logik und allgemeine Hilfsfunktionen werden konsequent in separate Dateien ausgelagert, um Redundanzen zu vermeiden und die Trennung von Verantwortlichkeiten zu gewährleisten. Alle TypeScript-Typen sind zentral in einer dedizierten Typdatei zusammengefasst. Alle Komponenten verwenden die in „theme/“ definierten Regeln. Dazu implementieren sie eigene Klassen innerhalb der Komponenten.

Ausnahmen bilden die Plugindateien, welche sowohl Darstellung, Typen als auch nötige, rudimentäre Funktionen vereinen, um eine optimale Erweiterbarkeit zu gewährleisten.

Namenskonventionen¶

Die Namensgebung folgt einheitlichen Konventionen, die eine konsistente Lesbarkeit im gesamten Projekt sicherstellen.

Ordner werden grundsätzlich mit einem Kleinbuchstaben begonnen. Besteht ein Ordnername aus mehreren Wörtern, werden diese entweder durch einen Bindestrich voneinander getrennt oder durch einen Großbuchstaben am Wortanfang kenntlich gemacht.

Dateinamen beginnen ebenfalls kleingeschrieben, wobei jedes folgende Wort mit einem Großbuchstaben eingeleitet wird. Exportiert eine Datei React-Komponenten, gelten stattdessen die Konventionen für Komponentennamen.

Komponentennamen beginnen mit einem Großbuchstaben, und jedes weitere Wort folgt demselben Muster. Der gewählte Name soll die Aufgabe oder Rolle der Komponente eindeutig beschreiben.

Variablennamen starten mit einem Kleinbuchstaben; jedes folgende Wort beginnt groß. Die Bezeichnung muss den Inhalt oder Zweck der Variable klar erkennbar machen.

Konstanten werden vollständig in Großbuchstaben geschrieben. Mehrere Wörter werden durch einen Unterstrich getrennt.

Props und State-Variablen müssen selbsterklärend sein, sodass ihre Bedeutung beim Übergeben ohne zusätzlichen Kontext verständlich bleibt. Ein Name aus mindestens zwei Wörtern ist verpflichtend.

Funktionen erhalten Namen, die die ausgeführte Aktion beschreiben. Jeder Funktionsname beginnt mit einem Verb.

Event-Handler beginnen entweder mit „handle“ oder „on“ und folgen ansonsten den Regeln für Funktionsnamen.

Übergreifend gilt: Namen sollen prägnant, aber dennoch aussagekräftig sein. Abkürzungen sind zu vermeiden, sofern es sich nicht um allgemein gebräuchliche Kurzformen handelt. Innerhalb des gesamten Projekts werden die beschriebenen Konventionen einheitlich eingehalten. Beim Import von Modulen werden konsistente, beschreibende Bezeichner verwendet, und importierte Dateien behalten ihren ursprünglichen Dateinamen. [1]

Inline-Dokumentation¶

Jede Funktion wird durch einen kurzen Kommentar dokumentiert, der ihre Parameter sowie ihr Verhalten beschreibt. Darüber hinaus enthält jede Datei einen einleitenden Beschreibungstext, der Zweck und Aufgaben der Datei zusammenfasst. Innerhalb von Render-Funktionen werden die einzelnen Darstellungsbereiche durch Kommentare strukturiert und kenntlich gemacht.

Theme-System¶

Die projektweiten Gestaltungsregeln sind im Verzeichnis „theme/“ zentralisiert. In „responsive.ts“ sind Funktionen zur dynamischen Anpassung des Layouts an unterschiedliche Bildschirmgrößen definiert. Die Datei „ui.ts“ stellt vordefinierte Designklassen bereit, die komponentenübergreifend wiederverwendet werden. Sie enthält Klassen mit Styles, die häufig von Komponenten verwendet werden. Alle weiteren Dateien innerhalb des Verzeichnisses enthalten grundlegende Layoutregeln, die App-weit Gültigkeit besitzen. Sämtliche Inhalte des „theme/“-Verzeichnisses stehen allen Komponenten der Anwendung zur Verfügung.

WebSockets und REST-API¶

Die Kommunikation zwischen der „Action Connect App“ und dem „Connect-Hub“ Backend erfolgt über zwei komplementäre Kanäle, die sich in Funktion und Kommunikationsrichtung bewusst unterscheiden.

REST-basierte Operationen sind in der Datei „RestAPI.ts“ über die Bibliothek Axios zentralisiert. Sie umfassen ausschließlich anfragenbasierte Vorgänge, bei denen der Client aktiv Daten anfordert: das initiale Laden der Geräteliste über „loadDevices“ und das Abrufen von Gerätedetails über „fetchDeviceDetails“. Alle vom Backend gelieferten Rohdaten werden durch die Funktion „normalizeThingRecord“ in den intern verwendeten „Thing“-Typ überführt, sodass die darüberliegenden Schichten unabhängig vom konkreten Backend-Datenformat bleiben.[2]

Für zeitkritische Operationen kommt eine persistente „WebSocket“-Verbindung auf Basis von socket.io-client zum Einsatz, verwaltet durch die Datei „socket.ts“. Steuerbefehle — etwa das Setzen eines „Capability“-Wertes — werden über diesen Kanal als strukturierte Nachrichten an das Backend übermittelt. Gleichzeitig empfängt die App über dieselbe Verbindung drei Arten von Ereignissen: telemetry-Events mit aktuellen Sensorwerten, status-Events bei Verbindungsänderungen eines Geräts sowie invalidate-Events, die einen gezielten Datenneuabruf für ein bestimmtes Gerät anstoßen. Dieser Mechanismus stellt sicher, dass der lokale Anwendungszustand kontinuierlich synchronisiert wird, ohne dass der Nutzer manuell aktualisieren muss.[3]

Die Einbindung beider Kommunikationskanäle in die Benutzeroberfläche erfolgt über spezialisierte React-Hooks. Der Hook „useThingScreen“ in „hooks/device-detail.ts“ ist für das Senden von Steuerbefehlen sowie die unmittelbare lokale Zustandsaktualisierung auf dem Detailbildschirm zuständig. Der Hook „useStartmenu“ verwaltet das Laden und Aktualisieren der Geräteliste auf der Startseite. Der „TelemetryProvider“ in „hooks/AppContext.tsx“ kombiniert initiale REST-Abfragen mit eingehenden WebSocket-Ereignissen zu einer konsistenten Telemetriehistorie für die Detailansicht. Alle drei Hooks trennen Datenhaltung und Darstellung voneinander und steuern zudem das visuelle Feedback gegenüber dem Nutzer, etwa durch Ladeanzeigen und Toast-Benachrichtigungen.

Die Konfiguration der Backend-Anbindung erfolgt über Umgebungsvariablen, die in einer .env-Datei hinterlegt werden. Expo stellt diese Werte zur Laufzeit über das EXPO_PUBLIC_-Präfix bereit, ohne dass sie in den kompilierten Quellcode einfließen. Dadurch lässt sich die Anwendung ohne Codeänderungen für unterschiedliche Deployment-Umgebungen konfigurieren.

Umgesetzte Plugins¶

Das Plugin-System der „Action Connect App“ bildet die zentrale Abstraktion zur einheitlichen Repräsentation heterogener IoT-Geräte. Indem alle Gerätefunktionen über einen gemeinsamen Satz typisierter Plugins beschrieben werden, lassen sich beliebige Geräte ohne gerätespezifischen Code in die Plattform integrieren. Das Modell unterscheidet zwischen zustandsbehafteten Typen, die einen persistenten Wert halten, und zustandslosen Typen, die ausschließlich Ereignisse auslösen. Ebenso wird zwischen lesenden, schreibenden und bidirektionalen Zugriffsrichtungen differenziert, aus denen die „Plugin-Registry“ zur Laufzeit die passende UI-Komponente ableitet.

„ON_OFF“
Dieser Typ bildet binäre Gerätezustände ab, die genau zwei Ausprägungen kennen: aktiv oder inaktiv. Er ist bidirektional ausgelegt — der aktuelle Zustand kann sowohl abgerufen als auch gesetzt werden. In der Benutzeroberfläche wird der Typ durch ein Toggle-Element dargestellt, das den Zustand unmittelbar sichtbar macht und durch einfache Interaktion änderbar ist.

„NUMBER“
Der Typ „NUMBER“ repräsentiert kontinuierliche Zahlenwerte und unterstützt optionale Konfigurationsparameter wie Minimum, Maximum, Schrittweite und Einheit. Anhand dieser Parameter berechnet die App den aktuellen Wert als relativen Anteil des definierten Wertebereichs. Je nach display-Parameter des „Capability-Objekts“ wählt das Plugin automatisch die passende Darstellungsform — Slider für Steuerungsaufgaben, Graph oder Gauge für Monitoring. Der Typ ist bidirektional und eignet sich damit gleichermaßen zur Anzeige von Sensorwerten wie zur aktiven Steuerung.

„IMPULSE“
„IMPULSE“ beschreibt zustandslose Aktionen, die keinen persistenten Wert hinterlassen. Der Typ ist ausschließlich schreibbar und dient der Auslösung diskreter Operationen wie dem Zurücksetzen eines Systems oder dem Auslösen eines einmaligen Vorgangs. In der UI wird ein einfacher Button verwendet, dessen Betätigung den Befehl direkt abschickt, ohne einen lokalen Zustand zu verändern.

„ENUM“
Dieser Typ modelliert eine geschlossene Menge vordefinierter Auswahloptionen, aus denen der Nutzer genau eine wählen kann. Da nur die im „Capability-Objekt“ hinterlegten Werte zulässig sind, wird serverseitig wie clientseitig ein konsistenter Zustand sichergestellt. Der Typ ist bidirektional; in der Benutzeroberfläche kommt ein Dropdown-Element zum Einsatz.

„TEXT“
„TEXT“ ermöglicht die Verarbeitung und Anzeige beliebiger Zeichenketten. Das optionale pattern-Feld erlaubt es, das erwartete Format einzuschränken — etwa für Farbcodes im Hex-Format oder strukturierte Datumswerte. Abhängig vom konkreten Anwendungsfall rendert das Plugin ein einfaches Textfeld, einen Farbwähler oder ein Datumseingabeelement.

„MESSAGE“
Der Typ „MESSAGE“ ist ausschließlich lesbar und dient der passiven Informationsdarstellung. Strukturierte Nachrichtenobjekte können unterschiedliche Schweregrade tragen — etwa Info, Warnung oder Fehler — die das Plugin farblich und ikonografisch unterscheidet. Eine Nutzerinteraktion zur Zustandsänderung ist bei diesem Typ nicht vorgesehen.

Custom Hooks¶

„start-menu.ts/useStartMenu“
Der Hook „useStartmenu“ bildet die zentrale Logikschicht des Startmenüs und kapselt sämtliche Zustandsverwaltung sowie Datenkommunikation ab, die für die Geräteübersicht erforderlich ist.

Beim Mounten liest der Hook zunächst die lokal persistierten Geräte-UUIDs aus dem „AsyncStorage“. Anhand dieser Liste werden die zugehörigen Thing Models gebündelt über einen einzigen Batch-Request vom Backend geladen. Schlägt dieser fehl — etwa durch einen Netzwerkfehler — fällt der Hook automatisch auf sequenzielle Einzelabrufe pro Gerät zurück. Im Anschluss wird für jedes Gerät die neueste Telemetrie geladen und in den lokalen State gemergt. Die fertige Geräteliste wird abschließend nach der im lokalen Speicher hinterlegten UUID-Reihenfolge sortiert, sodass eine vom Nutzer per Drag-and-Drop festgelegte Anordnung auch nach einem App-Neustart erhalten bleibt.

Parallel zum initialen Datenabruf wird eine WebSocket-Verbindung aufgebaut, über die der Gerätezustand kontinuierlich aktuell gehalten wird. Eingehende Telemetrie-Events werden direkt in den State des betroffenen Geräts gemergt. Statusänderungen — etwa wenn ein Gerät die Verbindung verliert oder wiederherstellt — werden sowohl im State als auch als Toast-Benachrichtigung für den Nutzer sichtbar gemacht. Invalidierungssignale lösen einen gezielten Datenneuabruf für das betroffene Gerät aus. Für jedes geladene Gerät wird dabei eine individuelle „WebSocket-Subscription“ verwaltet, damit das Backend Events gezielt an diesen Client adressieren kann.

Das Senden von Steuerbefehlen erfolgt ebenfalls über diesen Hook: Der lokale Gerätezustand wird unmittelbar nach der Nutzerinteraktion aktualisiert, bevor die Antwort des Backends vorliegt. Anschließend wird der Befehl über die Datenschicht übermittelt. Über eine Toast-Benachrichtigung erhält der Nutzer Rückmeldung über Erfolg oder Misserfolg der Übertragung.

„device-detail.ts/useThingScreen“
Der Hook „useThingScreen“ kapselt die Interaktionslogik der Gerät-Detailansicht ab und steuert die bidirektionale Kommunikation zwischen Benutzeroberfläche und Backend.

Beim Mounten wird eine „WebSocket“-Verbindung aufgebaut, über die drei Ereignistypen verarbeitet werden. Eingehende Telemetrie-Werte werden in den lokalen „Thing“-State gemergt, wobei „Capabilities“ mit noch ausstehenden Befehlen gezielt ausgenommen werden, um Race Conditions zwischen lokalem Update und eingehendem Event zu vermeiden. Statusänderungen aktualisieren den Verbindungszustand des Geräts. Invalidierungssignale lösen einen Datenneuabruf aus, wobei der bestehende lokale State erhalten bleibt.

Das Senden von Steuerbefehlen folgt einem optimistischen Muster: Der lokale Zustand wird unmittelbar nach der Nutzerinteraktion angepasst, noch bevor die Antwort des Backends vorliegt. Vor dem Senden wird der übergebene Wert auf Typkonformität geprüft, da das Backend ausschließlich primitive Datentypen akzeptiert. Im Erfolgsfall werden die Gerätedaten neu abgerufen. Bei einem Offline-Fehler wird der lokale Zustand auf den Stand vor der Interaktion zurückgesetzt und der Verbindungsstatus auf OFFLINE gesetzt. Bei sonstigen Fehlern verbleibt der optimistisch gesetzte Zustand. In allen Fällen erhält der Nutzer eine Toast-Benachrichtigung über das Ergebnis der Übertragung.

„AppContext.tsx/TelemetryProvider“
Der „TelemetryProvider“ bildet die zentrale Komponente zur Bereitstellung und Verwaltung von Telemetriedaten innerhalb der Anwendung. Als React-Provider kapselt er die gesamte Logik für den Bezug, die Speicherung und die Aktualisierung von Telemetriedaten eines ausgewählten Geräts ab. Hierzu stellt er seinen Kindkomponenten über den „TelemetryContext“ sowohl die aktuelle Telemetriehistorie als auch Funktionen zum Nachladen historischer Daten zur Verfügung. Um Race-Conditions zu vermeiden wird die Funktion „mergeNewestFirst“ verwendet, die zwei Listen von Telemetriedaten zusammenfügt.

Beim Initialisieren des Providers wird eine „WebSocket“-Verbindung aufgebaut und das ausgewählte Gerät abonniert. Dadurch können eingehende Telemetriedaten in Echtzeit verarbeitet werden. Neue Messwerte werden automatisch in die bestehende Historie integriert, wodurch die Anwendung jederzeit den aktuellen Gerätezustand widerspiegelt. Zusätzlich ermöglicht der Provider das Laden historischer Messwerte. Je nach ausgewähltem Zeitraum werden die entsprechenden Daten vom Backend angefordert und die aktuell angezeigte Historie aktualisiert.

Durch die Bündelung dieser Funktionen in einer eigenständigen Provider-Komponente wird eine klare Trennung zwischen Datenbeschaffung und Darstellung erreicht. Dies verbessert die Wartbarkeit der Anwendung und ermöglicht den konsistenten Zugriff auf Telemetriedaten aus verschiedenen Komponenten heraus, ohne dass diese die zugrunde liegenden Kommunikationsmechanismen selbst implementieren müssen.

„selectedThingContext“
Der „SelectedThingProvider“ übernimmt die zentrale Verwaltung des aktuell ausgewählten Geräts innerhalb der Anwendung. Hierfür nutzt er das Context-API von React, um die Geräteauswahl global bereitzustellen und für alle untergeordneten Komponenten zugänglich zu machen. Dadurch wird vermieden, dass Informationen über die ausgewählte Instanz über mehrere Komponentenebenen hinweg als Eigenschaften weitergegeben werden müssen.

Der Provider verwaltet den Zustand des ausgewählten Geräts mittels eines React-State-Hooks und stellt sowohl den aktuellen Wert als auch eine Funktion zur Aktualisierung der Auswahl über den Kontext bereit. Durch den Einsatz von „useCallback“ und „useMemo“ werden unnötige Neuerzeugungen von Funktionen und Kontext-Werten reduziert, wodurch unnötige Re-Renderings von konsumierenden Komponenten vermieden werden können. Dies trägt insbesondere bei größeren Anwendungen zu einer verbesserten Performance bei.

Der ergänzende Hook „useSelectedThing“ kapselt den Zugriff auf den Kontext und stellt sicher, dass dieser ausschließlich innerhalb eines „SelectedThingProvider“ verwendet wird. Dadurch wird eine konsistente Nutzung des globalen Zustands gewährleistet und potenzielle Fehler durch eine falsche Einbindung frühzeitig erkannt. Insgesamt bildet der „SelectedThingProvider“ die Grundlage für eine zentrale und konsistente Geräteauswahl innerhalb der Anwendung.
nach oben

Lokales Setup und Entwicklung¶

Voraussetzungen für die Entwicklung¶

Windows 11 1. Download des offiziellen Windows‑11-Installationsmediums (ISO oder Media Creation Tool). 2. Erstellung eines bootfähigen USB‑Installationsdatenträgers. 3. BIOS/UEFI-Konfiguration: - Aktivierung von Secure Boot und TPM 2.0. - Anpassung der Boot-Reihenfolge (USB als primäres Medium). 4. Durchführung der Installation über den Setup-Assistenten. 5. Abschlusskonfiguration: - Benutzerkonto, Netzwerk, Datenschutzoptionen. 6. Installation aktueller Treiber 7. Durchführung von Windows Updates

Visual Studio Code 1. Download der aktuellen Version von VS-Code 2. Ausführung des Installationsprogramms mit folgenden Optionen: - Integration in PATH aktivieren - Kontextmenüeinträge hinzufügen 3. Installation von ESLint (Code-Qualität) - Prettier (Code-Formatierung) - GitLens (Versionskontrolle) - React Native Tools (für mobile Entwicklung) 4. Anpassung der Einstellungen nach persönlichen Preferenzen

GitHub 1. Download und Installation mit Standardoptionen: - Nutzung der Git Bash - Integration in System-PATH 2. Festlegung von Benutzerinformationen: - git config --global user.name "Name" - git config --global user.email email@example.com 3. Erstellung eines Accounts auf GitHub. 4. Generierung eines SSH-Schlüssels: - ssh-keygen -t ed25519 -C email@example.com 5. Hinterlegung des Public Keys im GitHub-Profil. 6. Test der Verbindung: - ssh -T git@github.com 7. Klonen eines Repositories: - git clone repository-url 8. Nutzung von Feature-Branches 9. Pull-Requests für Code-Reviews

Integration von Komponenten 1. Verknüpfung der Tools: - VS-Code als primäre Entwicklungsumgebung verwenden. - Android Studio ausschließlich für Emulator und SDK-Management nutzen. - GitHub zur Versionskontrolle und Kollaboration einsetzen. 2. Validierung der Gesamtumgebung: - Start des Android-Emulators. - Ausführen eines Projekts über VS-Code (z. B. React Native). - Überprüfung der Git-Integration (Commit, Push)

Installation der Anwendung für iOS und Android¶

Installation der Anwendung aus dem App-Store¶

Für iOS-Geräte wird die „Action Connect App“ über den Apple App-Store bereitgestellt. Voraussetzung für die Installation sind ein iPhone oder iPad mit einer aktuellen iOS-Version, eine bestehende Internetverbindung sowie eine Apple ID, da der Zugriff auf den App Store eine Anmeldung erfordert.

Zur Installation öffnet der Nutzer die App-Store-App und sucht über das Suchfeld nach dem Anwendungsnamen. In der Ergebnisliste wählt er den passenden Eintrag aus, woraufhin sich die Detailseite der App öffnet. Diese enthält eine Beschreibung der Funktionen, Angaben zum Entwickler, Nutzerbewertungen sowie Informationen zu den erforderlichen Systemberechtigungen und der Kompatibilität mit dem Gerät.

Ein Tippen auf die Schaltfläche „Laden" öffnet ein Autorisierungsverfahren, bei dem sich der Nutzer via Fingerabdruck, Passwort oder Gesichtserkennung autorisieren muss. Danach startet den Downloadvorgang. Das Betriebssystem lädt die Anwendung herunter und installiert sie automatisch. Fordert die App bestimmte Systemberechtigungen an — etwa für Netzwerkzugriff oder lokale Benachrichtigungen — erscheint eine entsprechende Abfrage beim ersten Start der jeweiligen Funktion.

Nach abgeschlossener Installation lässt sich die App direkt aus dem App Store öffnen oder über den Startbildschirm des Geräts starten.

Installation der Anwendung aus dem Google Play-Store¶

Die „Action Connect App“ wird über den Google Play Store für Android-Geräte bereitgestellt. Voraussetzung für die Installation sind ein Android-Endgerät, eine bestehende Internetverbindung sowie ein aktives Google-Konto, da der Zugriff auf den Play Store eine Anmeldung erfordert.

Zur Installation öffnet der Nutzer die Play-Store-App und sucht über das Suchfeld nach dem Anwendungsnamen. In der Ergebnisliste wählt er den passenden Eintrag aus, woraufhin sich die Detailseite der App öffnet. Diese enthält eine Kurzbeschreibung der Funktionen, Angaben zum Entwickler sowie Nutzerbewertungen.

Ein Tippen auf die Installationsschaltfläche startet den Downloadvorgang. Das Betriebssystem lädt die Anwendung herunter und installiert sie automatisch, ohne dass weitere Schritte erforderlich sind. Fordert die App bestimmte Systemberechtigungen an — etwa für Netzwerkzugriff oder Gerätespeicher — erscheint eine entsprechende Abfrage entweder während der Installation oder beim ersten Start der jeweiligen Funktion.

Nach abgeschlossener Installation lässt sich die App direkt aus dem Play Store öffnen oder über das App-Menü des Geräts starten.
nach oben

Deployment und Betrieb¶

Lokale Entwicklungsumgebung¶

Im Rahmen des Projekts wird die entwickelte React‑Native‑Applikation primär in einer lokalen Entwicklungsumgebung ausgeführt. Hierzu kommt das Framework Expo zum Einsatz, welches die Anwendung auf einem Server betreibt, sodass sie vom Entwickler im Browser getestet werden kann. Eine Unterteilung in mehrere Entwicklungsumgebungen, wie sie in professionellen Softwareprojekten üblich ist, wird in diesem Projekt nur rudimentär berücksichtigt. Die Anwendung wird überwiegend in Visual Studio Code getestet und validiert.

Release-Prozess¶

Der Release‑Prozess erfolgt in vereinfachter Form und orientiert sich an einem klassischen Entwicklungsablauf. Änderungen am Quellcode werden lokal implementiert und anschließend direkt im Emulator getestet. Ein formalisierter Continuous‑Integration‑ oder Continuous‑Deployment‑Prozess ist nicht Bestandteil des Projekts. Stattdessen wird die Funktionsfähigkeit der Anwendung durch manuelle Tests sichergestellt. Die Bereitstellung erfolgt durch das Erstellen eines Builds innerhalb der Entwicklungsumgebung, wodurch die Anwendung auf dem Emulator ausgeführt werden kann.

Monitoring und Alerting¶

Da die Anwendung ausschließlich im Entwicklungs- und Demonstrationskontext eingesetzt wird, wurde auf die Implementierung eines vollumfänglichen Monitoring- und Alerting-Konzepts verzichtet. Zur grundlegenden Beobachtung des Systemzustands kommen zwei Werkzeuge zum Einsatz: Grafana als webbasierte Plattform zur Visualisierung von Metriken und Nutzeraktivitäten sowie Dozzle als leichtgewichtiger Log-Viewer zur Echtzeit-Anzeige von Container-Logs. Auftretende Fehler werden manuell untersucht und behoben. Automatisierte Benachrichtigungs- oder Eskalationsmechanismen sind nicht vorgesehen.

Backup und Restore¶

Da die Anwendung keine persistenten oder kritischen Nutzerdaten speichert, ist die Implementierung eines dedizierten Backup- und Restore-Konzepts im Rahmen dieses Projekts nicht notwendig. Die Sicherung des Projektfortschritts erfolgt stattdessen über eine Versionsverwaltung, welche Änderungen am Quellcode systematisch erfasst und dokumentiert. Dies ermöglicht eine transparente Nachverfolgung der Entwicklung sowie die Wiederherstellung vorheriger Bearbeitungsstände. Auf diese Weise wird eine angemessene Absicherung des Projekts erreicht, ohne zusätzliche Backup-Infrastrukturen bereitstellen zu müssen.

Roll-out und Vorbereitung¶

Die Veröffentlichung einer Expo-Anwendung erfolgt über den Aufbau eines Produktions-Builds und dessen Einreichung bei offiziellen App-Stores. Zentrales Werkzeug ist dabei Expo Application Services (EAS), das die Erstellung nativer Builds für Android und iOS abstrahiert und in der Cloud ausführt. Voraussetzung ist ein konfiguriertes Build-Profil in der Datei eas.json sowie ein Entwicklerkonto im jeweiligen Store-Ökosystem.

Der Build wird per EAS-CLI gestartet und erzeugt standardmäßig ein Android App Bundle (.aab), das für die Distribution über den Google Play Store optimiert ist, da es gerätespezifische Installationspakete ermöglicht. Der fertige Build kann anschließend über eas submit direkt in die Google Play Console eingereicht werden. Alternativ lässt sich die Binärdatei manuell aus dem EAS-Dashboard herunterladen und in der Play Console hochladen, wo zunächst interne Testversionen erstellt und validiert werden können. Durch die Einrichtung eines Google Service Accounts lässt sich dieser Prozess in eine CI/CD-Pipeline integrieren und vollständig automatisieren.

Produktions-Builds können ausschließlich über den jeweiligen Store installiert werden — eine direkte Installation auf einem Emulator oder Gerät ist standardmäßig nicht vorgesehen.

Neben dem cloudbasierten Ansatz über EAS bietet Expo auch die Möglichkeit, Builds lokal zu erzeugen. Hierfür sind native Build-Werkzeuge wie OpenJDK sowie ein Upload-Schlüssel zur Signierung der Anwendung erforderlich. Zudem muss über npx expo prebuild zunächst ein natives Projektverzeichnis erzeugt werden, das die Grundlage für den Build-Prozess bildet.
nach oben

Anhang¶

Glossar¶

"Thing Model" Datenstruktur, die Daten über die IoT-Geräte in einem JSON-Format enthält.
"Capability" Funktion oder Sensorwert, die ein Gerät besitzt.
Plugin Komponente, die die App um weiter Funktionen erweitert.
Registry Komponente, die eine Registrierungsliste verwaltet, in die alle Plugins zur Laufzeit geschrieben werden.
"CapabilityRenderer" Komponente, die zu einer "Capability" das passende Plugin sucht.
Telemetrie Daten, die Messwerte und Nutzereingaben von und zu den IoT-Geräten beinhalten.
Telemetriehistorie Historie von Telemetriedaten.
Optimistic Update Optimistic Updates sind sichtbare Änderungen in der lokalen App, bevor sie vom Server bestätigt wurden.[4]
Invalidierungsereignis Invalidierungsereignisse erzwingt das erneute Abfragen veralteter Daten.[5]
"WebSockets" "WebSockets" sind in der Bibliothek Socket.IO definiert. Sie ermöglichen eine stationäre, bidirektionale und Event-basierte Kommunikation zwischen einem Client und einem Server über HTTP.[3]
REST-API Eine REST-API ist ein webbasiertes Application Programming Interface (API), welches den REST-Designprinzipien folgt.[6]
Hook Hooks erlauben es States und weitere React Features zu nutzen, ohne Klassen definieren zu müssen.
Context API Erlaubt es, Daten jeder Komponente im Projekt zur Verfügung zu stellen, ohne Prop Drilling zu müssen.[7]
AsyncStorage AsyncStorage ist ein unverschlüsseltes, asynchrones, persistentes Key-Value Speichersystem, welches global in der App genutzt werden kann.[8]
Expo Router Expo Router ist eine Datei-basierte Bibliothek für Webanwendungen und React Native, welche dafür eingesetzt wird die Navigation zwischen einzelnen Screens zu verwalten.[9]

Abbildungsverzeichnis¶

[1] Marius Kroel: FinishING
https://eu02web.zoom.us/wb/doc/2vTbwKjoRGyembR-Yi_4ZQ/p/106992666279936

[2] Torsten Wilp: eigene Darstellung

Literaturverzeichnis¶

[1] dev.to: React JS - Naming convention
https://dev.to/kristiyanvelkov/react-js-naming-convention-lcg

[2] npm: Axios
https://www.npmjs.com/package/axios

[3] npm: socket.io-client
https://www.npmjs.com/package/socket.io-client

[4] Medium: What are Optimistic Updates?
https://medium.com/@kyledeguzmanx/what-are-optimistic-updates-483662c3e171

[5] coreui: How to invalidate queries in React Query
https://coreui.io/answers/how-to-invalidate-queries-in-react-query/

[6] IBM: Was ist REST-API?
https://www.ibm.com/de-de/think/topics/rest-apis

[7] Geeks for Geeks: Context API in React
https://www.geeksforgeeks.org/reactjs/explain-new-context-api-in-react/

[8] React Native: AsyncStorage
https://reactnative.directory/package/@react-native-async-storage/async-storage

[9] Expo: Introduction to Expo Router
https://docs.expo.dev/router/introduction/

nach oben