v1shnuuu/rev

Purpose and entry points

Revive is a Flutter mobile CPR-coaching app designed to retain a deterministic offline rescue path while optionally using AI for triage and questions. Application startup and global configuration are centered in lib/main.dart, with native host entry points at android/app/src/main/kotlin/com/firstaid/cpr_coach/MainActivity.kt and ios/Runner/AppDelegate.swift.

Emergency journey and screen orchestration

The UI is organized as an emergency workflow: home entry, symptom triage, live CPR coaching, scripted guidance, and optional chat. Key route-level components are lib/screens/home_screen.dart, lib/screens/triage_screen.dart, and lib/screens/live_cpr_screen.dart; supporting guidance and AI interaction live in lib/screens/step_guide_screen.dart and lib/screens/chat_screen.dart. The life-saving path should resolve to static CPR guidance when AI is unavailable or uncertain.

Deterministic CPR core

Motion sensing is isolated from the UI in lib/services/motion_service.dart. It consumes the device accelerometer stream, detects/debounces compression peaks, derives BPM, and classifies rhythm against the target range. Static medical flow and fallback content are data-driven in lib/constants/cpr_steps.dart and lib/constants/emergency_protocols.dart, ensuring rate feedback and CPR instructions do not depend on network or model output.

Feedback, voice, and live presentation

lib/services/audio_service.dart supplies metronome/audio feedback, while lib/services/tts_service.dart and lib/services/stt_service.dart provide on-device spoken instruction and hands-free recognition. The live screen binds these service outputs to CPR-focused visual components such as lib/widgets/components/revive_bpm_gauge.dart, lib/widgets/compression_animation.dart, and lib/widgets/cpr_instruction_animation.dart. Voice recognition can support emergency-keyword actions and conversational input, but should not block the compression loop.

Optional AI boundary

lib/services/ollama_service.dart is the explicit boundary to Gemma via Ollama and an ngrok-accessible host. It supports natural-language triage and Q&A, not sensor interpretation or clinical timing. Connectivity/TLS setup is coupled to startup in lib/main.dart, while operational settings are centralized in lib/constants/app_config.dart. Failures at this boundary must degrade to static protocol guidance rather than stall emergency UI.

Health and platform integration

After a session, lib/services/health_connect_service.dart records incident information through Android Health Connect. This is best-effort: permissions, unsupported devices, or unavailable Health Connect must not interrupt active coaching. Android packaging and manifest capabilities reside under android/app/src/main/AndroidManifest.xml; iOS is present as a Flutter target but Health Connect is Android-specific.

Design and delivery boundaries

A tokenized Flutter design system defines colors, typography, spacing, motion, haptics, and component primitives in lib/theme/app_theme.dart, lib/theme/app_haptics.dart, and lib/widgets/components/revive_card.dart. Runtime targets include Android, iOS, and web (web/index.html), though accelerometer and Health Connect behavior requires physical Android hardware. Dependencies/assets are declared in pubspec.yaml; CI runs through .github/workflows/flutter-ci.yml.