Skip to content

entscheidungen

Jump to bottom
Actionbot edited this page Oct 7, 2026 · 19 revisions

Architektur: Entscheidungen

Zweck

Kurze Zusammenfassung technischer Entscheidungen, für die es eventuell keine eigene ADR gibt.

Entscheidungen

  • Gemeinsamer SEV-Restweg vom 07.10.2026: Unterschiedlich lange historische Anfahrtswege dürfen auf streng belegtem gleichem geordnetem Restweg eine gemeinsame GPS-Prognose liefern, sofern alle plausiblen Kandidaten eigene frische Bewegung belegen und die späteste ETA höchstens 60 Sekunden von den übrigen Kandidaten abweicht. Relative Querabstände trennen räumlich nicht plausible Alternativen; eine solche Neubewertung gilt auch für frühere Bindungen. Die Regel beweist weder den historischen Weg noch einen offiziellen SEV-Fahrweg und erhält GPS-, Sprung-, Ereignis- und Ablaufgrenzen. Details: ADR gemeinsamer SEV-Restweg.

  • SEV-Verfügbarkeit vom 07.10.2026: Eine eindeutig am veröffentlichten Punkt belegte zusätzliche Richtungsfrist sperrt keine anderen gültigen Fahrtrichtungen. Unbekannte allgemeine Beschränkungen bleiben konservativ. Kurzzeitige Straßenabruf-Fehler erhalten einen kürzeren Cache als unbrauchbare Geometrien; providerseitige Wartefristen begrenzen den gesamten Prozess. Die Anzeige unterscheidet fehlende bestätigte Ersatzhaltpunkte von fehlender Straßengeometrie. Details: SEV-Haltestellen, GPS-Zeiten und Externe Schnittstellen.

  • Aktive Fahrt und Ereignisse vom 07.10.2026: Bestätigte Statusrevision begrenzt die aktive Route und automatische Zielaktionen; physische GPS-Abfahrt bleibt von der ETA-Zulässigkeit getrennt. Ladebesitzer, Followabsicht und sichtbare System-Zurück-Grenzen sind in der ADR aktive Fahrt und Beobachtungen begründet.

  • Nachreview-Korrekturen vom 06.10.2026: Fachzustand und Composition-Beobachtung bleiben getrennt; Schreibaufträge werden je Credential/Status geordnet, MarkAll benötigt einen neuen Serversnapshot und Android-Versionen erhalten dauerhafte Create-only-Claims. Begründung und Grenzen stehen in der ADR Nachreview-Korrekturen.

  • Befundkorrekturen vom 06.10.2026: Monotone Standortbelege, plausible Bewegung vor physischen Übergängen, reaktive begrenzte Laufzeitwiederaufnahme, Editor-Anfangsabsicht, Mutationsepochen sowie unveränderliche neue Releases werden in der ADR GPS-, Mutations- und Releasezustände zusammenhängend begründet.

  • Sitzungsgrenzen im Main-Audit vom 06.10.2026: Ein validierter manueller Login wird atomar gespeichert, Auth-/Check-in-Schreiboperationen vergleichen Server, Token und Revisionskennung in derselben DataStore-Transaktion. Feature-ViewModels und Navigation gehören zu dieser Revision, damit verspätete Antworten oder erneut gleiche Zugangsdaten nach Logout keinen alten Kontozustand übernehmen. Der Room-Feedcache verwendet getrennte Server-/Token-Digest-Partitionen und einen zusammengesetzten Primärschlüssel; temporäre Fehler erlauben ausschließlich den passenden Seite-1-Rückfall. Details: Auth, Feed und Migrationen.

  • Strenge GPS-/SEV-Zuordnung im Main-Audit vom 06.10.2026: GPS-Ereignisse verlangen das vollständige nullable Planpaar, auch wenn ein Marker hinzugefügt oder entfernt wird. SEV-Anfragen benötigen ein eindeutiges geordnetes Check-in-Fenster; breite Maßnahmenintervalle überdecken keine zusätzlichen unklaren Einschränkungen, und ein abgelaufener erster Richtungsort darf nicht zur späteren Gegenrichtung führen. Die Qualitäts-/Gültigkeitsgrenzen bleiben bestehen. Details: GPS-Zeiten und SEV-Ersatzhaltestellen.

  • Android- und Release-Absicherung im Main-Audit vom 06.10.2026: Ein systemseitiger Foreground-Timeout räumt die aktive Verarbeitung synchron auf, erhält jedoch ID und Cache für sichtbaren Wiederanlauf. Das derzeitige Target 34 aktiviert das reguläre Android-15-dataSync-Budget noch nicht. Der Widget-Receiver ist nicht exportiert; die CI prüft zusätzlich vollständiges Debug-Lint, und der manuelle Release validiert Eingaben und führt Tests vor Build/Signierung aus. Dies ersetzt keine Geräte- oder Release-Signierungsprüfung. Details: TripTracking, Widget, Build und Tests.

  • Jetpack Compose als UI Framework: Gewählt für moderne, deklarative UI-Entwicklung.

  • Coroutines & StateFlow: Gewählt für asynchrone Aufgaben und reaktives State Management (statt RxJava oder LiveData).

  • Retrofit & Gson: Gewählt für die Anbindung an die Träwelling JSON-REST-API, wobei auf @SerializedName zur strikten Mappung geachtet wird.

  • Room Database: Gewählt für lokales Caching und Offline-Fähigkeit (StatusDao).

  • Globaler NavHost: Core Tabs (Feed, Check-in, Meldungen, Profil) sind innerhalb eines HorizontalPager verpackt für seitliches Swipen, während tiefere Navigation als unabhängige Routen konzipiert ist.

  • App Rename: Am 28.04.2026 wurde die App von "Träwelling" bzw. "Träwelling Android" zu "Routely" umbenannt. Die zugrunde liegende Plattform und API bleiben weiterhin unter dem Namen "Träwelling" bestehen. Dies dient einer klareren Unterscheidung zwischen dem Client und dem Backend. Für weitere Details, siehe ADR App Rename.

  • Settings & Theming: Einführung eines dedizierten Einstellungsmenüs und Auslagerung von globalen Settings aus dem ProfileScreen. Hinzufügen von Dark Mode und AMOLED Themes. Für weitere Details, siehe ADR Dark Mode & Settings.

  • Träwelling-API-Migration vom 05.10.2026: Station und Haltidentität werden getrennt behandelt. Verbraucher verwenden gemeinsame Modellhelfer für station, Plan-/Echtzeit und Stopover-UUID statt auslaufender flacher Felder. Die bestehenden Endpunkte bleiben erhalten; ungenutzte neue APIs werden nicht ohne passende App-Funktion ergänzt. Details: Träwelling-API-Kompatibilität.

  • GPS-Zeiten als lokale Anzeige vom 05.10.2026: Der bereits etablierte Besuchscursor, gerichtete Fixfolge und geplante Fahrintervalle stützen die Zeitprognose. Ein gemeinsamer Resolver wählt GPS, manuelle Zeit, parsebare API-Echtzeit und Plan. Die frühere synthetische Verspätungsvererbung entfällt; Providerdaten und Bearbeitungswerte werden nicht durch Prognosen ersetzt. Bei ungeeignetem Verlauf erfolgt konservativ der Rückfall, statt eine Restzeit aus Luftlinie und Momentangeschwindigkeit zu bilden. Details: GPS-Zeiten.

  • Stabile GPS-Zeiten und rechtzeitiger Einstiegshinweis vom 06.10.2026: Der Bewegungsbeleg nutzt ein zeitlich begrenztes Beobachtungsfenster statt einer zu kurzen festen Callbackanzahl. Bereits belegte Prognosen können bei passenden frischen Positionen durch Bremsen und geordnete Haltübergänge erhalten bleiben; ihr Ablauf wird dabei nicht verlängert. Eine Einstiegsansage bei nutzbarem GPS erfordert bestätigtes stationäres Warten innerhalb des bevorstehenden API-/manuellen Abfahrtsfensters. Uhrzeit allein bewegt oder beendet keinen GPS-Besuch. Der Fahrtdetailzustand übernimmt API-Status und passend zugeordnete Stopover-Grenzen gemeinsam, damit kein roher Zwischenzustand die GPS-Besuchsidentität kurzzeitig verliert. Details: GPS-Zeiten und TripTracking.

  • Aktuelle Vergleichszeit für GPS-Anzeige vom 06.10.2026: Fahrtdetail liest die Systemzeit bei jeder Zusammensetzung, statt neue GPS-Daten gegen die möglicherweise ältere Zeit des letzten UI-Ticks zu prüfen. Der sekündliche Ticker sorgt weiterhin für rechtzeitigen Ablauf ohne neue Standortdaten. Die Zukunftssperre, Prognosekriterien und ursprüngliche Gültigkeit bleiben erhalten; keine UI-Hysterese verdeckt tatsächlich unbrauchbare GPS-Werte. Details: StatusDetail und Tests.

  • Coil ImageLoader mit User-Agent: Am 29.06.2026 wurde die App um eine eigene Application-Klasse (TraewellingApplication) erweitert, damals über Coil 2 und ImageLoaderFactory. Die Coil-3-Migration vom 06.10.2026 verwendet SingletonImageLoader.Factory, einen ausdrücklich registrierten OkHttp-Netzwerk-Fetcher und CacheControlCacheStrategy. Der angepasste Client erhält den erforderlichen User-Agent für Profilbilder; der Wechsel verändert keine API-Zugangsdaten. Die kompatibel gewählte Coil-Version und weitere Bibliotheken stehen unter Externe Abhängigkeiten.

  • Display-aus-Begleitung vom 06.10.2026: Der sichtbare Tracking-Foreground-Service wird nur während einer bestätigten aktiven Fahrt um einen generationsgebundenen partiellen CPU-WakeLock ergänzt. Jeder Erwerb ist auf 120 Sekunden begrenzt und wird alle 60 Sekunden erneuert; alle Stop-/Destroy-Pfade geben ihn ausdrücklich frei. Es wird weder das Display gehalten noch außerhalb der aktiven Fahrt ein Dauerlock angefordert. Da gewöhnliches Doze WakeLocks und Netzwerk beschränkt, liest die Einstellungs-Card den Android-Ausnahmestatus und bietet ausschließlich nach Nutzertipp die Systemanfrage an. Eine Ausnahme wird nicht in App-Preferences simuliert und kann weitere System-/OEM-Beschränkungen oder Force-Stop nicht aufheben. Details: TripTracking, Settings und Gerätetests.

  • API Modell Updates: Am 29.06.2026 wurde das User-Datenmodell um ein mastodon-Unterobjekt (MastodonInfo) erweitert. Die Prüfung vom 05.10.2026 unterscheidet zwischen dem entfernten LightUserResource.mastodonUrl und dem weiterhin gültigen Feld im vollständigen User-/Auth-Modell; mastodon.server ist ebenfalls vorhanden.

  • Öffentliche SEV-Punkte vom 06.10.2026: Busfahrten mit RE-/RB-Linienkennung erhalten eine asynchrone Ergänzung aus bahnhof.de-Karten. Vorhandenes OkHttp/Gson liest öffentliche GeoJSON-Punkte ohne Zugangsdaten oder JavaScript-Ausführung; PDF und QR sind keine Laufzeitabhängigkeiten. Die vollständige API-Haltfolge, konkrete Besuchsidentität, Stationsnähe und Datums-/Richtungsregeln müssen einen eindeutigen aktuellen Punkt belegen. Nur die interne Tracking-Projektion wird ergänzt. Mehrdeutige oder abgelaufene Quellen behalten die API-Koordinate und erklären die Unsicherheit im Fahrtdetail. Netzwerk-/Cachegrenzen begrenzen den Abruf, Status- und Generationsprüfungen verhindern späte Fahrtübernahme. Ein physischer Koordinatenwechsel invalidiert bisherige Ankunft und GPS-Zeitbasis. Diese erste Ergänzung belegte nur Haltpunkte, keinen Straßenweg oder genaue Bus-ETA. Details: SEV-Ersatzhaltestellen.

  • Optionale SEV-Straßenprojektion vom 06.10.2026: Die Diagnose OUTSIDE_CORRIDOR auf einer RE1-Busrückfahrt zeigt die Grenze der geraden Abschnittsprojektion. Für SEV-Zeitprognosen werden deshalb getrennt validierte Straßen-Geometrien des öffentlichen FOSSGIS-OSRM-Pkw-Profils geladen, ausschließlich zwischen eindeutig belegten öffentlichen Ersatzhaltpunkten. Der Service lädt höchstens den aktuellen Ankunftsabschnitt und dessen Folgeabschnitt, am Einstieg die ersten zwei geeigneten Abschnitte, ohne Blockierung der API-/GPS-Verarbeitung; Generation und Besuchs-/Koordinatenbindung verhindern späte Übernahme. Die Geometrie bleibt im RAM, Request-Starts sind begrenzt, GPS-Fixes werden nicht übertragen. Das Modell ist keine offizielle SEV-Route und seine Fahrtdauer keine Bus-ETA. Fehlende, unpassende oder mehrdeutige Wege fallen auf vorhandene Zeitquellen zurück; API-Polylines ohne Herkunftsbeleg und Bahnhofsluftlinie werden nicht als SEV-Weg eingesetzt. Ein Formwechsel erhält bestätigte tatsächliche Ereignisse, setzt aber Bewegung und Prognose zurück. Standortqualität, Gültigkeit und Stationsengine werden nicht gelockert. Details: GPS-Zeiten und Externe Schnittstellen.

  • Haltbasierte Wiederverankerung nach Tunnel vom 06.10.2026: Ein geschützter GPS-Cursor darf bei Signalverlust nicht allein durch die Uhr weiterrücken, muss aber nach mehreren unbemerkten Tunnelhalten an einem eindeutig belegten späteren Besuch wiederherstellbar sein. Eine getrennte frische Kandidatenfolge bestätigt nur vorwärts und prüft die ganze Route gegen nahe konkurrierende oder wiederholte Besuche. Bis zur Bestätigung bleiben Fahrplanquelle und alte Ansagen zurückgestellt; danach werden Ankunfts-/Aufenthaltsbelege auf neuer Basis gesammelt. Übersprungene Halte erhalten keine synthetischen Istzeiten oder Ansagen, das Ziel benötigt weiterhin eigene physische Bestätigung. Die neutrale Abschnittsdiagnose behauptet keinen bekannten offiziellen Fahrweg. Diese Haltkorrektur fügte selbst keine Schienen-Geometrie hinzu; die nachfolgende native Formquelle ist eine getrennte Entscheidung. Details: TripTracking, GPS-Zeiten und Tests.

  • Native Bahn-/Tram-Streckenverläufe vom 06.10.2026: Geeignete Formen des nativen Träwelling-Statusendpunkts werden lokal an geordnete Check-in-Besuche gebunden und gemeinsam für Zeitprognose sowie gerichtete Fortschrittshilfen verwendet. Stationssehnen, mehrdeutige Schleifen und unbelegte Teilabschnitte bleiben konservativ ausgeschlossen; physische Ankunft und Tunnelwiederverankerung behalten getrennte Belege. Der sessiongebundene RAM-Cache und die Anzeige nennen keine amtliche Gleisgarantie. Die ausführliche Abwägung steht in der ADR Native Streckenverläufe.

  • Gezielte Bibliotheksaktualisierung vom 06.10.2026: SDK 36, Target 34 und JDK 17 bleiben erhalten. Gewählte stabile Pins passen zu AGP 8.13.2, Gradle 8.14.5 und Kotlin 2.3.21; der Kotlin-Compose-Plugin ersetzt die bisherige Compiler-Extension, KSP und Coil werden passend migriert. Neuere Pins mit API-37-/AGP-9.1- oder unpassenden Kotlin-/R8-Anforderungen bleiben zurückgestellt. Versionsprüfung und ausgeführter Buildnachweis werden getrennt dokumentiert unter Build, Externe Abhängigkeiten und Tests.

Verwandte Seiten

Clone this wiki locally