2010-01-29 1335 views
5

Estoy desarrollando un LMS compatible con SCORM y tengo algunos problemas con los contenidos generados de Captivate.Captivate - LMS - Problemas de comunicación SCORM

Básicamente, el comportamiento es: Si ve un SCO (capturar contenido generado) con por ejemplo 15 diapositivas y 1 pregunta en cada diapositiva rápidamente, mi lms no sigue todas las 15 preguntas, solo las 3 primeras o 4. Si esperas mucho tiempo al final, o si tomas el contenido lento, funciona bien.

Después de una gran cantidad de búsquedas de Google, y la depuración y el seguimiento, por último, me encontré con dos cuestiones principales:

1) Captivate - API SCORM comunicación es asíncrona (es la misma que la memoria flash - Javascript comunicación). Entonces, cuando el usuario ve el contenido rápidamente, las llamadas a la función se vuelven cada vez más desaleadas, y al final, tal vez el usuario responda la pregunta 15, y el contenido envíe información de la pregunta 4. No puedo cambiar la interfaz Flash o JS-Flash, porque esto es proporcionado por Captivate.

¿Hay alguna manera de hacer esta sincronización? Quiero decir, ¿obligar al flash a esperar de alguna manera?

2) Las funciones tardan más cada vez que se llaman, por ejemplo, setValue tarda 7 milisegundos la primera vez y 200 la última vez que se llama.

Para comprender este problema, aquí hay un pequeño trasfondo: Cautivar contenidos (todos los contenidos realmente pero más cautivar) llama a una función específica muchas veces, la función SetValue, una de las funciones de la API SCORM. Esta función toma dos parámetros (fieldName, value) firstone es el nombre del campo que se va a establecer, y el segundo el nuevo valor. En mi implementación, esta función primero valida el valor usando una expresión regular, y luego establece el valor en un objeto.

Ok, puedo agregar mucha más información, pero no sé qué es realmente importante, no espero que arregles mi código sin verlo, pero estoy sin ideas, y necesito nuevas opiniones , las ideas, las direcciones .... tal que sombody hacer la pregunta correcta ... ayuda :)

Gracias

Respuesta

0

Algunas Opciones:

se podría cambiar la forma en que está haciendo las preguntas. En lugar de 1 por cuadro, coloque todas las preguntas en 1 marco.

De lo contrario, tendrá que hacer algo de magia JavaScript en su SCORM Player JavaScript. Comenzaría minimizando el código JS con una herramienta como JSMin.

Luego intente almacenar en caché los archivos JS para que solo se carguen una vez. Sospecho que los archivos se llaman una y otra vez con cada fotograma.

+0

Acerca de "Puede cambiar la forma en que hace las preguntas. En lugar de 1 por cuadro, coloque todas las preguntas en 1 marco". No es una opción, solo tengo control sobre el código LMS, otras personas (clientes) haciendo el contenido de SCO. Sí, en realidad tengo algo de magia JS, pero mi solución es compleja y dependiente del navegador, y depende de la versión flash ... Necesito un mejor enfoque. (Estoy ocultando el flash mientras la comunicación scorm está teniendo lugar con un gif transparente y un cursor en espera). Archivos de caché js, sí, se almacenan en caché, pero no lo suficiente. Gracias – Javier

0

"¿Hay una manera de hacer esta sincronización? Quiero decir, ¿obligar al flash a esperar de alguna manera?"

Al parecer, el problema es éste: "Captivate es el único SCO que llama a funciones SCORM de JavaScript asíncrona Firefox es el único navegador que no obliga a las comunicaciones sincrónicas entre la OCS y el código JavaScript de apoyo Cuando un Captivate SCO,.. ejecutando en Firefox, envía una actualización de estado a una de las funciones de JS, Captivate no espera una respuesta de éxito o falla antes de enviar la siguiente actualización de estado. Como Captivate es bastante detallado en sus comunicaciones y JavaScript no es multiproceso, las presentaciones de estado de prueba pueden apilar y sobreescribir unos a otros. Esto puede causar una pérdida de datos, especialmente para pruebas más largas.]

Si desea ver el problema asincrónico con cualquier otro LMS, realice una prueba larga de Captivate usando Firefox y responda las preguntas muy rápidamente. Algunas de las preguntas cercanos al final va a quedar afuera .. "(foro interzoic.com)

Y tal vez un solution: " El tema lento se resuelve cuando fuerzo al g_intAPIType a 0 (en el archivo .htm ) , por lo que fuerza a Captivate a comunicarse como si estuviera en IE. "

+0

Buena idea, pero ... no funcionó. Gracias. – Javier

7

Al publicar para SCORM, Captivate no usa métodos de comunicación síncrona. * Dependiendo del navegador, Captivate usa FSCommand o el método getURL de la vieja escuela para comunicarse con el archivo HTML; el archivo HTML luego usa JavaScript para retransmitir los datos al LMS a través de la API SCORM.

La respuesta (si existe) se transmite desde JavaScript a FSCommand o a un SWF proxy (para getURL), que luego se supervisa internamente en Captivate a través de una función de devolución de llamada. Esta función de devolución de llamada utiliza temporizadores, y es probable que allí se encuentre tu problema.

Si configura g_intAPIType en 0, está forzando al navegador a usar FSCommand, que no es compatible con todos los navegadores y sistemas operativos. Establecer g_intAPIType en 1 significa que está forzando al navegador a usar getURL, que tiene varios navegadores pero tiene algunos inconvenientes (incluidos muchos sonidos de clic).

En ambos casos, los datos se envían a través de una secuencia de comandos de cola interna, que utiliza la función de devolución de llamada waitForResponse.

Los problemas de rendimiento que encuentra probablemente se deban a la puesta en cola, y la comunicación asíncrona agrava el problema debido a los temporizadores conectados a waitForResponse. Cambiar g_intAPIType probablemente solo tenga un efecto menor en sus problemas de rendimiento, aunque usar getURL (g_intAPIType=1) puede ayudar a mejorar la coherencia entre el navegador y el navegador.

Independientemente de la configuración g_intAPIType, no puede evitar que el mecanismo de seguimiento interno use la función asíncrona waitForResponse, por lo que no hay forma de evitar que Captivate use temporizadores al obtener/configurar datos; durante un período de tiempo probablemente comenzará a notar retrasos cada vez más largos como los que describió, especialmente. si estás haciendo muchas llamadas al LMS.

(* Pequeña excepción: He sido informado de que Captivate 4 y 5 usan ExternalInterface si el proyecto está construido en AS3 y está publicado para SCORM 2004, pero parece que aún se usan los temporizadores de cola y waitForResponse, básicamente tratando ExternalInterface como los métodos asíncronos enumerados anteriormente.)

+3

actualización para aquellos que estén interesados: Captivate 6 tiene una base de código SCORM completamente reescrito, suministrada por Rustici Software (scorm.com). Captivate 6 no debe exhibir ninguno de los problemas descritos en esta pregunta. – pipwerks

0

En cautivar, al publicar un scorm, verá la opción "Enviar datos de seguimiento al final", Utilice esta opción para resolver su problema.