[Feature Request]: Introduce support for multiple classrooms (GSoC'24 4.2) #5344
Assignees
Labels
enhancement
End user-perceivable enhancements.
Comments
|
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-2-multiple-classrooms-support. |
|
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). Please note that there are some small changes to the requirements to better align with the PRD for the feature (as some key UX confusions were cleared up that influenced the original technical design). |
Milestone 1✅ PR 1.1 - #5410Introduce a new feature flag for the multiple classrooms feature.
⬜ PR 1.2 - #5418Update the model & domain layer to support the definition of classrooms, and specify a classroom per-topic.
⬜ PR 1.3 - #5419Introduce
⬜ PR 1.4Introduce a new activity & related fragments/views/tests for a new classroom list page.
Milestone 2⬜ PR 2.1Update 'recently played' topic cards to include classroom information and update tests.
⬜ PR 2.2Implement new recommendations logic & UI support for the classroom selection and add tests.
⬜ PR 2.3Ensure the existing event logs are captured in the new screen and related tests in preparation for removal & implement new event log.
⬜ Task 2.4Test, iterate, and work with the tech lead to finalize and launch the feature.
⬜ PR 2.5Audit home activity/fragment & recommendation tests to ensure the new utilities cover the same behaviors. Remove the old home activity/fragment.
|
6 tasks
BenHenning
added a commit
that referenced
this issue
May 29, 2024
<!-- READ ME FIRST: Please fill in the explanation section below and check off every point from the Essential Checklist! --> ## Explanation <!-- - Explain what your PR does. If this PR fixes an existing bug, please include - "Fixes #bugnum:" in the explanation so that GitHub can auto-close the issue - when this PR is merged. --> Fixes part of #5344 This PR introduces a feature flag `ENABLE_MULTIPLE_CLASSROOMS` which will be used to gate the new multiple classrooms screens. ## Essential Checklist <!-- Please tick the relevant boxes by putting an "x" in them. --> - [x] The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".) - [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation. - [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide). - [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)). - [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop". - [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)). ## For UI-specific PRs only <!-- Delete these section if this PR does not include UI-related changes. --> If your PR includes UI-related changes, then: - Add screenshots for portrait/landscape for both a tablet & phone of the before & after UI changes - For the screenshots above, include both English and pseudo-localized (RTL) screenshots (see [RTL guide](https://github.com/oppia/oppia-android/wiki/RTL-Guidelines)) - Add a video showing the full UX flow with a screen reader enabled (see [accessibility guide](https://github.com/oppia/oppia-android/wiki/Accessibility-A11y-Guide)) - For PRs introducing new UI elements or color changes, both light and dark mode screenshots must be included - Add a screenshot demonstrating that you ran affected Espresso tests locally & that they're passing Co-authored-by: Ben Henning <bhenning@google.com>
BenHenning
added a commit
that referenced
this issue
May 29, 2024
… for (multiple) classrooms & topic dependencies, and prepare for #4885 (#5398) ## Explanation Fixes #1547 Fixes part of #169 Fixes part of #5344 Fixes part of #5365 Fixes part of #5411 The main purpose of this PR is to introduce support for multiple classrooms in the data layer of the app (with minimal domain integration to avoid the change extending beyond the lesson structures). However, the PR is also doing a few more things including preparing the Android codebase for introducing an asset download script (#4885) and other peripheral cleanups of code (rather than updating it) that was noticed along the way. ### Preparing for multiple classrooms This addresses part of #5365. #5344 is introducing support for multiple classrooms in the app. To help prepare for those changes, this PR introduces the necessary data structure and domain loading changes to load a new proto structure: ```proto message ClassroomList { repeated ClassroomRecord classrooms = 1; } message ClassroomRecord { string id = 1; map<string, TranslationMapping> written_translations = 2; SubtitledHtml translatable_title = 3; LessonThumbnail classroom_thumbnail = 4; map<string, TopicIdList> topic_prerequisites = 5; message TopicIdList { repeated string topic_ids = 1; } } ``` Rather than just a flat topic list. Some important details to note: - The recommended topics structure has been updated to use this new ``topic_prerequisites`` value being loaded from classrooms. This will also extend to production assets since the asset download script from #4885 is also being updated to include support for this multiple classrooms structure to address the remainder of #5365. - To minimize domain changes, the new loading code assumes only **one** classroom is present. TODOs have been added on #5344 to extend this to support multiple classrooms. - Current loading code (including for JSON) is ignoring all but: ``classrooms``, ``id``, and ``topic_prerequisites`` (including ``topic_ids``) from the protos above. These other fields are expected to have supported added as part of #5344. - There were some color simplifications made in ``TopicListController``. These largely shouldn't have a major impact outside of developer assets. These changes were made to ensure non-specificity to the previous lesson classroom. In general, all of this should eventually be removed in favor of loading colors from lesson assets, but that will need to wait until the JSON pipeline is completely removed. ### Asset priming removal This addresses part of #169. ``PrimeTopicAssetsController`` and its implementation were responsible for hackily pre-loading all lesson images and audio to be on-device to enable offline support. This was the first attempt at offline support early in the app's development, but it had a few significant drawbacks: - It required preloading everything upon first app open. Since it can take a while for loading to occur, some robustness needed to be built in for pausing, cancelling, and resuming. I'm not certain if these were even 100% handled in the current implementation. - It doesn't perform strong compatibility checks until you're in the app which means lesson incompatibilities would just cause the app to get stuck rather than addressing it during lesson import time (e.g. via an asset downloader script). - It required very significant workarounds to existing loading pipelines that aren't ideal to keep in the codebase long-term (code smell). - There's no guarantee the user even has enough disk space to download all the needed assets (particularly audio), or if they'll have sufficient internet connectivity & bandwidth to perform those downloads upon first app open. This approach was abandoned after the earliest alpha releases for an asset download script (which is now being migrated over to this codebase per #5411. This removal unfortunately required removing a module that was referenced in a lot of tests throughout the codebase. While the removal itself was fairly simple, it does affect a lot of files. Other areas changed (but unaffected by tests since these flows didn't have automated tests): - ``SplashActivityPresenter`` for enabling the downloader to start and block the UI using a dialog box while the downloading occurred. - ``AudioPlayerController` for removing the special loading logic for primed audio files (the app now no longer supports loading audio files from disk as we don't yet have a good long-term solution for offline-available audio files due to their significant size). - ``GlideImageLoader`` for removing support for loading locally cached images (only through this flow; the flow we use for the asset download script uses a different annotation and is still supported). As alluded to above, two annotations were removed as part of this cleanup: - ``CacheAssetsLocally``: a boolean indicating whether the prime download flow should be enabled. - ``TopicListToCache``: this specified the list of topics to pre-download if the flow was enabled. ### GAE structure cleanup & preparing for asset script Preparing for #4885 included a few other changes, some of which were nice-to-have: - Introducing support for incorporating the protos from https://github.com/oppia/oppia-proto-api (specifically oppia/oppia-proto-api#1 since they are still a work-in-progress). - Adding ``java_proto`` versions for many of the app's proto structures (since the download script runs in the JVM and doesn't use the javalite proto environment). - Removed all of the unused GAE services and models (addressing #1547 by essentially making it obsolete), plus their mocks. These were never hooked up, and they're never going to be: the long-term plan for the codebase is to use new proto endpoints that will be added to Oppia web. These Retrofit endpoints have actually been rebuilt and repurposed to be used in the asset download script as a medium-term stop-gap until the permanent proto endpoints can be added to Oppia web. - ``RemoteAuthNetworkInterceptorTest`` was updated to use a different example service since ``TopicService`` has been removed. The services for platform parameters and user feedback are being kept. - Some test file & KDoc exemptions have been removed since their corresponding files have been deleted. Note that the new Java proto targets & oppia-proto-api targets aren't being used yet, but they will be in future PRs. This just provides the basis of support for the asset download script while also helping to split up the code to review across multiple PRs. ## Essential Checklist - [x] The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".) - [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation. - [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide). - [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)). - [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop". - [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)). ## For UI-specific PRs only This is essentially only data infrastructural except for a couple of points: - Topic loading is now happening through a classrooms structure rather than a tropic ID list. Since there's only one test & one production classroom, this shouldn't actually change the UX. - An at-app-open flow for predownloading image & audio assets has been removed. This hasn't been used since the very earliest alpha releases of the app, so it won't actually affect any users. - Some colors for developer lesson and topic thumbnails were updated--see above.
This was referenced May 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The app is currently limited to only showing basic numeracy lessons, and the broader team plans to introduce lessons of other types (such as financial literacy, science, and more).
Describe the solution you'd like
Suggested Milestones
Technical hints / guidance
Top-level components needed for supporting multiple classrooms in the app
ClassroomListActivity.kt+ presenter & layout: Top-level activity that has a row of available classrooms which is displayed as a carousel to facilitate addition of future classrooms.ClassroomListFragment.kt+ presenter & layout: Top-level fragment for the available classrooms. The classrooms are displayed in a carousel(custom view as per existing patterns, see the "last played stories" carousel).ClassroomController.kt: The new controller for providing classroom context and state.TopicListController.kt: Existing controller that will be updated to no longer surfacegetTopicListsince this is now implemented inClassroomController. Existing use cases and tests will need to be migrated over toClassroomController. For the home screen, suggest defaulting to the "math" classroom so that existing functionality is maintained.FeatureFlagConstants.kt: Where the new feature flag for enabling multiple classrooms will be defined.ProfileChooserFragmentPresenter.kt: Updated to navigate the user toClassroomListActivity.ktinstead of HomeActivity when the new feature flag is enabled.homepackage will actually be completely removed.Some key technical notes
Suggested files to add/change
ClassroomController.kt:
TODO: Others will be added soon.
Describe alternatives you've considered
No response
Additional context
This is the high-level tracking issue corresponding to https://github.com/oppia/oppia/wiki/Google-Summer-of-Code-2024#42-multiple-classrooms-support.
The text was updated successfully, but these errors were encountered: