Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Objective

Refactoring the player to extract the business logic from the Rendering of the Player so that it becomes reusable in other services.

Background

The current QuML Player is an Angular App that outputs a web component. A lot of the functionalities as described below are part of the Android Components.

  • Fetching the QuestionSet, Sections and getting individual Questions Metadata

  • Playing through the Questions (linear or non-linear)

  • Events like when to send Hints, Timeouts, Errors are part of the application state

  • Telemetry

All of the above is business logic and can be extracted out as common code and not be as tightly coupled with Angular. Making this loosely coupled with enable the common code to be reused in variety of other JS frameworks like React, React Native, Vue etc and will provide developers with basic tools on which to build their own QuML players. The said extraction can be ported to other languages by the community to further use the QuML spec in creative ways.

One of the use-case that can be enabled using this is for dissemination of questions in a chat based platform like UCI. Questions being sent one at a time.

Solution

Dividing the current structure of code into two parts question player and renderer. The player and renderer will communicate with each other through

  1. Events pushed by the player async using the EventEmitter. These are to

    1. abstract out the side effects of state mutation from the renderer.

    2. This also allows for external mutations outside of renderer to happen.

    3. This also helps when in the use cases where the renderer mutates the state through some other means - like an webhook response which can be hooked up with the APIs exposed by player.

  2. APIs exposed by the player to mutate the state by the renderer.

    This follows a unidirectional approach to update state rather than the bidirectional one to reduce complexity in debugging. So the renderer updates state using the Player API and the player then schedules any events if needed due to star.

Core features to be extracted

  • Fetching of a collection

  • Iterator for QuestionSet, Sections or any other collection

  • State Management for the following entities

    • Player

    • User

  • Events Management - Store and emit appropriate events for the renderer when the state is mutated by the renderer.

    • Entry and Exit (Question Set, Section, Question)

    • Telemetry

    • Hints

    • Attempts

    • Errors

    • Time Limits

  • Persistence Layer Interfaces

  • Generic metadata storage object

Interfaces and Classes

The pseduo/live code can be tracked here - https://github.dev/ChakshuGautam/sunbird-quml-player/tree/player-refactor. The code is in the folder refactor.

Integration Guide for Angular - WIP

Open Questions

  1. Should the player be allow for a callback based event processing? For example creating a telemetry event and sending it through event callback?

  2. Should the player allow for the

Prerequisites

A couple of things that need to be closed before the refactoring starts

  1. 100% code coverage on main-component

  2. Testing script (npm) to watch all tests.

  • No labels