Skip to content

feat: App Launch Sequencing / InstanceAwareConfig - #519

Open
IvanStepanok wants to merge 14 commits into
openedx:developfrom
raccoongang:infra/09-app-launch-sequencing
Open

IvanStepanok wants to merge 14 commits into
openedx:developfrom
raccoongang:infra/09-app-launch-sequencing

Conversation

@IvanStepanok

Copy link
Copy Markdown
Contributor

What

Wires the instance catalog into app launch and replaces the app-level Config with an instance-aware one. Port of openedx-app-ios#682, with the launch awaiting the catalog as the final iOS behavior documented in #685. Stacked on #518.

Why

Until now nothing called InstanceConfigLoader, and every Config reader (networking, SSO, feature flags, agreements) read only the bundled app-level values: instances existed as data, but the app didn't use them.

Changes

1. Launch waits for the catalog (AppViewModel, AppActivity)

  • The splash screen stays up while InstanceConfigLoader.load() resolves the catalog (live fetch with a 10 second timeout, falling back to the cached or bundled catalog); then the selected site's theme is applied and the first screen is routed. A recreated activity gets its screens back from the fragment manager and doesn't wait.
  • InstanceStore restores the saved selection synchronously from the cached catalog (InstanceConfigLoader.baseline()), so a process restored after being killed resolves the same site before any request is made, even when that site came from the remote catalog.

2. InstanceAwareConfig (core/config/InstanceAwareConfig.kt)

  • A Config subclass layering the selected instance over the app-level config. Config reads every key through one lookup, which is now overridable, so every getter becomes instance-aware with no call-site changes.
  • For the keys an instance may override (API host, OAuth client, SSO URLs, token type, feedback email, FAQ, platform name, agreements, discovery, program, dashboard, course UI flags, SSO button title, experimental features, and the login flags iOS nests under UI_COMPONENTS), a value the instance sets wins; anything it leaves out comes from the app-level config. UI_COMPONENTS merges per field.
  • Firebase, Braze, Branch, social providers, URI_SCHEME and app-wide feature flags stay app-level.
  • Unlike iOS, where an instance's feature flags are read with defaults even when the instance doesn't set them, a key an instance omits always falls back to the app-level value.

3. DI

  • Config resolves to InstanceAwareConfig. The app-level config stays available under its own qualifier for what must not move with the selection: Retrofit's base URL (which InstanceHostInterceptor rewrites) and the check that identifies the site a single-site install belonged to.

4. Tests

  • InstanceAwareConfigTest (10 cases): no selection, instance wins, fallback when omitted, blank values, platform name default, nested login flags, per-field UI merge, app-level-only keys, values following the selection, app-level accessors that never move.
  • AppViewModelTest: routing waits for the catalog; the catalog is applied before the theme.

Deliberately out of scope

  • API_HOST_URL / OAUTH_CLIENT_ID stay required at the app level: they are the fallback while nothing is selected, and they identify the site that inherits a single-site install's data.

How to test

  • ./gradlew detektAll testProdDebugUnitTest :app:assembleProdDebug
  • Manual: a single-site build still launches straight to sign-in (emulator, API 36).

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.
InstanceConfigLoader resolves the catalog the app runs with: the last cached remote
catalog, else the bundled INSTANCES list, else nothing. A live fetch with at least one
instance replaces that baseline and becomes the cache; a failed, malformed or empty
response leaves it untouched.

