hariom317/vsafe-women-safety-app

1. Repository shape

- This is a Flutter cross-platform mobile app with generated platform shells for Android, iOS, web, Windows, macOS, and Linux.

- The actual product logic lives almost entirely under lib/; the native folders are thin launch/bridge layers.

2. App entry and shell

- lib/main.dart is the Dart entry point and likely decides the initial route and global app setup.

- Platform-specific runners (android/.../MainActivity.kt, ios/Runner/AppDelegate.swift, etc.) only host the Flutter runtime; they are not where the app’s domain logic lives.

3. Primary product boundary: safety app UI

- The UI is organized by feature area:

- intro_pages for splash/onboarding

- user for sign-up/login/profile recovery

- navbar_pages for the main post-login tabs

- required_pages for core safety flows

- widgets and components for reusable UI parts

- This gives the architecture a clear split between authentication/onboarding and the main safety dashboard.

4. Authentication and user lifecycle

- lib/src/user/ contains the account flow: welcome screen, login, registration, password reset, email/OTP verification, and profile update.

- This is the app’s front door and likely gates access to all safety and communication features.

- User identity is represented in lib/src/model/user_model.dart, suggesting the app stores a structured profile separate from UI.

5. Main navigation and feature hub

- lib/src/widgets/bottom_nav_bar.dart and lib/src/widgets/drawer_widgets/screen_drawer.dart indicate two major navigation surfaces:

- a bottom tab bar for primary workflows

- a drawer for secondary settings/help/legal screens

- navbar_pages/home_screen.dart, chat_screen.dart, fake_call_screen.dart, and profile_screen.dart suggest the core app is centered around these four main sections.

6. Safety operations subsystem

- The home experience is decomposed into focused widgets:

- emergency.dart for SOS actions

- nearby_map_service.dart for map/location-based assistance

- safety_tips.dart and situation.dart for guidance and contextual content

- custom_carousel.dart for surfaced content on the home page

- The feature set from the README—SOS, shake-trigger alerts, emergency contacts, and real-time location sharing—appears to live here.

7. Emergency and fake-call flows

- required_pages/fake_call.dart, incoming_fake_call.dart, and navbar_pages/fake_call_screen.dart model a dedicated de-escalation/escape flow.

- flutter_background_services.dart implies background execution is used for time-sensitive behaviors like shake detection or alerting while the app is not foregrounded.

- assets/audio/caller_tune.mp3 supports the fake-call experience with realistic ringing audio.

8. Chat and contact subsystem

- lib/src/chat/ contains the full one-to-one messaging stack: user cards, message cards, profile dialog, user chat screen, and profile viewing.

- lib/src/model/contact_model.dart and user_message.dart define the data boundary for contacts and chat messages.

- chat/apis.dart and db/db_services.dart suggest backend/persistence access is abstracted away from the UI, likely to Firebase or another cloud datastore as described in the README.

9. Persistence and lightweight local state

- db_services.dart and share_pref.dart indicate two storage layers:

- app/database services for structured records

- shared preferences for local flags or session-like state

- This likely supports remembered login state, onboarding completion, profile cache, and possibly selected settings.

10. Support content and informational surfaces

- The app includes non-transactional content flows for safety education and support:

- drawer_widgets/help_page.dart, privacy_policy_page.dart, terms_and_conditions.dart, feedback_page.dart, notification_page.dart, setting_page.dart

- required_pages/chatbot.dart for guided assistance

- These are important because the app is not only operational SOS tooling; it also provides guidance, policy, and support content.

11. Content-heavy asset pipeline

- The assets/ tree is a major part of the product: Lottie animations, intro imagery, safety-tip images, and safety-training videos.

- This indicates the app leans heavily on rich educational and onboarding media rather than plain text-only screens.

- The architecture therefore includes a presentation/content layer as a first-class subsystem.

12. Backend and platform integration boundaries

- The README states Firebase is used for backend services, and ios/Runner/GoogleService-Info.plist confirms Firebase configuration on iOS.

- The code layout suggests cloud-backed features for authentication, messaging, and possibly notifications/location services, while native code remains minimal.

- In a diagram, the key boundaries are: Flutter UI layer → app services/data layer → Firebase/backend services, with native runners acting only as platform hosts.