# ADR-Entwurf: Gemeinsame Weboberfläche + lokale Android-WebView

Datum: 2026-10-14 · Status: **Experiment, noch keine freigegebene Produktionsarchitektur**

## Kontext

- Gleiche Neon-Corporate-Designsprache für Android-App und mobile Website.
- Laravel 13 ist zentrale Geschäftslogik, MySQL persistent, Redis/WebSocket für Echtzeit.
- Domains laut Planung: `m.wetslip.net`, `api.wetslip.net`, `img.wetslip.net`, `www.wetslip.net`.
- Android-App muss bei Netzunterbrechung eine brauchbare Oberfläche bieten.

## Zielarchitektur

- Ein gemeinsamer Satz statischer UI-Dateien wird auf `m.wetslip.net` **über HTTPS** ausgeliefert und mit einer signierten Android-APK ausgeliefert.
- In der APK lädt eine Flutter-Hülle das lokale Paket über einen abgesicherten HTTPS-Origin mit Android `WebViewAssetLoader` (nativ oder plugin-kompatibel). `file://` und `allowUniversalAccessFromFileURLs` sind nicht erforderlich.
- Backend-Endpunkte ausschließlich via `https://api.wetslip.net`; Auth, Berechtigungen, Rollen, Moderation, Altersprüfung und alle Schreiboperationen serverseitig.
- `img.wetslip.net` ist Auslieferungsorigin für Medien mit geeigneten, kurzlebigen Berechtigungen für private Medien; keine öffentlichen URLs für private Inhalte.
- Separate SSR-Lösung für SEO-relevante öffentliche `www`-Seiten.

## Offline-Stufen

**0 – immer:** App-Shell, Assets, Navigation, Einstiegsseite und Offline-Hinweis (in APK gebündelt; im Browser nach Cache-Installation).

**1 – lesend:** Freigegebene öffentliche Listing-Metadaten und öffentliche Vorschaubilder mit begrenzter Lebensdauer in IndexedDB/Cache Storage. Anzeige als *zuletzt synchronisiert*, niemals als live. Maximalumfang und automatische Löschung definieren.

**2 – lokal:** Nichtkritische Bearbeitungsentwürfe und Favoriten-Warteliste optional. Nutzer-initiierte Wiederholung von Aktionen mit Serverbestätigung und Idempotency-Key; niemals unbemerkt Kauf-/Zahlungsaufträge nach Netzrückkehr absenden.

**3 – privat:** Nachrichten und sensible Mediendaten nicht per Service Worker unkontrolliert cachen. Falls später explizite Offline-Chatfunktion erwünscht: lokaler verschlüsselter, angemessen geschützter Speicher, Session-Lifecycle, Logout-Löschung, Geräteverlust, Backups und Aufbewahrungsdauer separat spezifizieren.

## Service Worker

- **Nur gleicher Origin**, statische Shell, ausdrücklicher Demo-Katalog.
- Keine API-/Auth-/Private-Routen, keine Cross-Origin-Medien; keine Auth-Antworten oder privaten Images.
- Statische Dateien per versioniertem Cache. Navigationsrequests network-first, offline lokale Shell.
- Unter `m.wetslip.net` funktioniert dies via HTTPS. In der Android-WebView dienen mitgelieferte Assets als primäre Offlinequelle; WebView-Service-Worker-Verhalten muss auf Android real getestet werden.
- Browser-Cache ist keine vertrauenswürdige Datenbank; Server prüft jeden Schreibzugriff.

## CORS, Cookie, Token

- `m.wetslip.net`, eine Android-AppAsset-Origin und `api.wetslip.net` sind verschiedene Origins. CORS explizit einschränken und Origins niemals dynamisch ungeprüft reflektieren.
- Auth-Strategie erst nach Spike entscheiden: Für mobile Web-Session und lokale WebView muss ein sauberes Cookie-/CSRF- bzw. Bearer-Token-Modell entworfen werden. Bei nativer Tokenhaltung Bridge ausschließlich über allowlisted Origins/Operations. Keine Tokens in URL, Logs, lokalen Webdateien oder Git.
- CSP, Navigation-Allowlist, HTTPS-Zertifikatsprüfung, sorgfältige Datei-Upload-Verarbeitung.

## Native Funktionen

- Flutter/Android: FCM (GMS) und optional HMS-Push; Google-freie Systeme erfordern eigenen validierten Fallback.
- Android-Lockscreen-Inhalte standardmäßig geheim, optional pro Benutzer.
- Kamera/Dateizugriff nur über genehmigte native Schnittstellen bzw. Web-Fileselector, ausschließlich nach Nutzeraktion.

## Notwendige Abnahmetests

1. Desktop / Smartphone-Browser und WebView zeigen gleiche Komponenten und Produktbildpositionierung.
2. App startet im Flugmodus; Browser-Seite erst nach erfolgreich installiertem Cache offline.
3. API offline zeigt *zuletzt synchronisiert* und verhindert Bestellanfragen.
4. Abgelaufene Tokens und Logout werden sauber behandelt; private Ressourcen werden nicht im SW-Cache gefunden.
5. App-Neustart, OS-Prozessende, langsames WLAN, Funkloch, Hard Refresh, Service-Worker-Update und Android-Zurück-Taste getestet.
6. Keine Datenlecks per Android-Benachrichtigung bei geschütztem Sperrbildschirm.