Repository navigation
feat: add per-instance theme engine - #513
Conversation
Introduces Instance and InstancesConfig: what one Open edX platform is and how it is parsed from the INSTANCES block of the bundled config. Nothing reads it yet. Required fields are NAME, API_HOST_URL and OAUTH_CLIENT_ID; a malformed entry is dropped. KEY falls back to a slug of NAME, INSTANCE_NAME is localized with an English fallback, and PLATFORM_NAME defaults to the display name. The schema matches iOS (#672).
InstanceStore holds the instance catalog and the selected instance, persists the selection by key and publishes it as a StateFlow. A single-instance catalog selects its only instance automatically. Registered in Koin as InstanceStore and InstanceProvider; nothing consumes it yet. Mirrors iOS #673.
InstanceTheme derives a palette from an instance's accent color and its optional THEME.LIGHT/THEME.DARK overrides: only the fields an instance sets change, the rest keep the compiled default, and a missing dark value falls back to the light one. Palette field names are the ones iOS uses (#675), mapped onto AppColors. OpenEdXTheme observes InstanceThemeManager, which holds the selected instance's theme. Nothing applies a theme yet, so every screen still renders the default palette.
openedx-webhooks
added
open-source-contribution
|
Thanks for the pull request, @IvanStepanok! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
| fun applyTo(base: AppColors, isDark: Boolean): AppColors { | ||
| val modeAccent = if (isDark) dark[ACCENT_COLOR] ?: light[ACCENT_COLOR] else light[ACCENT_COLOR] | ||
| var colors = (modeAccent ?: accentColorHex)?.toColorOrNull()?.let(base::withAccent) ?: base | ||
| light.forEach { (field, lightHex) -> |
There was a problem hiding this comment.
I have a concern here, I think any dark key only with no light key will be ignored. @IvanStepanok please check before merge
There was a problem hiding this comment.
Good catch, you're right. applyTo only walked the light keys, so a field set only under DARK was dropped.
Fixed in 587193f. It now walks both maps: dark mode uses the dark value, else the light one; light mode uses only the light value, so a dark-only field leaves light mode on the default. There's a unit test for it now.
Screenshot below: Verawood South with background, text_primary and the text input colors set only under DARK. Dark mode before and after the fix, then light mode after the fix, which stays on the default palette.
Could you take another look?
applyTo walked only the light keys, so a field present in the dark map alone was dropped. It now walks both: dark mode uses the dark value, else the light one; light mode uses only the light value, so a dark-only field leaves light mode on the compiled default.
github-project-automation
Bot
moved this from Ready for Review
to Done
in Contributions
Base: #512
Summary
Adds the theme engine. Port of openedx-app-ios#675 (forwarded to
developin #684). Given an instance's accent color and its optionalTHEME.LIGHT/THEME.DARKoverrides,InstanceThemederives the palette: only the fields an instance sets change, everything else keeps the compiled default, and a field missing fromDARKuses itsLIGHTvalue.Design notes
InstanceThemetakes primitives, not theInstancemodel, so the theme layer doesn't depend on how instances are configured.accent_color,text_primary,card_view_background, ...), mapped onto Android'sAppColors, so one catalog can brand both apps. The accent drives every color the default palette derives fromprimary. Unknown names and invalid hex values are ignored.OpenEdXThemeobservesInstanceThemeManager, so applying a theme restyles every Compose screen. Unlike iOS, where the final app applies only the accent color, the whole derived palette is applied.Not included in this PR
Testing
InstanceThemeTest(8 cases: derivation, partial overrides, per-mode accent, dark fallback, light/dark independence, ignored input, hex parsing, manager state)./gradlew detektAll testProdDebugUnitTest :app:assembleProdDebugNote
This is the 3rd pull request of the multi-instance stack.