I have a fairly simple in-house LMS. It essentially consists of an ASP.Net page which handles launching courses and a javascript implementation of the SCORM 2004 API. The javascript implementation is included on the ASP.Net launcher page using a simple include in the head section.
When a SCORM compliant course is launched by the page in a new window, it uses the standard SCORM API search algorithm and locates the instance of the SCORM API on the LMS course launcher page. This is all pretty standard SCORM behavior so far, nothing out of the ordinary.
The problem I am having, is that if the launcher page is refreshed for some reason, then the API instance is lost, and the course is no longer able to communicate with the API. I have gone back to the SCORM 2004 standards documentation, and cannot find anything in there about what the SCO is supposed to do in this instance.
Is this just a limitation of the SCORM architecture, or is there something I could do in my implementation to prevent this from occurring?
Is it the SCO's responsibility to try to search for the SCORM API again and reinitialize it?
I know there are lots of LMS's out there that implement SCORM, and I'm wondering if anyone knows what methods they have implemented to prevent this from happening, if any?
Does anyone familiar with SCORM LMS architecture have any suggestions to prevent loss of the API instance when the opener page is reloaded?
The main issue you have here is that once the player window is refreshed, the window.opener relationship between the content window and the player will no longer be valid. Even if you could have the content try its API search algorithm again, it would not work because of this.
One alternative approach is to force an exit of the content whenever your player window is refreshed/closed. I work for a company that makes a very popular SCORM player, and this is the route we take.
When your player page opens the window with the content in it, you can keep a reference to that new window in a variable. Then in a beforeunload/unload handler on your page, you can check if the content window is still open and close it as part of your exit routine.
While that's not quite the same outcome you wanted, it does keep the learner from continuing to interact with the content in a state where their progress won't actually get persisted.