In various locations, content cards will need to be displayed with rich-text. Android TextViews support rendering a subset HTML, though the default rich-text provided by the Oppia backend may need to be processed before simply being passed to the TextView. See the web rich-text component for specifics.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• ContentCard (Left side)

• Learner Answer (Right side)

• Final touch up with padding, margin, animations and Accessibility Scanner test

This is tracking implementing the fully polished UI version of the continue interaction.

See the web frontend for details on how the continue button interaction works.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• Continue Button

• Next Button and Previous Button

• Submit inactive/active Button

• Learn again Button

• Final touch up with padding, margin, animations and Accessibility Scanner test

Currently, Oppia relies on JSON blobs when sending content to the web frontend. These JSON structures contain various data representing backend data, and also web-specific items (e.g. category colors or names of icon resources). Although this works nicely for the web, two key changes will help majorly simplify app development and establish long-term precedence for clean backend API design:

1. Abstract away web-specific properties. Properties like category tile colors and icons should be chosen by the frontend, not the backend. The backend may want to make sure the category itself is sent over in the payload, but how it should look should be chosen by the client. Other properties like this should also be converted to be non-web-specific.

2. Use protobuf instead of JSON. JSON is not automatically backward compatible like Protobuf, so changes to the data structures requires forking the API to a new version rather than the backend providing suitable defaults for new/old fields to ensure the clients work correctly. This is especially important for the long-term maintenance of the app.

This requires filing and tracking corresponding work items in https://github.com/oppia/oppia.

There needs to be a page where the user can view all languages that the Oppia app supports and select which on it should be displayed in. This should be a per-profile setting that sets the language for the app, but not for the whole system. It should be easy to navigate to this screen. It should also be possible for the user to change the language only for the profile selection page temporarily as they log in. See the PRD for specifics.

A general system should exist to track the user's activity/inactivity in the app. Callers into this system are responsible for determining what is a user action. This system will have a timer that will keep track of when the last user action occurred. If that was longer than a fixed time ago (30 minutes), then the user should automatically be logged out.

The profile selection page may require a lot of custom UI that's not broadly available in the Google material design component libraries. See the PRD for specifics.

Work Items:

Auth Screen

• Auth Screen: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/a841330e-efe5-4bdb-acdd-4d6e52a59571/PC-MP-Admin-Authorization-Empty-
  (@rt4914 )
• Submit Button active/inactive
• Submit button should be visible above keyboard
• Submit button in keyboard should submit the pin directly.
• Accessibility test

Add Profile Screen

• Add Profile Screen: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/bdbfc057-f662-4ce1-b142-7e842ed65afb/PC-MP-Add-Profile-Empty- (@nikitamarysolomanpvt waiting for design)
• Create Button active/inactive
• Create button should be visible above keyboard
• Create button in keyboard should submit the pin directly.
• Accessibility test

Profile Chooser

• Profile Chooser Screen: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/ad1de6e2-1d5d-4ac3-888c-58d036c7ede4/PC-MP-Profile-Chooser- (@veena14cs )
• Accessibility test

Sqlite is the database storage option of choice, and given the large variety of data being stored in the Oppia app this is an ideal database system to use. However, the relational and join/query-based nature of the RDBMS should be abstracted into a simple RESTful interface that only exposes the shared data models used in higher layers of the app (see section 4.5 of the app architecture design document). This abstraction needs to force all operations to be performed off the main thread, with multithreading enabled.

If transactions are required here or in the future, this abstraction should expose them via a Closeable interface. The abstraction itself may need to enforce transactions if the regular RESTful interface is used instead.

The abstraction also needs to consider app upgrades: the database may need to be upgraded if a new structure is used in the later app version, and data may need to be appropriately moved over. This flow should be completely hidden from callers, though the cost of actually upgrading the database will likely be included in the futures waiting on the database operation to complete.

The abstraction needs to support approximate the size of certain entities despite them potentially being split across multiple tables.

This abstraction should be compatible with the data source system implemented in #6.

Gravitar & user avatar rendering requires special considerations (and likely Glide integration), and is important for the profile selection page.

There needs to be a system that supports enumerating the list of supported languages for a specific exploration/chapter, and allow the user to select that language to localize the lesson. This should be per-chapter and be independent of the app-wide language selection system (see below).

This is tracking implementing the fully polished UI version of the multiple choice interaction.

