Offline mode (OM) for course mainly consists of 3 main parts:
Additional information, questions and updates:
This part is about how user will receive a content for a specific course on their device to be able to work while offline. This requires to download:
course info
dates
discussions
XBlocks
updates
handouts
For JSON based data it is going to be cached for future offline use. No extra work on the backend.
For XBlocks a compressed file with all static files is generated presumably only on course publish event.
media file is going to be created for downloading which path/filename will be based on the XBlock path. This allow to omit extra backend endpoint for media file path
media file should be using storage classes to be configurable in production
static content will be put near the main XBlock’s HTML file and all the links are changed to forward to local static directory
each XBlock is separate compressed archive
This part involves batch data transfer when a user goes online after being offline. It requires to take care of:
XBlocks submissions
Events
Course XBlocks updates
Create:
endpoint that accepts user’s submissions in a batch
endpoint that accepts user’s events in a batch
it is required to insert a JS bridge for mobile application to intercept XBlocks JS Messages (similar to Iframe PostMessages). For now we can assume that submit answer and sending events should be intercepted.
Messages sent to mobile are grouped by XBlock
For the same XBlock requests are processed in the order of timestamp
Changes to XBlocks should reflect on the downloaded course XBlocks state. This means default state of the XBlock when user sees it for the first time changes to the state after user submitted a response and obtained a feedback.
When state of XBlock is changed (default state of the XBlock when user sees it for the first time changes to the state when user submitted a response and obtained a feedback), in the offline mode XBlock is displayed with a feedback.
If server returns 4xx or 5xx it is required to store their requests and not loose a progress. Process this case intelligently.
Handle conflicts and make a comprehensive response.
Assuming there can be situations:
where user did some actions in both offline mobile and online web
user did some actions before a deadline and went online after the deadline
[here can be more cases later]
bad internet connection == offline? Assuming that there can be large data to send and user can have poor experience with online in that moment. We can propose to use offline mode in this case or automatically use it.
processed based on the server timestamp or mobile timestamp?
should be processed in order of timestamps
This part is partially touched in the section above when state changes are mentioned. There are different scenarios when the XBlock stored on the mobile device for offline mode is required to be updated.
course XBlock was changed after user had downloaded the course
user obtained a feedback in the XBlock. Consequently user should see feedback in offline
Endpoint for XBlock can be extended with query parameters to be able to download default state of the XBlock and state with a feedback. If user would want to reset his feedback in the offline mode there will be 2 XBlocks states already stored.
Potentially it would be good to know which XBlocks are outdated before sending batch data to the server. By this potential conflicts can be avoided. Validating all XBlocks can require to have a separate endpoint with last updates dates. Mobile application can compare each XBlock update date and react in different ways like show some information for user or skip submissions for outdated XBlock.
Here will be information on which XBlocks are offline-friendly and which are not and why
Questions and updatesAssumption:
|