scorm-again

The Activity Tree defines the structure and behavior of a course. Each node in the tree represents an activity and contains configuration for sequencing, controls, and rollup rules.

Key properties for each activity node include:

• id: Unique activity identifier.
• title: Display name.
• isVisible: Whether the activity appears in navigation.
• isActive: Whether the activity is currently active.
• isSuspended: Whether the activity is currently suspended.
• attemptLimit: Maximum allowed attempts (null for unlimited).
• children: An array of nested activity objects.
• sequencingRules, sequencingControls, rollupRules: Configuration objects defining how the activity behaves within the course flow.

{
  id: "root",
  title: "Course Title",
  isVisible: true,
  isActive: false,
  isSuspended: false,
  attemptLimit: null,
  children: [
    {
      id: "module-1",
      title: "Module 1",
      children: [...],
      sequencingRules: {...},
      sequencingControls: {...},
      rollupRules: {...},
      objectives: [...]
    }
  ],
  sequencingControls: {...},
  sequencingRules: {...},
  rollupRules: {...}
}

scorm-again provides several advanced features for SCORM implementations:

• SCORM 2004 Sequencing: Full support for navigation requests (start, continue, previous, choice, jump, exit, suspend, etc.), activity tree management, sequencing rules (pre-condition, post-condition, exit), and rollup rules.
• Cross-Frame Communication: Allows running SCORM content in sandboxed iframes while communicating with the SCORM API in the parent frame. This supports cross-origin iframes and provides synchronous API behavior with asynchronous cache updates.
• Offline Support: Automatically stores and synchronizes SCORM data when connectivity is lost, making it suitable for mobile and remote learning.
• Synchronous Commits: Implements blocking commits that return actual LMS success/failure responses to prevent data loss.
• Event System: Provides listeners to track all API interactions for monitoring or custom UI.
• Multiple Data Formats: Supports JSON, flattened, and parameter-based data commit formats.

When the device regains connectivity, the OfflineStorageService.sync() process is triggered. The lifecycle follows these steps:

1. Detection: NetInfo detects an online status and dispatches a scorm-again:network-status event with { online: true }.
2. Initialization: OfflineStorageService.sync() is called, emitting an OfflineDataSyncing event. The WebView receives a postMessage({ type: 'sync', status: 'start' }) to update the UI (e.g., setting isSyncing to true).
3. Execution: The service retrieves queued commits from localStorage and attempts to send HTTP requests to the LMS.
4. Resolution:
   • On Success: localStorage is cleared, and an OfflineDataSynced event is emitted. The WebView receives postMessage({ type: 'sync', status: 'success' }) to update the UI and notify the user.
   • On Error: Data is retained in localStorage, and an OfflineDataSyncFailed event is emitted. The WebView receives postMessage({ type: 'sync', status: 'error' }) to notify the user. The system will retry later.

### Offline Data Sync (Coming Back Online)

NetInfo detects online │ └─► Dispatch 'scorm-again:network-status' { online: true } │ └─► OfflineStorageService.sync() │ ├─► Emit 'OfflineDataSyncing' event │ │ │ └─► postMessage({ type: 'sync', status: 'start' }) │ └─► setIsSyncing(true) │ ├─► Retrieve queued commits from localStorage ├─► Send HTTP requests to LMS │ ├─► On success: │ ├─► Clear localStorage │ ├─► Emit 'OfflineDataSynced' event │ │ │ │ │ └─► postMessage({ type: 'sync', status: 'success' }) │ │ ├─► setIsSyncing(false) │ │ └─► Alert.alert('Sync Complete') │ └─► Return success │ └─► On error: ├─► Keep data in localStorage ├─► Emit 'OfflineDataSyncFailed' event │ │ │ └─► postMessage({ type: 'sync', status: 'error' }) │ ├─► setIsSyncing(false) │ └─► Alert.alert('Sync Failed') └─► Retry later

A SCORM player wrapper is a UI layer that orchestrates the relationship between the SCO content and the LMS backend.

Core Components

• Content Frame: An iframe where the SCO runs.
• Navigation Controls: Buttons for prev, next, and exit.
• Course Menu: A Table of Contents (TOC) that displays SCO status indicators.
• Progress Display: Visual indicators for completion percentage and scores.

Data and Event Flow

1. API Calls: The SCO (inside the iframe) calls methods like LMSSetValue on the window.API object.
2. Event Emission: scorm-again intercepts these calls and fires events (e.g., LMSSetValue).
3. UI Update: The Player Wrapper listens for these events via api.on() and updates the UI state (Menu, Progress Bar, Navigation) and persists data to the backend or localStorage.
4. Backend Sync: The SCORM API handles the HTTP communication to the LMS backend.