SCORM 1.2 player in the Mobile app: Difference between revisions

Revision as of 14:50, 13 January 2016

SCORM 1.2 player in the Mobile app
Project state	In Progress
Tracker issue	https://tracker.moodle.org/browse/MOBILE-938
Discussion	{{{discussion}}}
Assignee	{{{assignee}}}

Introduction

SCORM module support in the mobile app is one of the most requested features by users, specifically, the ability to play SCORM packages offline in the mobile app including synchronization of the tracking data once the device is online again.

In this document we are going to do a brief analysis about what will be needed to implement in both the Mobile app and Moodle code to add support to play SCORM packages.

Moodle Mobile The current Moodle Mobile app is an HTML 5 application that uses other common web technologies. It is a client application that uses REST protocol web services to send and get information from the Moodle installation. Recently, we have started working on another version of this Moodle Mobile app using Ionic framework with AngularJs to overcome the current mobile application’s technical problems.

What is SCORM? SCORM stands for Sharable Content Object Reference Model. It is a common standard introduced by Advanced Distributed Learning. Those standards facilitate the use of SCORM based content in any management system without any hassle. SCORM consists of two main parts: Run Time Environment and Content Aggregation Model.

Run Time Environment This describes how the content of the SCORM package should behave when it is loaded by a learning management instance. In this project, we will mainly tackle this section. The run time environment consists of 8 main functions that facilitates the access to the LMS.

Content Aggregation Model This describes how a person who is creating SCORM packages should package that content according to the SCORM standards.

The 8 main functions in the run time environment need to be implemented as a Javascript API. Since we are doing this project using AngularJs, this should be done by fixing it to an Angular Module. This Angular module will have all the necessary controllers and services to handle communication between an external SCORM package and the Moodle site.

Functionalities

The minimum functionalities to be supported would be:

Support for SCORM 1.2 packages only
Support for zip SCORM packages only (no alternative methods for adding SCORM contents)
Complete support for the SCORM 1.2 API runtime
Support for playing packages offline

Technical Overview

There are currently several Javascript SCORM players with basic support for SCORM 1.2:

The aim of this project is to improve and package inside an AngularJS module one of those players and include it in the official Moodle Mobile app. We are talking about AngularJS because the new version of the official Mobile app (Moodle Mobile 2) will be build using the Ionic framework that is based in AngularJS

In order to be able to support playing SCORM files from a Moodle site in the app, we need to develop new code in both Moodle and Moodle Mobile and also do some changes in the current code:

In Moodle:

A new set of external functions in the SCORM module to be used as Web Services by the app in order to:

Retrieve a list of all the SCORM modules inside a course
Retrieve tracking information from a particular user in a SCORM package (e.g. list of attempts, current attempt status, etc..)
Send tracking information of a particular user in an existing SCORM package
Some modifications in the current SCORM module (described below) to allow teachers to choose if they want make a SCORM module available to mobile users and then allow downloading full SCORM packages.

In Moodle Mobile:

A generic AngularJS SCORM player module that should be able to parse the imsmanifest.xml file, display the SCORM and navigation TOC and implement a local SCORM runtime
A new addon for the SCORM module that will contain the AngularJS SCORM player and will perform tasks like downloading the SCORM zip package, retrieving the SCO tracking information from Moodle and synchronizing the results.

Moodle requirements

SCORM module changes

In order to make possible to play SCORM packages in online and offline modes, the Mobile app needs to download the complete zip SCORM package and extract to the local sdcard/storage system.

This means that we need to add support to downloading the zip packages via the SCORM pluginfile callback, but this presents some problems:

There are several ways for adding SCORM packages into a course, we are going to support only zip packages uploaded and those downloaded via URL to a zip (filesystem repositories won’t be supported either).

Privacy/security: Sometimes, teachers or administrators don’t want to share the complete zip packages, we will need a new SCORM module setting called “Allow to download complete SCORM packages” or something similar so a teacher can disable the zip packages download at any time. For existing packages this option should be disabled, but for new it should enabled by default.

Package size: Sometimes SCORM packages are huge; the storage capacity in mobile devices is limited so it will be necessary to detect the zip package and the free space available in the device

The Mobile app will notify the user if the SCORM package is supported, checking if the package was uploaded or downloaded via URL, if the “Allow to download complete SCORM packages” is enabled, and if there is enough free space in the device.

Why is it mandatory to download the complete zip SCORM package?

The app does not support SSO to Moodle, so it won’t be possible just to embed the SCORM player into an iframe
We can try to parse the imsmanifest.xml and then display in an iframe the requested files pointing to the Moodle pluginfile.php file, but this presents two problems:
We’ll need to parse/pre-process all the HTML files to fix the links to point to http://yourmoodle.com/webservice/pluginfile.php/zz/yy/file.html?token=authtoken
We will be sending lots of requests to the Web Server, exposing the authentication token (since it’s needed to validate the user credentials)

