Update: A few months after writing this journal entry, I developed SCORM class files for ActionScript 2 and ActionScript 3 (both require ExternalInterface). Check them out here.
- SCORM is a standardized method of communicating between a web-based course and a Learning Management System (LMS).
It looks like this:
[ you > cellphone < mom ]
Old-School #1: FSCommand
Old-School #2: GetURL and SetVariable
The second old-school technique is to use ActionScript’s
getURL() coupled with
//ActionScript: //watch() or setInterval() used here to detect //when variable "myVar" has been updated.Code language: JSON / JSON with Comments (json)
This technique wasn’t very popular because it was hard to implement, could only pass strings (no object, arrays, etc.), and was also asynchronous.
First, a few things to note about loading external variables into a SWF:
- When a Flash SWF first loads on a page, it’s really easy to pass variables into the SWF from your HTML page using FlashVars.
- If an HTML page has two SWFs embedded on it, passing variables between the two SWFs is (relatively) easy using LocalConnection.
- Passing variables to a SWF AFTER the SWF has already been embedded to the page is the tricky part.
(Warning: this may be a gross oversimplification.)
Sounds reasonable, right? This biggest benefit of the FJIK method is that it isn’t limited to passing strings; it supports passing different variable types, such as objects and arrays. It proved to be a popular technique, but it had a few significant drawbacks: transfer speed (you have to wait for a new SWF and FlashVars to load each time you make a call), the required use of 4 or 5 external files (.as, .js, and .swf) is cumbersome, and — like the getURL method — the data is returned asynchronously. No instant ‘return’ statements.
The new-school technique is to use ExternalInterface, which was specifically designed by
Back to the point: Why the attempt at a hybrid?
You might ask: Why was I trying to make a hybrid of old and new techniques in the first place? The new-school ExternalInterface method works fine and is super-easy!
Answer: ExternalInterface works fine for people with Flash Player 8 and above. That eliminates the majority of the student population I’m targeting. Yes, I know Flash Players v8-9 are supposed to be ubiquitous, but the IT dept. at my workplace installed Flash Player 7 in early 2005 and hasn’t updated most of the machines since then. Employees have no admin rights on their computers, and therefore way to update Flash without calling IT to come do it. When you have over 5,000 employees, this becomes a big issue. It will be at least a few months before the majority of users get Flash Player upgrades.
I also have a colleague in a similar situation, except his target audience is mostly Mac users! This means FSCommand won’t work for him, and can’t hold him over until his end users get Flash Player upgrades.
How I hoped it would work
This would have allowed me to use the same function calls in Flash Player v6-7 as in Flash Player v8-9, regardless of what technique was being implemented under-the-hood. However, because ExternalInterface and the FJIK each rely on imported classes, have such different syntax, and aren’t both synchronous (only ExternalInterface is synchronous), it would have been a huge headache to try and cram these very different techniques into one course. Bah humbug.
Why not use getURL/SetVariable instead of FJIK?
So whatcha gonna do?
Wait until we upgrade to Flash Player 9. Sucks, but it’s a pragmatic choice.
I’m in a unique situation in that our IT dept. only supports Internet Explorer on Windows PCs. So far I’ve been able to use the easy-to-implement (and PC-only) FSCommand. I’ll be the first to admit this is something I’ve never been happy about, but hey, it has been a practical and fully-functioning solution for over 2 years. When I developed my current Flash course interface, I knew ExternalInterface was over the horizon, so I didn’t bother with getURL or the FJIK (which hadn’t been released yet). Little did I know that over 2 years later we’d still be supporting Flash Player 7!
In my own defense, I must say that I haven’t ignored standards and best-practices: everything else I’ve built is been cross-browser and cross-platform, including course content. But my guilt is catching up to me, along with a new crop of Mac users at work! It’s in all of our best interests for me to stop using FSCommand in our SCORM courses. If it weren’t for that stinkin’ Flash Player 7 on our older computers… grrr.
So my plan for now is to develop an ExternalInterface version of our Flash-based course interface, and have it ready for that fateful day when the IT guys tell me Flash Player 9 is up and running on (most of) our machines. Sigh… I was hoping for a happier ending!
Here are some interesting articles I encountered while doing my research:
Excellent wrap-up of this very nagging issue. If it’s any consolation, my organization is in the exact same boat as yours. Luckily for me, as the big E-learning expert AND the big (supposedly) Flash expert in my enterprise, we are on the verge of migrating to Flash 9 player… because I said so. It’s a nice place to be, but in the meantime, being stuck to Flash 7 sucks hardcore.
On another note, with me being the author or a contributor on three of the four articles you mentioned — thanks for making me feel like an even bigger nerd. 🙂
Nice work Philip. Well written entry. It was a joy to read. You summarized the awkward space that exists when trying to develop a solution that reconciles the limitations of different flash player versions – operating systems – and browsers. It was interesting as an aside to read about Brad’s ExternalInterface accelerator code, and wonder if the performance boost is necessary when sending small strings back and forth with SCORM?
Thanks for your good blog .
I like your Captivate and Scorm articles .
Comments are closed.