Step 8 – The LMSSetValue() Function

The LMSSetValue() function is very similar to the LMSGetValue() function that I described in my last post except that we might have a problem with the amount of data that we’re transferring to the server.

If you’re familiar with programming HTML forms, you’ll know that the GET data submitted using a form is limited in size by the browser that you’re using and/or the server that you’re accessing. Either way, it’s better to avoid using GET if you have anything more than a small amount of data, or if you don’t know how much data you’ll be dealing with. Therefore, for the LMSSetValue() function, I’ll employ a combination of:

  • The GET method for the variable name and the random code;
  • The POST method for the data that we’re trying to store in the LMS database.

So here’s what the LMSSetValue() function looks like.

function LMSSetValue(varname,varvalue) {

  // create request object
  var req = createRequest();

  // set up request parameters - uses combined GET and POST
  req.open('POST','setValue.php?varname='+urlencode(varname)
        +'&code='+Math.random(),false);
  
  // send header information along with the POST data
  var params = 'varvalue='+urlencode(varvalue);
  req.setRequestHeader("Content-type", 
             "application/x-www-form-urlencoded");
  req.setRequestHeader("Content-length", params.length);
  req.setRequestHeader("Connection", "close");

  // submit to the server for processing
  req.send(params);

  // process returned data - error condition
  if (req.status != 200) {
    alert('Problem with Request');
    return "false";
  }

  // process returned data - OK
  else {
    return "true";
  }

}

I’ll highlight the areas of the code where it differs from the LMSGetValue() function:

  • Lines 7 and 8 – Exactly the same as the LMSGetValue() function except that I specify the ‘POST’ method for transferring data rather than ‘GET’.
     
  • Line 11 – I set up the data that I want to transfer using POST – in this case, simply the value that’s to be saved to the LMS database – and temporarily store it in a JavaScript variable called ‘params’.
     
  • Lines 12 through 15 – I set up the request headers that will be sent to the LMS server to tell it that POST data is being submitted.
     
  • Lines 18 – I submit the request to the server along with the data to be stored in the LMS database.
     

Now that the SCORM RTE API has been modified to send and receive requests to the LMS server using AJAX, it’s time to figure out what to do at the server end of things. And that’s going to be the subject of my next post.

This entry was posted in Run Time Environment. Bookmark the permalink.

3 Responses to Step 8 – The LMSSetValue() Function

  1. Joe says:

    First of all..excellent tutorial!
    Have you ever experienced any performance issues as a result of the third parameter (asynchronous/synchronous, true/false) being set to false (synchronous).
    I understand that in the GET call, we need to wait on the return, but it seems as if we can set it to asynchronous on the SET call. Make sense?
    -Joe

  2. Steve Addison says:

    Hi Joe

    I have seen performance problems as Step 43 – The Need for Speed (posted today – Tuesday, November 17th, 2009) discusses. But they were (I believe) to do with the course’s use of LMSetValue and LMSGetValue causing excessive numbers of AJAX requests.

    I did try the ‘asynchronous’ option early in my investigations, but ran into problems. It seems that courses (SCOs) often use an LMSSetValue() to set a data element value, and then immediately use an LMSGetValue() to read it back into the course in order to make sure that it was transferred correctly. From what I could make out, using ‘asynchronous’ could result in LMSGetValue() being executed before the LMSSetValue(). In this case, the course sees it as an error in transferring the data.

    So, in summary, I don’t think you can use the ‘asynchronous’ mode without the risk of confusing the course. Hopefully, the caching system that I’m working on right now will make this problem irrelevant.

    Steve

  3. Charles says:

    Hey Silas Yeah, reporting is still trckiy with native apps. The problem is the traditional code added into the HTML assumes the file is running on the server. In order for this to work correctly with an LMS, the user would have to enter their username/password in the app. The app would log them in to the server and pass the data back and forth. Lots of coding involved there. If you are just tracking some generic input (i.e. it’s a form they are filling out), it’s a bit easier, but you’d still need to write some code to capture that input and send it to your server. And yes, you would need to write this before the phone gap step.By the way, I’ll be uploading another video shortly showing a slightly different process of building and app that might help.

Leave a Reply

Your email address will not be published. Required fields are marked *