New external functions

mod_scorm_get_scorms_by_courses

Parameters: list of course ids

Returns: A list of SCORM packages module settings in the specified courses, including only the settings the user may see (according to his permissions).

This external function will also return information like the size of the zip package and a md5 hash to detect if the package has been updated.

Via this external function, we will be able to check if the SCORM package can be downloaded and played in the app.

mod_scorm_get_scorm_attempts

Parameters: scormid and userid Returns: A list containing information of all the attempts done by the specified user id

This will be used to know the current attempt status for the user (last attempt, etc..)

mod_scorm_get_scorm_scoes

Parameters: scormid

Returns a list of scoes inside the specified scorm

mod_scorm_get_scorm_user_data

Parameters: userid, attempt

Returns all the user tracks for all the scorm scoes (including objectives and interactions)

This will be used for preparing the API runtime data

mod_scorm_insert_scorm_track

Parameters: scoid, userid, attempt, element, value

Inserts track information about a SCO

Returns: true or false (success or not)

Moodle Mobile requirements

SCORM player

The SCORM player will be an AngularJS module integrated in a Mobile app addon. It will be responsible for:

Parsing the imsmanifest.xml file in order to display the available Organizations and Structures inside the package.
Displaying a basic SCORM player with a basic menu tree.
Implementing a basic runtime support in order to retrieve the SCOs tracking information (including objectives and interactions) and sending tracking information too.

The SCORM player will be an agnostic AngularJS player that will communicate with the Mobile app SCORM add-on via the SCORM runtime.

Moodle Mobile SCORM addon

A new addon for the SCORM module that will contain the AngularJS SCORM player and will perform the following tasks:

Downloading and synchronizing the SCORM zip package
Unzipping the package into the device persistent storage
Populating the SCORM SCO’s default tracking information
Storing and synchronizing tracking information with Moodle via Web Service

In order to do that, the SCORM player (AngularJS module) will have to communicate with the addon via the API runtime (functions LMSInitialize, LMSGetValue, LMSSetValue)

Use cases

Online

Scenario:

   A teacher has created a Moodle course including 3 SCORM packages: two packages uploaded via zip and a second package pointing to a imsmanifest.xml file via URL. One of the uploaded packages is around 250MB, the other one around 20MB
   The teacher has allowed the two uploaded packages to be accessed via the Mobile app.
   A student opens the course using the Mobile app. He can see listed the 3 SCORM packages, but when he tries to open the linked package he gets a warning message saying that this SCORM package is not compatible with the app.
   When he tries to open the SCORM package (the one that is around 250MB) he gets a new warning about the size of the SCORM and the current free space (300MB), therefore the user cannot download this package.
   Finally, he tries to open the last SCORM package, and he sees that this package is compatible with the device. When the user opens the package in the app, the following happens:

The app checks if the package was already downloaded, if so, it checks if the checksum is still valid; if it’s not, it downloads the package again. If the package was not downloaded, the app downloads it. The app via the mod_scorm_get_scorm_attempts WS tries to resolve the current attempt for the user (resume, start a new one) The app then retrieves the list of SCOes inside the package via mod_scorm_get_scorm_scoes, and the SCORM SCOes default data via mod_scorm_get_scorm_default_values When this information is ready, the app launches the player that via LMSInitialize will initialize the first SCO data The student does some activities inside the SCORM and some information is stored via LMSSetValue. Once he has finished (or every time LMSCommit happens or iv scorm->autocommit is enabled), the information is stored in Moodle via the mod_scorm_insert_scorm_track Web Service

Offline support