The catalog is fetched from INSTANCES_CATALOG_URL with a plain OkHttp client: no app
interceptors, no credentials, a 10 second timeout. Remote snake_case keys are normalized
with the same map iOS uses (#676). Nothing calls the loader at launch yet.

Unlike iOS, the YAML build configuration stays: the Gradle build already turns it into
the bundled config.json the loader reads.
InstanceHostInterceptor re-targets requests built against the app's base URL at the
selected instance: scheme, host and port change, path and query stay. Other hosts, and
every request made with nothing selected, pass through. Each request is tagged with the
instance it was sent for.

Token refresh calls the selected instance's /oauth2/access_token with its OAuth client.
A 401 for a request sent before a site switch neither refreshes nor logs out, and tokens
returned after the learner switched are discarded. The access token is only attached to
requests for the active site's host. Mirrors iOS #677.
Preferences tied to a learner on one site (tokens, push token, user, profile, server app
config, relative dates, calendar sync state) are now stored per instance, so switching
sites can't leak one site's session into another. Device-wide settings (video quality,
Wi-Fi only downloads, review prompt, What's New) stay shared.

StorageNamespace decides where an instance's data lives. The instance whose API host and
OAuth client match the app-level configuration keeps the existing unprefixed keys, so an
upgraded single-site install stays signed in; that choice is recorded once and never
re-derived from a later catalog. Every other instance gets instance.<key>.* keys.

CorePreferences can now check or clear one instance's session without selecting it, and
token refresh saves rotated tokens for the site that issued them even if the learner
switched away mid-refresh. Mirrors iOS #678.
The refresh resolved the selected instance twice: once for the tokens and again for the
endpoint, so a switch in between could send one site's refresh token to another. The
instance is now resolved once per authenticate call and used for the tokens read, the
token endpoint and where the result is saved. The minimum interval between refreshes is
tracked per site, so refreshing one site no longer holds back another.
Each instance gets a Room database file of its own, so cached courses, offline progress,
calendar state and download records can't collide between sites, even when both use the
same course and block IDs. The legacy namespace keeps the original OpenEdX_db file, so an
upgraded single-site install keeps its data with no schema migration and no destructive
fallback.

The injected DAOs now forward every call to the selected instance's database, resolved
once per call; default @transaction methods are forwarded to the generated DAO, and flows
switch databases after a site switch.

Downloaded files go to instances/<site> under the downloads folder; the legacy namespace
keeps the existing location. The download worker carries the site that queued it and
writes each file's record to that site's database, so a download that finishes after a
switch can't land in the other site. Once its own queue is empty it moves on to the
selected site's queue. Progress and failure events reach the UI only for the selected
site. Mirrors iOS #679.
The background sync read and cleared offline progress through the selected site's
database, one call at a time, so a site switch in the middle could clear the other site's
records and submit the rest to the wrong site. It now works in the database of the site it
started on and stops before sending anything once another site is selected.
…hrough it

InstanceSessionManager separates switching sites from signing out:
- switchActiveInstance selects a site and applies its theme; nothing is torn down.
- logoutCurrentInstance cancels downloads, unregisters push when wired, clears the site's
  tokens and user, then clears the selection. Cached courses and downloaded files stay, so
  signing back in to the same site is fast.
- logout(instance) does that for the selected site and only clears the stored session of
  any other site.

Both the Settings logout and the forced logout (401, disabled account) now go through
logoutCurrentInstance instead of clearing preferences and every database table.

Because logout keeps the cache, a different learner signing in to the same site would see
the previous learner's cached courses; sign-in records who used the site last and clears
the cached course data when that changes. Mirrors iOS #681.
- Signing out of a site with nothing queued no longer cancels the download worker, which
  may be working through another site's queue; removing downloads cancels the worker only
  when one of them was the active download.
- Switching sites and signing out clear the web view session cookies, so the next web page
  fetches the selected site's cookies instead of trusting the previous site's freshness.
@openedx-webhooks openedx-webhooks added open-source-contribution PR author is not from Axim or 2U core contributor PR author is a Core Contributor (who may or may not have write access to this repo). labels Oct 19, 2026
@openedx-webhooks

Copy link
Copy Markdown

Thanks for the pull request, @IvanStepanok!

This repository is currently maintained by @openedx/openedx-mobile-maintainers.

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

  • If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
    • This process (including the steps you'll need to take) is documented here.
  • If it doesn't, simply proceed with the next step.
🔘 Provide context

To 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:

  • Dependencies

    This PR must be merged before / after / at the same time as ...

  • Blockers

    This PR is waiting for OEP-1234 to be accepted.

  • Timeline information

    This PR must be merged by XX date because ...

  • Partner information

    This is for a course on edx.org.

  • Supporting documentation
  • Relevant Open edX discussion forum threads
🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details
Where 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:

  • The size and impact of the changes that it introduces
  • The need for product review
  • Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

These operations wait on the network, and a site switch while they wait used to send the
rest of their work, and their results, to the newly selected site.

- Requests can be pinned to a site: a RequestInstance tag set by the caller (Retrofit @tag)
  makes InstanceHostInterceptor send the request to that site's host and HeadersInterceptor
  attach that site's token, whichever site is selected by then. A site no longer in the
  catalog gets no token.
- Sign-in pins its token, exchange and profile requests to the site it started on, writes
  tokens and user to that site's storage, and stops with InstanceSwitchedException, writing
  nothing, if another site was selected in the meantime.
- Sign-out pins the revoke request and then signs out only the site it started on; if the
  learner switched meanwhile, the new site keeps its selection and session. Settings no
  longer cancels every download before signing out.
- Push: the device token is device-wide again. PushRegistrations registers it with, and
  unregisters it from, one site at a time with pinned requests; signing out of any site,
  selected or not, unregisters that site first. Registration work is unique per site, and
  the token is rotated after sign-out only once no site is still signed in, since rotating
  would cut off the others. A new token is registered with every signed-in site.
@IvanStepanok
IvanStepanok force-pushed the infra/09-app-launch-sequencing branch from 300c6cc to 19f916c Compare October 19, 2026 17:53
Signing out of the selected site waits on the network to unregister push.
If the learner switched sites meanwhile, the rest of the sign-out read the
selection again: it cleared the new site's session and reset its
selection, cookies and theme.

The site is now fixed when the sign-out starts. Only its session is
cleared, and the selection, web cookies and theme are reset only while it
is still the selected site.
The launch now waits for the instance catalog before showing the first screen: the
splash screen stays up while InstanceConfigLoader resolves it (a live fetch with a 10
second timeout, falling back to the cached or bundled catalog), then the selected
instance's theme is applied and routing proceeds. InstanceStore restores a saved
selection synchronously from the cached catalog, so a process restored after death
resolves the same site before any request is made.

Config is now InstanceAwareConfig: for the keys an instance may override (API host,
OAuth client, SSO URLs, token type, feedback email, FAQ, platform name, agreements,
discovery, program, dashboard, course UI flags, SSO button title, experimental features
and the login flags), a value the instance sets wins and everything else comes from the
app-level config. Firebase, Braze, Branch, social providers, the URI scheme and app-wide
feature flags stay app-level. Every existing Config consumer becomes instance-aware with
no call-site changes.

The app-level config stays available under its own Koin qualifier for what must not
move with the selection: the Retrofit base URL that InstanceHostInterceptor rewrites,
and the legacy storage owner check. Mirrors iOS #682, with the launch now awaiting the
catalog as the final iOS behavior documented in #685.
@IvanStepanok
IvanStepanok force-pushed the infra/09-app-launch-sequencing branch from 19f916c to da8d21b Compare October 20, 2026 07:22
@mphilbrick211 mphilbrick211 moved this from Needs Triage to Ready for Review in Contributions Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core contributor PR author is a Core Contributor (who may or may not have write access to this repo). open-source-contribution PR author is not from Axim or 2U

Projects

Status: Ready for Review

Development

Successfully merging this pull request may close these issues.

3 participants