See the web frontend for details on how the multiple choice interaction works.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• Radio Buttons along with text and entire background

• Final touch up with padding, margin, animations and Accessibility Scanner test

Robolectric tests are a critically important aspect for the development of the app. Such tests will directly impact the velocity at which the prototype can be developed since they will allow for quick refactors late in the development process with minimal risk of regression. This level of flexibility is essential to ensure late requirements can be incorporated without paying significant long-term technical debt or risk the stability of the product.

A profile system needs to be implemented satisfying the requirements described in the Oppia PRD. This system should support storing a context of the currently logged-in profile, and support logging out that profile or logging in another profile. This system is responsible for the pin-based authentication described in the PRD.

Other systems might need to be updated to rely on this context rather than requiring a profile ID to be passed in to simplify them.

Note that for the prototype, it's essential that at least some portion of this system be implemented even if it just defaults to a single user without support for profile switching. Supporting profiles plays a central role in the design for the entire app architecture, so adding it late will be complex.

A management system is needed for the list of topics available to the user, including tracking when this list needs to be updated and replaced with a new copy downloaded from the Oppia backend.

Consumers of this system will want to enumerate the list of topics available to the user, slice that by the user's own activity and progress on those topics, and jump to the topic viewer for a specific topic in the list. Topics sould support organization by their subject. Note that this system is not responsible for tracking progress--a separate system will do that as described below.

There needs to be support for downloading topics. This does not need confirmation based on what network the user is currently on for the purpose of the prototype, but does in later milestones. This also does not require queuing the download; it can be downloaded immediately.

There needs to be a general-purpose data provider system that can be used to observe asynchronous data that can possibly change over time. Subscriptions to these data providers should either be only in background threads with no lifecycle dependencies, or should be transformed to LiveData for UI-bound subscriptions. The data provider system should be used for network, database, and cache I/O, as well as in-memory storage. This system will need a solution for combining or transforming data, as is needed by subscribers.

If an existing system exists to satisfy these core requirements, that should be used instead of implementing a custom system.

There should be an easy-to-use (preferable via fluent pattern) logging system on top of logcat that will be used throughout the app. This should log to a local file specific for the app so that app-level logs can be uploaded with user feedback reports. It's highly preferable to use an existing logging API if one is available rather than building this from scratch.

This is tracking implementing the fully polished UI version of the text input interaction.

See the web frontend for details on how the text input interaction works. This is the first interaction that will be implemented, so it includes designing the general interaction architecture that will be leveraged by other interactions.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• TextInput

• Final touch up with padding, margin, animations and Accessibility Scanner test

The skill training page works similarly to the exploration player, except it's seeded from a set of skills based on where the page is opened from. See the PRD for specifics. This should also behave similarly to the Oppia backend controller that generates a practice session.

The story page should show the user their current progress through the story, and provide links to the corresponding explorations that they can play.

Mock: https://xd.adobe.com/view/e8aa4198-3940-47f9-514a-f41cc54457f6-9e9b/screen/5abb0ace-19ee-48b8-8154-919154f924d2/TP-CL-Chapter-List-/

https://xd.adobe.com/view/ee9e607b-dbd6-4372-48dc-b687d32af3da-98af/screen/cce938d6-e079-4761-bac0-8bde22ac6348/TP-CL-Auto-Scroll-Button-

There needs to be a dialog that shows when a user attempts to perform a restrictive action (such as downloading a topic) when they are not the admin. This should prompt the user to give the phone to the admin, and the admin can enter their password to authenticate. The dialog also needs an option to silence the prompt for a 5 minute interval.

This is tracking implementing the fully polished UI version of the item selection interaction.

See the web frontend for details on how the item selection interaction works. Note that when explorations are downloaded, their item selection assets also need to be downloaded (e.g. images) to ensure that these work properly offline.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/97bc8e75-0232-4079-be1f-3e935fe73e33/TM-Q4-Checkboxes-No-Answer-
(NOTE: This mock reference is from TrainMode and not exploration but both of them will have same mocks for ItemSelection)

Checklist

• ItemSelection

• Final touch up with padding, margin, animations and Accessibility Scanner test

A threading library should be provided to encourage developers to use it rather than relying on other mechanisms (e.g. raw threads and AsyncTask) which, when used improperly, could result in crashes and other issues. This implementation should provide interop with Retrofit, and integrate well with other async mechanisms deemed safe (e.g. Kotlin coroutines with work managers or mechanisms provided by RX).