First of all, to be clear, SCORM is a standard that wasn’t designed to work offline and synchronize data. One of the reasons forcing ADL to sponsor xAPI (Tincan API) was the impossibility of working in offline scenarios with SCORM (see http://scorm.com/project-tin-can-phase-3-tracking-offlinelong-running-content/).

With this premise—SCORM not being suitable for offline mode—we needed to lower our expectations. We needed to do something simple that also works for 90% of the cases.

So basically we came up with two approaches for implementing SCORM offline:

Approach 1: Data merging

   This is the most complex approach that basically would work merging data between the online and offline mode. We currently can’t implement this approach because the Web Services does not return data like the time a track entry was created or modified.
   Merging data is very dangerous because in some cases the SCORMS developers use different elements of the specs to store data that must be synchronized (suspend_data and lesson_status, for example). We did an initial study of all the possible cases and we found it very complex to implement something that works for the final user.

Approach 2: Independent attempts:

   This approach profits from the self-contained characteristic of Moodle attempts.

   Moodle attempts are independent, this approach have the following considerations:

If the user is ONLINE he can continue and start new attempts that automatically will be synchronized with Moodle (real time)
If the user is Offline, the user can:
Start new offline attempts (if the previous online or offline attempts are finished).
Continue existing offline attempts.
Continue existing online attempts. In this case, since the online cached data could be outdated, we’d ask the user if he wants to start a new offline attempt or continue with the online one. * If the user chooses to continue an online attempt but our cached data doesn't matches Moodle data when synchronizing, a new attempt will be created.
If the user is Online and he switches to Offline: same as continuing online attempts, we’ll ask the user what to do (in this case we take a snapshot of the data to compare to the remote data, when we try to synchronize if the data don’t match we’ll be creating a new attempt)

Using this approach forces us to have a strong and clever synchronization process, This process should be able to analyze all the possible scenarios to check if it can synchronize data or not.

Some cases:

Moodle Web all attempts finished and Moodle Mobile one attempt pending to be synchronized: In this case, the process should check if we’ve reached the attempts limit
Moodle Web last attempt not finished and Moodle Mobile one attempt pending to be synchronized: In this case we cannot synchronize, we should advise the user to finish the Moodle attempt
Moodle Web last attempt not finished and Moodle Mobile same attempt continued: Compare the snapshot, if it matches it means that the user hasn’t modified anything in Moodle web so we can synchronize the data. If the snapshot doesn’t match with Moodle web’s data, create a new offline attempt that will be synchronized when the Moodle Web attempt is finished.
Moodle web last attempt not finished and Moodle Mobile last attempt not finished (different attempts). The user is online, in this case the user must finish the offline attempt

All the possible cases:

Case 1: SCORM in Moodle Web does not have attempts User is offline There aren't attempts not synchronized

Get the attempts count ( 0 if not cache available) Check the attempt limit number Get SCOES TOC: Create empty User start a new attempt Save attempt tracks If the user leaves, we try to synchronize if he is online, if we synchronize we fetch all the required data for the next execution get_user_data, get_scoes_track

Case 2: SCORM in Moodle Web have attempts User is offline get_attempts_count is 0 There aren't attempts not synchronized

Same case that above

Case 3: SCORM in Moodle Web have attempts User is offline The last attempt is finished There aren't attempts not synchronized

Same case that above Except for the TOC that is cached (last attempt) but not the player TOC that will be empty

Case 4: SCORM in Moodle Web have attempts User is offline Last cached attempt is not finished There aren't attempts not synchronized

New attempt always or continue the attempt? Ask the user, because if he continues and we cannot synchronize the continued attempt will become a new attempt

Case 5 User is offline The last offline attempt not sync is finished There are attempts not sync

Start new attempt, and then Case 3

Case 6 User is offline The last offline attempt not sync is not finished There are attempts not sync

   Continue the attempt
   Index TOC with offline data
   Same TOC for player
   When the user finishes, try to sync

Case 7 User is online Then go offline

Try to sync the current SCORM Make an snapshot, ask the user to continue the attempt or start a new offline attempt Try to sync

Case 8 User is offline Then go online

Try to sync, we sync when the TOC change also. Sync is complex, operations are not atomic

Case 9 User is online Offline attempt not finished Online attempt not finished

Force to finish the off-line? (ask Gavin-Martin)

Case 10 User is online Offline attempt finished Online attempt not finished

   Sync process will do,

we need to display to the user a list of not-synchronized attempts

Synchronization cases

When the app tries to synchronize a SCORM it can find these cases:

1- SCORM only has online attempts. Nothing to sync.

2- SCORM only has offline attempts. Send them all to Moodle (without surpassing max attempts).

3- SCORM has online completed attempts and new offline attempts (consecutive to the online ones). Send the offline attempts as new attempts (without surpassing max attempts).

4- SCORM has online completed attempts and new offline attempts NOT consecutive (the offline attempts were created over a cached version or similar case). Modify offline attempts numbers to place them after the online attempts and send them to Moodle (without surpassing max attempts).

5- SCORM has an online incomplete attempt that has been continued in offline. Compare snapshots:

   5.1- If snapshots match (attempt hasn’t been modified in Moodle), send offline data.
   5.2- If snapshots don’t match, convert offline attempt into a new attempt. After this conversion we will end up with one of the following cases: 3, 4 or 6. If max attempts has been reached then the offline attempt will be discarded.

6- SCORM has new offline attempts created over an online completed attempt, but we receive a new online incomplete attempt. The last offline attempt can be completed or not. User has to finish the online attempt before we can send the offline attempts (the offline attempts will be created AFTER the online one without surpassing max attempts).

Documentation