Question about the inProgress field


Andrew writes,

"I think I am still in a "session" mindset, though I can see xAPI may be more geared at sending the data once the activity is over. The problem I can see myself having though is making sure that if the user closes the window or their computer crashes or whatever, how can I make sure that their progress is saved and their attempt reported to their lecturer/supervisor etc? That's what I'm trying to address with the questions below. 


I do have a couple of further question about  "inProgress" though. I'm setting it to true whenever I send a statement to the Public LRS I expected perhaps that this would cause the LRS to update my initial statement, but rather a new statement is created every time, so I'm flooding the public LRS's feed. Is it up to the LRS how it deals with  "inProgress" and how should I be dealing with changes in result? 


My second question has to do with setting  "inProgress"  to false. Currently I plan to do this by sending a final statement when either the user clicks an exit button, or window.beforeunload or window.onunload are called. Is this the best way to do this? What happens if a user closes their browser window and they are using a browser that does not run window.beforeunload or window.onunload? How are LRSs expected to manage attempts which never set "inProgress" to false?"
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


  • Avatar
    David Ells


    Though xAPI is purposed for new learning scenarios that are not within traditional confines of browser sessions, we do want folks to exercise it's flexibility towards excellent backwards compatibility.

    The inProgress field is not used by the LRS in anyway. It is meant to provide a hint for either humans looking directly at the statement stream, or for reporting tools that might use it to logically group statements. The same can be said about the "attempt" concept that is noted in the TCAPI spec. Using a verb that signifies a new attempt (or not) has no affect or implication for the LRS, it only serves as a hint to guide reporting tools.

    With that said, here are more direct answers for your questions: 

    1) A big stream of statements can be a good thing, so you shouldn't worry much about that. Statements are immutable, which means they cannot be updated. Depending on what it is that you're updating, it may be useful to see those updates over time, or on the other hand you might want to report only important changes, or only at a certain time. If there is some bit of state that you'd like to update which the course relies on to function (think SCORM suspend data), you can use the State API part of xAPI to store and update that, without generating any statements. 

    2) As noted, there is no special processing an LRS is required to do for any "attempt" concept, it is only provided as a way to help users and reporting tools make more sense of the data. The scenario you mention regarding the browser unload event is just the sort of problem we hope to avoid in xAPI. That is, though many applications or courses (within and outside of eLearning) might still rely on unload, it is not baked into the spec itself as a requirement. With that said, it's important to remember that marking browser sessions in a course will only be as reliable as the way you implement it, whether that is through unload, beforeunload, or a mix of events for different browsers.

Powered by Zendesk