If it's needed, this threading library should also provide a lifecycle-safe manager for recurring task handling (maybe using Firebase job manager if these need to be long lived tasks).

Individual profiles will need to have data associated with them directly. Such data requires a system to organize other file I/O systems based on the current profile that's selected. This system should interop directly with the other I/O systems described above rather than reimplement them. One possible manifestation of this might be a series of providers for the other I/O systems based on profile ID.

Note that this system is not responsible for managing the current profile logged in, though it should be designed with per-profile Takeout/Wipeout in mind.

The initial Android Studio project structure should be introduced with each of the 5 modules described in the technical design document, with some interactions between them. These modules comprise of:

• App module: this contains the frontend Android code & UIs
• Data-specification module: this contains protos to be used in other modules as the domain model
• Domain module: this contains business logic to be consumed by the app module
• Data source module: this contains code that interacts with the disk and Oppia's backends to provide data needed by the domain module; to be consumed by the domain module
• Utility module: this contains reusable UI utility components, and the data source mechanism that's used to share data between the data source and domain modules

The topic page should provide background information on the topic, skills corresponding to the topic (which link to the concept card for that skill), navigation to training on skills in the topic, the progress of stories the user has played in that topic, and links to stories (with preference for in-progress/immediately upcoming stories, though all stories should be viewable). See the PRD for specifics.

Note that this is tracking implementing the final UI for just the topic page. The final UIs for each constituent tab is indicated as a blocker of this issue.

https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/19cfbacf-854c-4c7d-8691-3b3d117e1866/TP-Overview-

Task Items

• Hamburger Icon and Toolbar/ActionBar title

• TabLayout with icons and titles

• Final check on all fragments and final touch-up

