MDBriefcase
A Flutter LMS ecosystem where one codebase powers seven apps across three medical-education businesses, with Moodle-backed SCORM learning that feels native on Android and iOS.
MDBriefcase (via Sazim Tech)
Remote · Production LMS
Software Engineer · Full-lifecycle Flutter delivery
Sazim Tech · Jul 2025 to Present
Cross-Platform Flutter Engine
Private / enterprise distribution
One Flutter codebase · 7 apps · 3 businesses · Moodle + WordPress backends
MDBC, RXBC, and BMA brands from one Flutter engine
JS↔Dart bridge so Moodle packages run like native web
Two Moodle LMS systems and three WordPress CMS instances
Preview → enroll → SCORM → quizzes → progress → credits
Executive Summary
MDBriefcase is a continuing medical education platform for physicians and allied professionals. Learners explore accredited courses, take SCORM-packaged modules published from Moodle, complete surveys and assessments, track progress toward credits, and manage engagement across events and related content, all inside branded Flutter apps.
The hardest engineering problem was not “another LMS UI.” SCORM packages are built for JavaScript runtimes on the web. Flutter is Dart. Moodle publishes course content as SCORM packages that expect a browser-style API surface. I built the bridge layer (WebView plus JavaScript channels with an explicit Dart API) so those packages get the same entry points they would on web, while course progress, quiz scores, and completion sync back into Moodle and the app’s progress UI on Android and iOS without failure.
Around that core, the same codebase delivers course explore/preview, enrollment, curriculum management, surveys, PDF and mixed content types, per-device SCORM download/storage controls, and analytics integrations including Salesforce-linked analytics and profile-related management.
The Challenge
The Challenge: Running Web-Native SCORM Inside a Dart Mobile Runtime
Few mobile engineers ever have to make Moodle SCORM packages behave correctly inside Flutter. The packages assume a JavaScript host. Without a faithful API layer, playback, completion tracking, and progress reporting break, and CME learners lose trust in credits and completion status.
SCORM Expects JavaScript; Flutter Speaks Dart
Moodle publishes SCORM form packages designed for browser JS. On mobile, those packages need the same channel surface a web host would provide (created manually in Flutter via JS↔Dart bridges), or the learning experience diverges from web.
Progress Must Match Moodle Truth
Track completion, quiz attempts, scores, and overall course progress had to round-trip through the bridge into Moodle completion state, then surface as accurate progress bars and status across the app.
Multi-Brand, Multi-Backend Complexity
One codebase powers seven apps across three businesses, talking to multiple Moodle LMS instances and WordPress CMS backends, without forking the learning engine per brand.
SCORM Downloads & Device Storage
Packages must download once per device, remain available offline for that install, reset if the user changes devices, and let learners manage how much storage they keep or clean up.
Project Scope
Engineering Objectives & Delivery Scope
- Integrate Moodle-published SCORM packages in Flutter via WebView and JavaScript channels with a hand-built API layer matching web entry points.
- Sync module completion, quiz scores, and course progress with Moodle and render trustworthy progress UI on Android and iOS.
- Support course preview, explore, enrollment, curriculum taking, and mixed content (SCORM, surveys, PDFs, and related materials).
- Ship events and survey management within the same product surface.
- Implement per-device SCORM download caching with shared download state and user-controlled storage cleanup.
- Maintain one Flutter codebase across seven branded apps (MDBC / RXBC / BMA) against multiple Moodle and WordPress backends.
- Integrate Salesforce-linked analytics and profile-related management for engagement visibility.
Engineering Foundation
Architecture & Technical Design
Feature-based GetX architecture with repositories, typed DTOs, and domain entities. The SCORM runtime sits behind a unified interface with platform-specific WebView/JS bridge implementations for Android and iOS, talking to Moodle APIs for enrollment, tracking, and completion.
JS↔Dart SCORM Bridge
Manually implemented the API functions SCORM packages expect from a web host, exposed through JavaScript channels so Moodle form entry points connect cleanly into Flutter.
Unified Interface, Dual Native Hosts
Separate Android and iOS WebView bridge implementations behind one Dart interface: same learner UX, platform-correct hosting.
Progress & Completion Pipeline
Track-level events (module complete, quiz score, survey view) flow through the bridge into Moodle completion records and back into app progress bars and status chips.
Multi-Backend Feature Modules
Repositories target Moodle LMS and WordPress CMS instances per brand configuration, keeping enrollment, content, events, and surveys modular.
One Flutter codebase
Feature-based · GetX
MDBC
RXBC
BMA
3× WordPress
CMS
2× Moodle
SCORM · JS↔Dart
Screen Walkthrough
The product, in the order a user moves
Production screens from the live apps, framed as a journey rather than a pile of captures. Follow them from the first screen to the last action.
Follow the journey →
Deep Dive
Key Technical Implementations
Detailed breakdown of core features addressing complex mobile engineering requirements.
SCORM in Flutter via JavaScript Channels
The rare Dart↔JS host problem most mobile engineers never face
SCORM is a JavaScript-era standard. Moodle publishes packages that expect browser-style APIs. I built the missing host: WebView plus JavaScript channels and a hand-authored API layer so form entry points connect the way they would on web. Android and iOS each have correct native bridge implementations behind one Dart interface, and clients got on-spot views on both platforms without failure.
- Manual API surface matching what a web SCORM host would expose automatically
- Moodle form packages launch and communicate through JS channels into Dart
- Parity-focused playback so Android and iOS match the intended web learning experience
Moodle Completion & Progress Tracking
Tracks, quizzes, scores, and completion status learners can trust
The same bridge powers progress. We record which tracks the learner completed, quiz attempts and scores, and Moodle completion status, then surface that as progress bars and status throughout enrolled courses and course detail screens.
- Per-track completion events synced with Moodle
- Quiz and assessment scores stored and reflected in course status
- Progress percentages and bars driven by real completion data, not UI guesses
Per-Device SCORM Download & Storage Control
Download once on a device; reset when the device changes
SCORM packages download for a single device install. Shared download state avoids repeat fetches on that device. If the learner switches devices, setup resets. Users can see storage impact and clean up packages they no longer need.
- One-time download per device with shared downloaded state
- Device change resets local SCORM setup as designed
- Learner-controlled storage cleanup for downloaded packages
Course Preview, Explore & Curriculum
From discovery to Take This Course to module-level work
Learners browse and preview CME/CPD programs (credits, duration, accreditation), enroll, then work through curriculum items (SCORM modules, pre-tests, surveys, and related activities) with clear “how to complete” guidance.
- Course explore and preview with CME metadata
- Curriculum lists mixing SCORM, surveys, and assessments
- Enrollment and take-course CTAs wired into the Moodle-backed flow
Surveys, PDFs & Mixed Course Content
Not only SCORM: full course content scope inside Flutter
Beyond packages, the apps integrate survey forms, PDF content, and other course-related materials so a single curriculum can mix interactive SCORM with supporting documents and feedback instruments.
- Survey forms as first-class curriculum activities
- PDF and supporting course materials in-scope
- Consistent completion rules across content kinds
Events & Survey Management
Engagement beyond the individual course player
The product surface also covers events and survey management so CME programs can run live/scheduled engagement alongside self-paced SCORM learning, within the same Flutter ecosystem.
- Events as part of the learner journey
- Survey management alongside course taking
- Shared architecture with enrollment and progress modules
Seven Apps, Three Businesses, Multi-Backend
One Flutter engine across MDBC, RXBC, and BMA
A single codebase powers seven production apps across three businesses, integrating multiple Moodle LMS systems and WordPress CMS instances. Feature-based GetX modules with repositories and typed DTOs keep brand and backend differences configurable instead of forked.
- 7 apps / 3 businesses from one Flutter codebase
- 2 Moodle LMS + 3 WordPress CMS integrations
- GetX feature modules with repositories, DTOs, and domain entities
Salesforce Analytics & Profile Management
Engagement visibility and learner profile surfaces
Salesforce was integrated for the analytics side of engagement, alongside Google Analytics instrumentation and profile-related management so learning activity and learner identity stay connected for the business.
- Salesforce-linked analytics for engagement insight
- Google Analytics instrumentation in the mobile clients
- Profile-related management within the LMS apps
Hurdles & Solutions
Technical Challenges & Trade-Offs
Real production obstacles overcome during engineering and deployment.
Hosting SCORM (JS) packages inside Flutter (Dart) without breaking Moodle contracts
Built a WebView + JavaScript-channel host with an explicit Dart API layer that recreates the entry points a browser would provide, with separate Android/iOS implementations behind one interface.
Learners get web-parity SCORM experiences on both stores; clients validated views as on-spot without platform failure.
Keeping progress, quizzes, and completion truthful across bridge and Moodle
Routed track completion and assessment events through the same bridge into Moodle completion APIs, then rebound results into progress UI.
Progress bars and status chips reflect real completion, which is critical for CME credit trust.
SCORM package size vs. repeat downloads on mobile
Per-device download cache with shared downloaded state, reset on device change, and user-facing storage cleanup.
Packages download once per install; learners control storage without ops intervention.
One codebase across seven branded apps and multiple backends
Feature-based GetX architecture with repositories targeting Moodle/WordPress per brand configuration instead of app forks.
Shared learning engine improvements land across MDBC, RXBC, and BMA together.
Outcomes
Impact & Production Outcomes
MDBriefcase proves a hard systems problem: make JavaScript-era SCORM feel native in Flutter while staying honest to Moodle. The bridge, progress pipeline, download cache, and multi-brand architecture turned that constraint into a production CME ecosystem clients were genuinely happy with, and we will layer in additional screenshots for events, surveys, storage management, and analytics as they become available.
Shared Flutter delivery across three medical-education businesses
Moodle packages run with web-like API entry points inside Flutter
Client-validated on-spot views without platform-specific failure
Completion, quizzes, and progress bars tied to Moodle truth
Technology Breakdown
Tools, Frameworks & Libraries
Categorized technical stack employed to achieve reliability, performance, and store compliance.