Writing and Reading Cookies
Mar 14, 2011
The question: Can AP write a cookie to a name and with contents that I specify, then read that cookie at a later time?
The task: I'm being presented with 20-25 SCOs most if not all of which are in Articulate Presenter. The client wants a single graphical interface similar to an iPhone to function as the 'menu'. Tying all the SCOs together into one would make a SCO that is totally unwieldy. The size is still undefined but anticipated to be 8 - 16 hours total. Also I know that some piece of information in the entire package will change on a fairly frequent basis and I don't want to have to deal with modifying and republishing something of that size frequently.
My thought is to have each SCO write a cookie when it reaches the last screen. I'll also have the first screen of each SCO be the iPhone Menu screen that reads the cookies from each of the other SCOs and indicates in some fashion whether each SCO has been completed/not completed. The SCOs will be running in an LMS, but I can't replicate an iPhone interface like the client wants within the LMS.
This is the best solution that I have come up with, but am totally open to other suggestions, and of course this solution totally depends on being able to write a cookie that I can retrieve later. The next best solution is for the AP SCOs to write the cookie. I could then use a different Authoring System to hold the iPhone interface Menu, and also launch the rest of the SCOs while still maintaining normal tracking in the LMS.
Thanks for any suggestions that anyone has.
4 Replies
You may be able to capture the completion data of each individual SCO and pass this to a frame. If you're comfortable hand jamming code for each Articulate file this shouldn't be too tough.
There isn't anything built in. But since all of the API wrapper and cookie stuff is editable in notepad, the tool doesn't prevent it. You'd need to write your own "super wrapper" to manage the data I/O and completion logic. I'd recommend leveraging suspend data from the LMS vice a client side cookie. Suspend data is more portable and less volatile.
Thanks for the information and suggestion Steve. leveraging the LMS Suspend data would definitely be preferrable as it is totally portable wheras cookies are not. Trouble is, I don't know how to do that, how do I retrieve the suspend data from the LMS? BTW, I'm using SumTotal ROD 8.2. I know it is SCORM but SCORM still give the LMS some lattitude in how it does things.
Hi Don,
I've had some success building custom wrappers that work with SumTotal (8.0 was the last version I tested with) by extending the excellent framework built by Philip Hutchison (http://pipwerks.com/laboratory/scorm/). You'll want to build an I/O function to concatenate all of your suspend data and modify your API wrappers for each course to intercept the write and read calls and pass them up to this function (targeting a specific frame).
It'll be a bit of an engineering effort, but should be pretty doable.
Thank you Steve. I'll take a look at Phil's framework and se where I can go from there.
This discussion is closed. You can start a new discussion or contact Articulate Support.