[Feature Request]: Introduce platform parameter dashboard & improved testing support

[BenHenning]

Is your feature request related to a problem? Please describe.

There's no easy way for developers or testers to tweak current features enabled (or platform parameter configurations) in the app. Additionally, overriding platform parameters and feature flags in tests is cumbersome.

Describe the solution you'd like

Suggested Milestones:

• Milestone 1: Introduce improved testing support for platform parameters.
  • Deliverable 1: Introduce new annotations for overriding feature flags, platform parameters, and defaulting each back to normal, all targeted for test classes and methods.
  • Deliverable 2: Update OppiaTestRule to properly arrange the platform parameters and feature flags for each overridden value as indicated by the class-level and method-level annotations.
  • Deliverable 3: Update OppiaTestRule to fail if it's not the first rule run for a test, and update any tests that fail because of this.
  • Deliverable 4: Add a regex check ensuring that OppiaTestRule is always present in a test file, and update all tests that are missing the rule.
  • Deliverable 5: Migrate all old TestPlatformParameterModule usage over to the new annotations and remove the module.
• Milestone 2: Introduce UI for overriding platform parameters and feature flags.
  • Deliverable 1: Refactor the domain logic for platform parameters and feature flags to facilitate value updating using compile-time module configuration (i.e. production implementations should make it impossible to override platform parameters).
  • Deliverable 2: Introduce a new platform parameter to gate the override UI feature.
  • Deliverable 3: Introduce a new UI that distinctly lists:
    • Platform parameters and features (each should be distinctly indicated).
    • Both parameters & features show, for each:
      • Their name.
      • Their local default value.
      • Their remote value (if any).
      • Their current value.
      • Their sync status, that is one of: unspecified, using local value, using remote value, using override value.
    • Parameters show the values of the parameter based on type. Feature flags show based on enabled/disabled state (rather than true/false boolean values).
  • Deliverable 4: Update the UI to include support for overriding values.
    • Platform parameters provide true/false switches for boolean values, and text input for integers & strings.
    • Feature flags provide enable/disable switches.
    • Both provide a button for resetting the override (only if it’s set).
  • Deliverable 5: Update the UI to include a status indicator for whether the app needs to be restarted in order for the override to take effect, and a button to force restart the app (i.e. by crashing it and letting the user reopen it).
  • Deliverable 6: Test, iterate, and finalize (i.e. release) the new UI to developers.
  • Deliverable 7: Introduce a new wiki page demonstrating the UI and explaining how and when to use it. Add an interactive link to this page in the new UI itself.

Technical hints / guidance

Top-level components needed for introducing a platform parameter dashboard & improving testability

• PlatformParameterDashboardActivity.kt + presenter & layout: Activity for the new dashboard UI.
• PlatformParameterDashboardFragment.kt + presenter & layout: Fragment for the new dashboard UI.
• PlatformParameterDashboardController.kt: Controller for providing list & override support for parameters and flags.
• New view models & layouts for distinctly displaying platform parameters and feature flags.
  • Note that feature flags should show "enabled/disabled" instead of "true/false", and have a "enable/disable" override.
  • Platform parameters should have custom override fields for their possible types: boolean, integer, string.
• platform_parameter.proto: To support local overriding and additional context needed for dashboard display.
• TODO: files needed for refactoring platform parameter syncing to allow overrides.
• EnableFeatureFlag.kt: A repeatable annotation that allows overriding a feature flag to be on in tests.
• DisableFeatureFlag.kt: A repeatable annotation that allows overriding a feature flag to be off in tests.
• ResetFeatureFlagToDefault.kt: A method-only repeatable annotation that forces the specified feature flag back to its default state.
• OverrideBoolParameter.kt: A repeatable annotation that specifies overriding specific boolean-based platform parameters.
• OverrideIntParameter.kt: A repeatable annotation that specifies overriding specific int-based platform parameters.
• OverrideStringParameter.kt: A repeatable annotation that specifies overriding specific string-based platform parameters.
• ResetParameterToDefault.kt: A method-only repeatable annotation that forces the specified parameter back to its default state.
• OppiaTestRule.kt: Updated to ensure that it's the first rule run. Beyond that, also updated to ensure corresponding override annotations are correctly set/unset when running tests. Also, performs some basic validity checking to ensure different combinations of overrides & reset annotations are sensical.
• File content textproto + regex check test to ensure that all tests use OppiaTestRule.
• TestPlatformParameterModule.kt: Removed as part of the migration to the new system.

Some key technical notes

• All new components require new corresponding test files. All updated components will need their tests updated based on the changes to those components.
• If it's simpler, consider introducing a separate activity/fragment for modifying platform parameters & feature flags. It's assumed that the UI can just use an expand/collapse state for this, instead, to reduce UI complexity.
• The new activities & fragments aren't explicitly spec'd out since they are mostly boilerplate. Existing classes should be analyzed for a reference on spec'ing these out in the proposal.

Suggested files to add/change

TODO: Will be added soon.

Describe alternatives you've considered

No response

Additional context

Note that this project includes work that relate to the following issues: #4302 and #4303.

[BenHenning]

NB: This issue is locked to ensure that it only contains updates for requirements. If you have questions regarding this project, please use its corresponding discussion category: https://github.com/oppia/oppia-android/discussions/categories/gsoc-q-a-4-3-platform-parameter-improvements.

[BenHenning]

NB: The main issue comment has been updated to include the technical details directly rather than a link to a Gist (so that we can easily change this if needed). None of the technical requirements have actually changed.

[BenHenning]

Please note that this project is no longer being offered as a Google Summer of Code 2024 project for Oppia Android since we can't be sure that we'll have a mentor for it.

Existing proposals that have been submitted for feedback will still be reviewed, and the corresponding authors will be met with to discuss options.