pharshilladila/typing-speed-master

1. This is a Flutter cross-platform app, but the primary product is a web typing trainer/analytics app. The repo also contains Android scaffolding, so the same codebase can be packaged for mobile, though the architecture is centered on Flutter web deployment.

2. The app is organized around a feature-first layout under lib/features, with shared UI and utilities in lib/widgets, lib/helper, lib/utils, and lib/models. Each major screen owns its own model/provider/widget subfolders, which makes the architecture mostly modular by feature rather than by technical layer.

3. The root entry point is lib/main.dart, which likely wires together global services, providers, theming, and routing before handing off to app_entry_point.dart. The app-wide composition is managed through lib/providers/app_providers.dart, auth_provider.dart, router_provider.dart, test_goal_provider.dart, and theme/provider/theme_provider.dart.

4. Navigation is centralized in lib/routes/app_router.dart. The named screens in the tree suggest a route map that spans the typing test flow, results flow, dashboard, history, profile/settings, certificates, and game modes.

5. The core product flow is the typing test pipeline: typing_test_screen.dart collects keystrokes and timing, typing_test_provider.dart computes live metrics, and results_screen.dart presents the completed session. Supporting widgets like text_display_widget.dart and character_analysis_widget.dart indicate character-level feedback and real-time correctness tracking.

6. Persistent analytics are modeled separately from the live test UI. Shared domain objects such as typing_test_result_model.dart, typing_stat_data.dart, user_model.dart, and test_goal_model.dart feed the dashboard, history, and profile statistics views. The dashboard screens use chart widgets to visualize trend data rather than recomputing metrics in the UI.

7. The app has a distinct analytics/dashboard subsystem under lib/features/dashboard and lib/features/history. These screens consume aggregated result data to show WPM, accuracy, performance by difficulty, radar-style summaries, and historical lists, with reusable cards/shimmer/loading states in shared widgets.

8. Authentication and user state are a separate concern from the typing engine. The README and auth_provider.dart indicate Google sign-in and guest usage, with Supabase as the persistence backend for saved results and user data. Profile screens and providers build on that authenticated user context to show stats, preferences, and account management.

9. There is a game subsystem under lib/features/games that extends the typing experience into alternative mini-games: character rush, word master, and word reflex. A game_dashboard_provider.dart and common game widgets suggest these are coordinated under a shared game dashboard but remain isolated from the main test flow.

10. Certificates are treated as a specialized output path rather than a core test flow. The certificate feature has its own model, provider, and custom painter, which implies it generates shareable or printable certificates from achieved test results.

11. The profile area bundles non-core but user-facing configuration and legal content: login/register states, theme and notification preferences, activity summaries, update/details widgets, and privacy/terms pages. This area acts as the account/settings boundary for personalization and compliance.

12. Shared UI primitives are heavily reused across features: custom app bars, drawers, dropdowns, dialogs, toast messages, result cards, responsive layout helpers, and background decorations. This indicates the app’s visual consistency is enforced through a component library in lib/widgets, not duplicated inside screens.

13. The repository also includes deployment/runtime artifacts that matter architecturally: web/manifest.json, web/firebase-messaging-sw.js, and web/ads.txt for web delivery, plus android/app/google-services.json for Android-side Firebase configuration. vercel.json, railway.json, and nixpacks.toml show the app is prepared for multiple hosting/build targets, with the web build likely deployed externally.

14. In summary, the main architecture is: Flutter UI at the top, feature modules in the middle, shared providers/models beneath, and external services at the edge for auth, persistence, and deployment. The important boundaries to diagram are the typing-test runtime, analytics/history read models, account/profile state, game extensions, and the reusable app shell that ties them together.