Fixes#633
On Android 12 and above, the splash screen was ignoring the user’s saved theme preference and instead defaulting to the system theme. This happened because the splash screen is rendered before Application.onCreate() finishes executing. At that point, the system’s UiModeManager hadn't been updated with the user's preferred theme, so it showed the wrong one.
Changes:
- Introduced initializeNightModeFromPreferences() in UiExtensions.kt. This method forces the correct theme mode synchronously during Application.onCreate(), ensuring it’s in place before the splash screen ever appears.
- Added observeNightModePreferences() to actively listen for changes to the theme setting. This keeps UiModeManager updated in real time so future cold starts use the right theme immediately.
- On Android 12+ (API 31+), now using UiModeManager.setApplicationNightMode() to set the theme properly.
- For older versions, the implementation falls back to AppCompatDelegate.setDefaultNightMode() for compatibility.
- Added a toDarkThemeConfig() extension function to translate the DataStore proto into the theme model used by the UI.
- Included the AppCompat dependency in the app module to support these changes.
Why the Observer Matters? Without it, any theme change made by the user wouldn't notify UiModeManager right away. That would mean the next time the app is launched cold, the splash screen would still use whatever theme was cached before—not the one the user just selected. This fix prevents that.
Testing:
- Confirmed that the splash screen reflects the saved theme preference, even on a fresh app start.
- Checked all theme configurations: Light, Dark, and Follow System.
- Verified behavior on both Android 12+ and Android 11 devices to ensure backward compatibility.
Updates the modularization documentation with the following changes:
- Adds an important note about dependency graphs in module READMEs.
- Renames several section headers for clarity (e.g., "Types of modules" to "Module types").
- Moves the section on dependency graphs to be after the examples table.
The `<code>` HTML tag is used to properly render code snippets within the `ModularizationLearningJourney.md` documentation file. This improves the readability of the examples provided in the table.
Expands on the role of feature `:api` modules in the modularization learning journey documentation.
Clarifies that `:api` modules expose navigation keys and functions for inter-feature navigation. Also adds a new `impl` row for the implementation details.
Removes the general theory of modularization and links to the official guidance instead.
Clarifies the structure of feature modules, detailing the split into `api` and `impl` submodules and their dependency rules.
Also includes minor heading and formatting updates.
Add `rememberViewModelStoreNavEntryDecorator` to the list of decorators for `NavEntry` instances. This enables support for `ViewModel` instances within the navigation component.
Updated string resource identifiers in the `SettingsDialogTest` to follow the `feature_settings_impl_` prefix convention. This aligns the test resources with the recent module renaming.
The string resource identifiers for settings have been updated in the navigation tests. The `feature_settings` prefix has been changed to `feature_settings_impl` to reflect changes in the settings feature module.
The `feature:settings:api` module has been renamed to `feature:settings:impl` to better reflect its role as an implementation module.
This change includes:
* Updating module paths and namespaces.
* Moving all related files, including source code, resources, and tests, to the new `impl` directory.
* Updating dependencies and project configurations in Gradle scripts and README files to point to the new module path.
* Renaming string resources to include the `_impl` suffix for clarity.
* Updating the AndroidX Lifecycle dependency to version 2.10.0.
The `NiaAppStateTest` is updated to align with the changes in `InterestsNavKey`, which now requires a `topicId` argument. The test now uses `InterestsNavKey(null)` to correctly represent the top-level interests destination.
Adds automatically generated dependency graphs to the README.md files for the following feature modules:
- `:feature:bookmarks:api`
- `:feature:bookmarks:impl`
- `:feature:foryou:api`
- `:feature:foryou:impl`
This commit refactors the navigation implementation by renaming all `...Route` classes to `...NavKey`. This change provides more descriptive and consistent naming for navigation keys across the codebase.
Key changes include:
* Renamed `BookmarksRoute` to `BookmarksNavKey`
* Renamed `ForYouRoute` to `ForYouNavKey`
* Renamed `InterestsRoute` to `InterestsNavKey`
* Renamed `TopicRoute` to `TopicNavKey`
* Renamed `SearchRoute` to `SearchNavKey`
* Updated all associated feature modules, tests, and UI components to use the new `NavKey` names.
* Removed obsolete test utilities and mock providers related to the old navigation setup.
* Deleted outdated dependency graph images and their corresponding `README.md` files from feature modules.
This commit refactors the navigation state management by renaming `NiaNavigatorState` to `NavigationState` to make it more generic.
Specific changes include:
- Renamed `NiaNavigatorState` to `NavigationState`.
- Renamed `NiaNavigatorProvider` to `NavigationStateProvider`.
- Updated all usages of the renamed classes, including `NiaNavigator`, `NiaBackStackViewModel`, and various tests.
- Replaced the `getEntries()` extension function with `toEntries()`.
- Added numerous TODOs to identify areas for future improvement, such as removing dependencies on `SavedStateHandle` for navigation state, simplifying event handling in ViewModels, and documenting the new navigation components.
Made NiaNavigator a stateless class only responsibly for navigating and pop (modifying backStack).
Navigation state now lives in a new class called NiaNavigatorState.
The state of this class is saved and restored by ViewModel.
everts
Don Turner
Simon Marquis
Don Turner
dturner
Clara Fok
Aurimas