webaddicted/e-commerce-disinfectant

1. This is a Flutter client application named E-Commerce-Disinfectant. The same Dart codebase targets Android, iOS, and Web, while the android/, ios/, and web/ folders are the platform shells and launch/configuration wrappers around the shared Flutter app.

2. The app entry point is lib/main.dart, with startup wiring likely handled through lib/utils/common/initial_binding.dart and the route constants in lib/utils/constant/routers_const.dart / routes_page.dart. The overall flow appears to start with splash/onboarding, then move into login, then the main home experience.

3. The presentation layer is organized by feature under lib/view/. Each major screen has its own page file: splash, login, home, order, details, profile/setting, notification, wallet, survey, complaint, and list. This makes the app mostly feature-driven rather than layered by UI type alone.

4. Reusable UI pieces live in lib/view/widget/ and are shared across feature screens. These include list/grid tiles, category chips, banner cards, rating display, and carousel dots, which suggests the home and catalog areas are built from composable product and category widgets.

5. Application state and screen logic are separated into lib/controller/. There are controllers for home, login, and a shared base_controller, which strongly suggests a controller-based state management pattern where pages render UI and controllers manage data loading, user actions, and navigation side effects.

6. Data access is split into a small repository layer in lib/data/repo/. base_repo.dart, home_repo.dart, and login_repo.dart isolate data-fetching and persistence operations from UI code. This is the main boundary between screen logic and underlying data sources.

7. The data models under lib/data/common/ represent the app’s core entities: user_info, category_bean, and task_item. These are likely the objects passed between repositories, controllers, and widgets for login state, catalog/category presentation, and task/order-style list content.

8. Networking and remote integration are centralized in lib/utils/apiutils/, with api_base_helper.dart and api_response.dart. The presence of a DIO-based helper in the README means the app is prepared for API-backed flows, even though the repo also contains substantial UI/demo content and dummy data.

9. Local persistence is handled through lib/utils/sp/ using shared preferences helpers and a manager/service split. This is where app-level state such as login/session data, onboarding flags, or cached preferences would be stored and read across launches.

10. Shared cross-cutting utilities sit in lib/utils/common/, including validation, widget helpers, and global utilities. Together with lib/utils/theme/ and the constant files in lib/utils/constant/, this forms the app’s design and behavior layer: colors, strings, assets, routes, preference keys, and dummy content.

11. The app appears to be a retail/catalog experience with multiple user journeys: browsing categories, viewing details, cart/order flow, address entry, profile settings, notifications, wallet, surveys, and complaints. The README screenshots match that structure, so a diagram should show a central commerce/navigation hub branching into those feature modules.

12. Assets are bundled locally under assets/fonts and assets/images, and the UI depends on them for branding and product imagery. There is also a prebuilt apk/app.apk artifact in the repo, indicating the project is distributed with a packaged Android build in addition to source.

13. The repository includes CI/testing scaffolding: .github/workflows/dart.yml for Dart/Flutter automation and test/widget_test.dart for basic widget coverage. The native Android/iOS projects are standard Flutter host projects, mostly infrastructure rather than business-logic owners.