Integrate multiplatform-settings #1

New Issue

2026-02-03T22:50:35+01:00

hb commented

2026-02-03 22:50:35 +01:00

this is the lib:

implementation("com.russhwolf:multiplatform-settings-no-arg:1.3.0")

this is the lib: implementation("com.russhwolf:multiplatform-settings-no-arg:1.3.0")

hb self-assigned this 2026-02-03 22:50:55 +01:00

hb added the Kind/Enhancement label 2026-02-03 22:52:14 +01:00

hb commented

2026-02-04 00:07:36 +01:00

das könnte eine gute Alternative sein (ohne externe Abhängigkeit):

https://developer.android.com/kotlin/multiplatform/datastore

fkt. mit android, iOS, JVM -> JS?

das könnte eine gute Alternative sein (ohne externe Abhängigkeit): https://developer.android.com/kotlin/multiplatform/datastore fkt. mit android, iOS, JVM -> JS?

hb commented

2026-02-04 02:24:58 +01:00

Android DataStore ist raus, das ist kompletter Overkill.

Diese Lib ist handlicher, aber auch nicht unkompliziert im Handling:
https://github.com/russhwolf/multiplatform-settings

Die eigentliche Frage ist, was überhaupt darüber laufen soll. Für die Konfig des Programms (Server-Namen, etc.) reicht eine Properties-Datei (aus der o.g. Lib lassen sich zumindest Hinweise ziehen, wie das auf nicht-JVM-Platformen machbar wäre). Alles Andere könnte auch in der DB abgelegt werden (jedenfalls sollange die DB im gleichen Netz ist).

Oder: Config wird als .properties (o.ä.) mit ausgeliefert, "normale" User-Settings (Farben, Font-Size ...) liegen lokal in Preferences (schneller Zugriff) und nur wichtige User-Settings, die auch ein Abrauchen des Rechners überleben sollten, kommen in die DB (sicherer). Macht das Programm nicht unbedingt übersichtlicher, wäre aber sicherlich performanter, weil die allermeisten Einstellungen dann lokal gespeichert würden. Da könnte auch die Lib hilfreich sein.

Für Infos zu Preferences ist das hilfreich:
https://www.javathinking.com/blog/java-how-do-you-use-the-preference-api-where-do-these-variables-store/

Android DataStore ist raus, das ist kompletter Overkill. Diese Lib ist handlicher, aber auch nicht unkompliziert im Handling: https://github.com/russhwolf/multiplatform-settings Die eigentliche Frage ist, was überhaupt darüber laufen soll. Für die Konfig des Programms (Server-Namen, etc.) reicht eine Properties-Datei (aus der o.g. Lib lassen sich zumindest Hinweise ziehen, wie das auf nicht-JVM-Platformen machbar wäre). Alles Andere könnte auch in der DB abgelegt werden (jedenfalls sollange die DB im gleichen Netz ist). Oder: Config wird als .properties (o.ä.) mit ausgeliefert, "normale" User-Settings (Farben, Font-Size ...) liegen lokal in Preferences (schneller Zugriff) und nur wichtige User-Settings, die auch ein Abrauchen des Rechners überleben sollten, kommen in die DB (sicherer). Macht das Programm nicht unbedingt übersichtlicher, wäre aber sicherlich performanter, weil die allermeisten Einstellungen dann lokal gespeichert würden. Da könnte auch die Lib hilfreich sein. Für Infos zu Preferences ist das hilfreich: https://www.javathinking.com/blog/java-how-do-you-use-the-preference-api-where-do-these-variables-store/

hb pinned this 2026-02-04 23:49:15 +01:00

hb unpinned this 2026-02-04 23:49:34 +01:00

hb added this to the APP client project 2026-02-04 23:50:25 +01:00

hb moved this to To Do in APP client on 2026-02-04 23:50:54 +01:00

hb referenced this issue from a commit

2026-02-05 18:43:36 +01:00

settings wird so langsam (#1)

hb commented

2026-02-05 23:32:09 +01:00

Im Moment funktioniert es nur für die JVM-Platform, das reicht aber bis auf Weiteres. WASM wird implementiert, falls das ein Thema werden sollte und Android und iOS liegen sowieso in ferner Zukunft.

Implementiert als Java-Preferences für "unwichtige" User-Settings außerdem Java-Properties für Programm-Config (werden beim Start einmalig eingelesen und sind unveränderlich).

Die PKCE-JWTs landen erstmal in den Preferences, wobei das noch auszutesten ist, denn das Refresh-Token läuft nur 35 Minuten, da lohnt sich das Speichern kaum.

Im Moment funktioniert es nur für die JVM-Platform, das reicht aber bis auf Weiteres. WASM wird implementiert, falls das ein Thema werden sollte und Android und iOS liegen sowieso in ferner Zukunft. Implementiert als Java-Preferences für "unwichtige" User-Settings außerdem Java-Properties für Programm-Config (werden beim Start einmalig eingelesen und sind unveränderlich). Die PKCE-JWTs landen erstmal in den Preferences, wobei das noch auszutesten ist, denn das Refresh-Token läuft nur 35 Minuten, da lohnt sich das Speichern kaum.

hb referenced this issue from a commit

2026-02-06 16:40:50 +01:00

#1 Setings ist erledigt

hb commented

2026-02-06 16:47:15 +01:00

Die Token werden nicht in den Settings gespeichert (wegen 35 Minuten lohnet es sich nicht ein Sicherheitsrisiko einzugehen).

Ansonsten läuft das und die fehlenden Platformen kommen dran wenn's soweit ist.

Die Token werden nicht in den Settings gespeichert (wegen 35 Minuten lohnet es sich nicht ein Sicherheitsrisiko einzugehen). Ansonsten läuft das und die fehlenden Platformen kommen dran wenn's soweit ist.

hb closed this issue

2026-02-06 16:47:15 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hb/zz_app#1