aaron.silvers at gmail.com
Sun Apr 30 08:28:51 EDT 2006
All good questions. My responses are in-line
> So I understand that it's better to leave my 'flash player' as one. But
> won't my 'flash player' (which can contain hundreds of exercises) be
> threated as one item by the LMS?
It will be treated as one SCO by the LMS. That SCO will have hundreds of
files listed in its resource inside your imsmanifest.xml
> Or is it possible to pass to the LMS a score for each exercise in my
> 'flash player'. The scorm-manifest will have one item, but my manifest will
> have hundreds of items.
You can only record one "cmi.score" per SCO, but each SCO can have hundreds
upon hundreds of interactions (check out "interactions" in the RTE document
in Chapter 4: Run Time Data Model), and each interaction can have its own
score recorded by the LMS. This score isn't related on the LMS side to the
overall cmi.score of the whole of the content, but you as a developer can
tie the two together, just as you would to produce an overall score for the
content anyway. The difference is that you have a mechanism for recording a
score for each exercise, and that is in the cmi.interaction.
You can also tie each exercise to a cmi.objective, and each objective can
have its own cmi.objective.score. This is the method I would advise as
instructionally it makes more sense to tie activities to learning objectives
than recording each question of an exercise for its own merit.
> Secondly, what's the difference between
> http://www.adlnet.gov/downloads/201.cfm and Flash/JS Integration Kit?
Some very major differences. The Plug-In Technology Example from
ADLnet.orgwas created almost a full year before the Flash/JS
Integration Kit came out
and relies on ASBroadcaster and a series of callback functions in order to
easier on the communication side of things, we had better luck internalizing
Now this worked GREAT -- Alan was able to queue our SCORM calls and not rely
on FSCommand, which were my two main goals. But from a maintenance
standpoint, it's a pain... mostly because of internalizing the APIWrapper
inside of ActionScript. If I'm creating a content package with only this
Flash file -- sure, this is a fine solution. But if I were to create a
larger content package with other SCOs, and mix up the technologies -- now I
Two places where I have to maintain the same code -- it's sloppy. With the
Flash/JS Integration Kit, everything in my entire content package can use
the same methods in the same file. It's better coding. Plus... the
Flash/JS Integration Kit is actively maintained, which is more than anyone
can say for the SCORM2004Obj.as class. There is currently no Flash
developer on ADL or employed by CTC (who staffs the ADL Technology Center)
tasked to maintain this code.
> Thirdly, there's one thing I don't seem to understand. How does the
> how? If I deliver a SCORM-package, I can't know how another company calls
> it's API…
This will sound pretty silly, but if you look at that APIWrapper code, all
it's doing is searching the chain of parents for an instance of the API
object, and after 500 levels of searching (or some other silly arbitrary
number like that), if it does't find the API, it just fails. The good news
as you don't have to worry how another company calls the SCORM API. By
nature of the fact that an LMS passes the SCORM conformance test, it means
that they will provide an API that conforms to whatever version of SCORM
it's using (1.2 or 2004).
the things you really need to worry about are things that are very hard to
test for. Cross Domain scripting issues are a huge pain in the butt for me
(and I'd like to think I know quite a bit about SCORM development).
Aaron E. Silvers
aaron.silvers at gmail.com
"Whoso would be a man must be a nonconformist." - Ralph Waldo Emerson
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osflash