• Accessibility Scanner is working correctly (https://support.google.com/accessibility/android/answer/6376570?hl=en)

Users will make progress on individual topics based on the corresponding stories and skills completed/practices. There should be a system that easily consolidates and reports this information based on the specific topic and profile IDs. This system also needs to download and maintain the individual topics the user has chosen to keep on the local device.

This system is also responsible for managing all stories, explorations, questions, and skills associated with the topic. These may need to be split into their own systems to simplify implementation.

NB: Since the prototype does not need to support manual downloads, this system needs to, by default, automatically download an entire topic (all skills, concept cards, questions, explorations , etc. corresponding to it).

There needs to be a settings page where the user can configure various aspects of their Oppia experience, including viewing and deleting topics that are not frequently used. The user should also be able to change the app language from this page. See the PRD and mocks for specifics.

Users will make progress on individual stories when they play them. There should be a system that can be used to record and retrieve this state based on the story being played (by ID) and profile ID of the user playing it. Note that this system is storing based on individual exploration being played in the context of a story.

The actual storage necessary here is just completed exploration IDs that can be cross-referenced with the exploration IDs contained in a story.

A replacement is needed to SharedPreferences for storing settings and generally caching data since SharedPreferences executes on the main thread which can block the UI rendering and cause ANRs. It's instead recommended to use a proto-backed storage mechanism that relies on background threads (likely via the threading library described below) to perform the I/O. Using proto allows the data structure to be trivially updated to a new structure upon app update without requiring an upgrade flow. Such a system should be strict-mode compliant (that is, does not perform any I/O or long-running operations on the main thread).

This is tracking implementing the fully polished UI version of the numeric input interaction.

See the web frontend for details on how the numeric input interaction works.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• Numeric Text Input (similar to this mock)

• Final touch up with padding, margin, animations and Accessibility Scanner test

The concept card should provide background information on the skill it corresponds to, including worked examples. It should also provide the option for the user to work through practice questions to learn more about that skill. See the PRD for specifics.

Note: from the mocks, this is an inline component within the content card view, though it can also be viewed when reviewing concepts from the topic.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/2ee531cf-c358-4a7d-b9dd-b772b51c3d3c/PM-Q2-Concept-Card-

Checklist

• Toolbar

• Content

• Final touch up with padding, margin, animations and Accessibility Scanner test

The Oppia home screen should follow the requirements listed in the Oppia PRD. It should have access to the navigation drawer, and be accessible from the splash screen if there is already a logged in profile. The home screen should be able to navigate directly to topics, stories, and skill training pages. It should be navigable back from each of those if the user uses the system back button.

Mock Link: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/d47aa8de-a7a8-4d25-b011-5baefc7b7098/HP-Home-Page-

Checklist

• Home Toolbar, also suggestion: do not add "search" icon in this because there is no functionality for search currently.

• Welcome message to learner (check comments before taking this task)

• Recently-played and View All text

• Promoted Story Item (In this mocks are representing a list of promoted stories but for now in development we are keeping only one promoted story at a time) (Also, do not implement "Download" status UI)

• All topics text (Assigned to @veena14cs )

• Topic Summary Item (Assigned to @veena14cs )

• Topic Summary List (Assigned to @veena14cs )

• ContinuePlaying List (Assigned to @rt4914 )
  https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/2b6c8e95-5ac7-4472-bc2b-1c318a3f7e5c/HP-Continue-Playing-

• Full final touch-up, focus on padding/margin and animations

• Accessibility scanner test

Guidelines should be established for how all activities should interact with each other, and how fragments should leverage the back-stack for specific desired navigation. These guidelines should include any existing activities, and may result in changes to those activities. All future activities/fragments should consider these guidelines in their design to ensure that the Oppia app has clear and consistent navigation.

The Oppia GAE backend needs to have an abstraction from which the rest of the app can interact. Since the prototype and MVPs are not expected to support push notifications, this interface will be entirely RESTful with async/future responses with error handling support. This implementation should support RPC retry for appropriate 5xx errors.

Work items:

• Identify among all existing GAE endpoints (get/post), which we can use during the prototype
• Loosely identify data missing from the above endpoints (this bucket is expected to be small/non-existent), and identify which endpoints have data which needs to be changed for the Android app
• Specify the Retrofit interfaces to represent all of the identified endpoints (simple interfaces/no annotations or return types needed beyond pseudocode)
• Identify what data (via pseudocode data structures/YAML/JSON/etc) we will be passing along from the backend through these endpoints
• Identify how error handling will work (e.g. what Retrofit does), whether RPC retry is supported & how it is/can be configured, etc.
• Determine the testing strategy for the GAE endpoints for downstream app components

There needs to be a system that supports enumerating the list of supported languages by the app, and switching the app into that language without changing the entire system language. This should be a setting stored per-profile, and restored upon logging into that profile. There should also be support for temporarily changing the language (e.g. for the profile selection page). Retrieval/updating this preference should be based on the current context of the logged-in profile.

This is tracking implementing the fully polished UI version of the number with units interaction.

See the web frontend for details on how the number with units interaction works.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• NumerWithUnits (similar to this mock)

• Final touch up with padding, margin, animations and Accessibility Scanner test

The navigation drawer should provide navigation options to the home screen, profile selection page (by logging out), settings page, and admin settings page (if the logged in user is an admin). See the PRD for specifics.

It's important that users have the ability to report issues they observe in the app. This should include both free-form text and optionally a screenshot. System logs and other useful debug information should be included, and these reports should be stored securely in Oppia's backend with an easy way to view them to investigate the issues.

This is tracking implementing the fully polished UI version of the fractions interaction.

See the web frontend for details on how the fractions interaction works.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• FractionInput (similar to this mock)

• Final touch up with padding, margin, animations and Accessibility Scanner test

Explanation

There needs to be a system for streaming and playing audio packs selected for a specific chapter by the user, leveraging the default audio language set for the current user's profile.

Low-fi Checklist

• Basic audio player UI
• Alert dialog for cellular network warning (https://xd.adobe.com/view/bee1fced-33bd-4f69-6a89-2c30fe1c4f65-c8d0/screen/d74f0571-471f-4ea6-a3a5-32e135253c56/Lesson-Introduction-4)
• Based on audio, content-card should get highlighted
• Audio language selection
• Play audio via MediaPlayer or ExoPlayer (https://github.com/google/ExoPlayer)

High-fi Checklist

• Seekbar and its animation

• AudioBar along with Volume icon in toolbar

• CellularAlertDialog

• LanguageChangeDialog

• Final touch including animations, positioning and Accessibility checks

Test follow items too

• Check how to audio bar changes on en and hi-en because this might change the seekbar length.
• Shadow below the seekbar thumb (green circle)
• The seekbar progress - white line has a sort of padding at start/end which needs to be removed.
• The seekbar white progress line should be rounded at the end
• [ ]After the volume icon click, the “Language string like HI or EN” takes time to be visible which is not good for the UI.

It's important that a developer-only menu exist in the navigation drawer to provide a variety of debugging utilities. Currently needed functionality:

• Profile functionality
  • Generate multiple child profiles at once with variations like profile with short name, profile with max characters, profile with pin, profile with image, etc.
  • Reset to admin profile only (deleting child profiles) & admin pin
• Mark recently played (requires validation to make sure the app doesn't end in a broken state)
  • Topics
  • Stories
  • Chapters
• Mark completed (requires validation to make sure the app doesn't end in a broken state)
  • Topics
  • Stories
  • Chapters
• View logs
  • Analytics event logs
  • Logcat logs
  • View performance analytics (once available), and introduce option to reset these counters
• Directly accessing learning material
  • Topics (requires topic ID)
  • Explorations (requires topic ID, story ID, and exploration ID)
  • Revision cards (requires topic ID & subtopic ID)
  • Concept cards (requires skill ID)
• App-wide behavior changes
  • Force all hints/solutions on by default (toggle)
  • Fix question generation seed to a specific value (to have reproducible practice sessions)
  • Force app to run in wifi/cellular/no network case
  • Switching the Oppia backend (e.g. between production, testing, and local)
• Miscellaneous (one-off actions)
  • Crash the app
  • Force restart the app
  • Dump all datastores to a shared file location to make it easy to pull off the device (e.g. for release version of Android)
  • Force admin authentication flow

Oppia has a bunch of web-specific data being populated in GAE response payloads, many of which are difficult to consume by the Android app (e.g. hex colors or relative URLs to avatars). These endpoints need to be updated to be more platform-agnostic.

This requires filing and tracking corresponding work items in https://github.com/oppia/oppia.

The Oppia splash screen should be shown for the duration required for the profile to be loaded and the app fully initialized (database upgrading can block this screen). This is nice-to-have for the proof-of-concept to help introduce a proper app loading flow.

The Oppia GAE backend needs to provide download payload lengths to the frontend to enable progress-based downloads. This needs to be investigated since it's not clear whether large payloads can be downloaded in one stream, or if the backend needs a streaming service. Also, it's not clear whether the HTTP content length header is sufficient for this purpose, or if a custom length header needs to be provided.

This requires filing and tracking corresponding work items in https://github.com/oppia/oppia.

Learners should be able to assemble a random assortment of questions based on preselected skills to train and review those skills.

Specific things to complete (from #500):

• End of question player has weird scrolling
• Not following mocks (initial implementation is closer to the exploration player and doesn't follow the non-conversational flow of the mocks)
• Add hints & solutions support (partially supported in the shared state recycler view assembler from #500)
• Add audio voiceover playback support (partially supported in the shared state recycler view assembler from #500)

There are various actions in the app (such as trying to download a topic) which require privileged (adminstrative) access. There needs to be a system to allowing user actions to be protected by the administrator account, or overwritten with per-profile settings.

Content cards can be paired with questions that hold an interaction for the purpose of quizzing the learner on a particular concept. Questions are used when reviewing concepts, training skills, or within an exploration as part of a story. See 3.2.4 of the technical architecture document for the interactions that will be supported in the prototype.

There needs to be an admin settings page for permissions that may not be enabled for individual profiles, and for settings that can be enabled for individual profiles (e.g. such as whether users are allowed to delete topics from the device). See the PRD for specifics.

The exploration player should be functionally close to the reactive exploration player in the web frontend, though with mobile-specific considerations. At a high level, this player should:

• Displaying cards (see #26)
• Playing audio tracks (see #17)
• Support back-and-forth navigation
• Submitting answers (see #27)
• Tying into skills when questions are answered
• Linking to concept cards
• Recording story progress when completed (time permitting)
• Full answer classification minus ML since that is a WIP
• Misconceptions & hints triggers
• Redirection to other cards
• Correct/wrong answers
• Missing prerequisites as feedback for showing concept card

This is tracking implementing the fully polished UI version of the end exploration interaction.

See the web frontend for details on how the end exploration interaction works.

Mock: https://xd.adobe.com/spec/e2239cf4-9cde-4c08-5296-25316c1f0a14-9412/screen/40d6cf5f-f673-42c8-af15-035f711ef6b9/PM-IN-Introduction-

Checklist

• Return to Topic Button

• Final touch up with padding, margin, animations and Accessibility Scanner test