App theme preference (Light / Dark / System) has no effect #23

New Issue

2026-06-28T13:41:08Z

admin commented

2026-06-28 13:41:08 +00:00

Bug

The Settings screen exposes a "Theme" preference (Light / Dark / System) backed by AppPreference.appTheme() (domain/preference/AppPreference.kt:15). Selecting a value persists it, but the change has no effect on the app — the UI always follows the system theme.

Root cause

AppTheme in app/src/main/java/dev/achmad/ledgerr/ui/theme/Theme.kt:20 only accepts darkTheme: Boolean = isSystemInDarkTheme(). Nothing reads AppPreference.appTheme() and passes the resolved value in, so the preference is effectively dead. Search confirms there are no other call sites for appTheme() or AppTheme other than the default parameter.

Expected behavior

Choosing Light in Settings forces light mode regardless of system setting; Dark forces dark; System follows the device. The change should take effect immediately (no app restart) and survive process death.

Acceptance criteria

Toggling the theme preference in SettingsScreen re-themes the app live.
After force-killing and relaunching, the last-selected theme is restored.
SYSTEM follows isSystemInDarkTheme() (current device setting).
Status bar / nav bar colors stay in sync with the active theme.

Suggested approach (not prescriptive)

Add a State<AppTheme> / Flow<AppTheme> accessor on AppPreference (or expose it from a ThemeViewModel).
Have AppTheme resolve the effective darkTheme from the current preference, falling back to isSystemInDarkTheme() when the value is SYSTEM.
The current call site of AppTheme is the single entry point — wire it there.

**Bug** The Settings screen exposes a "Theme" preference (Light / Dark / System) backed by `AppPreference.appTheme()` (`domain/preference/AppPreference.kt:15`). Selecting a value persists it, but the change has **no effect on the app** — the UI always follows the system theme. **Root cause** `AppTheme` in `app/src/main/java/dev/achmad/ledgerr/ui/theme/Theme.kt:20` only accepts `darkTheme: Boolean = isSystemInDarkTheme()`. Nothing reads `AppPreference.appTheme()` and passes the resolved value in, so the preference is effectively dead. Search confirms there are no other call sites for `appTheme()` or `AppTheme` other than the default parameter. **Expected behavior** Choosing **Light** in Settings forces light mode regardless of system setting; **Dark** forces dark; **System** follows the device. The change should take effect immediately (no app restart) and survive process death. **Acceptance criteria** - Toggling the theme preference in `SettingsScreen` re-themes the app live. - After force-killing and relaunching, the last-selected theme is restored. - `SYSTEM` follows `isSystemInDarkTheme()` (current device setting). - Status bar / nav bar colors stay in sync with the active theme. **Suggested approach (not prescriptive)** - Add a `State<AppTheme>` / `Flow<AppTheme>` accessor on `AppPreference` (or expose it from a `ThemeViewModel`). - Have `AppTheme` resolve the effective `darkTheme` from the current preference, falling back to `isSystemInDarkTheme()` when the value is `SYSTEM`. - The current call site of `AppTheme` is the single entry point — wire it there.

admin referenced this issue from a commit

2026-06-28 14:31:07 +00:00

fix(#23): wire AppTheme preference in MainActivity

admin referenced a pull request that will close this issue

2026-06-28 14:31:13 +00:00

fix(#23,#24,#27): theme preference wiring, dd MMM yyyy dates, calendar icon in DateField #38

admin closed this issue

2026-06-28 14:32:57 +00:00

Sign in to join this conversation.