Refactoring: Settings Type-Safety und Validierung #82

Closed
opened 2026-05-16 23:42:54 +00:00 by jreinemann-euris · 0 comments
jreinemann-euris commented 2026-05-16 23:42:54 +00:00 (Migrated from github.com)

Kontext

Die App speichert Settings als Key-Value-Strings in der Room-Datenbank (SettingsEntity(key, value)). Es gibt keine Type-Safety, keine Validierung und keine zentrale Definition der gültigen Keys.

Problem

  • Ein Tippfehler in einem Key (z.B. "sever_url" statt "server_url") führt zu stillem Fehlverhalten
  • Kein Compile-Time-Check auf gültige Settings-Keys
  • Werte werden als Strings gespeichert, Typkonvertierung passiert ad-hoc beim Lesen
  • Kein Default-Wert-Management – fehlende Keys müssen überall individuell behandelt werden

Akzeptanzkriterien

  • Zentrale Settings-Key-Definition (enum oder sealed class)
  • Type-safe Getter/Setter im SettingsRepository (z.B. getInt(key), getString(key))
  • Default-Werte zentral definiert
  • Bestehende Settings-Zugriffe auf die neue API migrieren
  • Compile-Time-Fehler bei ungültigen Keys
  • Alle Tests grün
## Kontext Die App speichert Settings als Key-Value-Strings in der Room-Datenbank (`SettingsEntity(key, value)`). Es gibt keine Type-Safety, keine Validierung und keine zentrale Definition der gültigen Keys. ## Problem - Ein Tippfehler in einem Key (z.B. `"sever_url"` statt `"server_url"`) führt zu stillem Fehlverhalten - Kein Compile-Time-Check auf gültige Settings-Keys - Werte werden als Strings gespeichert, Typkonvertierung passiert ad-hoc beim Lesen - Kein Default-Wert-Management – fehlende Keys müssen überall individuell behandelt werden ## Akzeptanzkriterien - [ ] Zentrale Settings-Key-Definition (enum oder sealed class) - [ ] Type-safe Getter/Setter im SettingsRepository (z.B. `getInt(key)`, `getString(key)`) - [ ] Default-Werte zentral definiert - [ ] Bestehende Settings-Zugriffe auf die neue API migrieren - [ ] Compile-Time-Fehler bei ungültigen Keys - [ ] Alle Tests grün
Sign in to join this conversation.
No description provided.