ash469/school_management_app

Purpose and Runtime

A Flutter/Dart cross-platform school-management client for administrators, teachers, students, and parents. It delivers role-specific workflows for academic operations, communications, attendance, grades, fees, schedules, and forms. Primary application entry point: lib/main.dart. Native hosts support Android, iOS, Linux, macOS, Windows, and web; Android includes Firebase configuration at android/app/google-services.json.

Application Bootstrap and Navigation

lib/main.dart initializes the Flutter app, theme, and navigation. The user journey begins with school and role selection, then login, and routes into the appropriate dashboard:

• lib/screens/school_selection_screen.dart

• lib/screens/role_selection_screen.dart

• lib/screens/login_screen.dart

This is the main control boundary between unauthenticated selection/authentication and role-scoped application areas.

Role-Specific UI Domains

Screens are organized primarily by user role, making each role’s dashboard a composition root for its workflows:

• Administration: lib/screens/school_admin_dashboard.dart, lib/screens/school_admin/analytic_dashboard.dart, lib/screens/school_admin/student_management_screen.dart

• Teachers: lib/screens/teacher_dashboard.dart, lib/screens/teachers/teacher_attendance_screen.dart, lib/screens/teachers/teacher_grading_screen.dart

• Students: lib/screens/student_dashboard.dart, lib/screens/student/grades_screen.dart, lib/screens/student/forms_screen.dart

• Parents: lib/screens/parent_dashboard.dart, lib/screens/parents/attendance_screen.dart, lib/screens/parents/fee_management_screen.dart

Role separation is a UI/navigation organization boundary; shared underlying entities and services serve multiple roles.

Domain Model Layer

Typed Dart models represent the payloads exchanged between screens and services. Core shared entities include users, schools, classes, attendance-related academic records, assignments, forms, events, fees, messages, and notifications:

• lib/models/user_model.dart

• lib/models/class_model.dart

• lib/models/api_response.dart

These models isolate UI code from API response structure and define the common data vocabulary across role flows.

Service and Backend Boundary

The service layer contains API-facing and domain-specific operations. api_service.dart and api_auth_service.dart are the likely common transport/authentication boundary; feature services encapsulate operations for their domains:

• lib/services/api_service.dart

• lib/services/api_auth_service.dart

• lib/services/attendance_service.dart

• lib/services/assignment_service.dart

• lib/services/grading_service.dart

• lib/services/notification_service.dart

Typical flow is screen → feature service → API/auth service → remote backend → ApiResponse/domain model → screen rendering. Backend implementation is not present in this repository.

Notifications, Firebase, and Device Integration

Firebase is configured for Android and Flutter options are checked into the client. FCM-specific data and service code indicate a push-notification integration boundary; web includes a Firebase messaging service worker:

• lib/firebase_options.dart

• lib/services/fcm_service.dart

• lib/models/fcm_data.dart

• web/firebase-messaging-sw.js

Analytics and image handling are also isolated as services: lib/services/analytics_service.dart and lib/services/image_service.dart.

Shared Presentation and Local State

Reusable widgets, app-wide styling, constants, and storage utilities reduce duplication across role screens:

• lib/widgets/dashboard_card.dart

• lib/utils/app_theme.dart

• lib/utils/storage_util.dart

Local storage likely preserves session/user state across launches, while services own remote interactions. The declared Provider pattern is the intended state-management approach, although provider placement is not visible from the tree.