md-khadimul-islam/brandtech_shop

1. Overall shape

- This is a cross-platform Flutter client app, with one shared Dart codebase under lib/ and standard platform runner shells for Android, iOS, web, macOS, Windows, and Linux.

- The architecture is explicitly layered around core and features, following a clean-architecture style.

2. App bootstrap and shell

- lib/main.dart is the entry point that wires the app together.

- The app shell likely sets up global providers, theme state, routing, and shared services before rendering feature screens.

3. Core subsystem

- lib/core/ holds app-wide infrastructure that is reused by all features:

- constants/ for strings and app constants

- errors/ for shared exception/failure types

- network/ for Dio HTTP and connectivity checking

- router/ for global GoRouter configuration

- services/ for shared UI services like snackbars

- theme/ for light/dark theme definitions and theme state

- This is the main boundary separating reusable platform/app concerns from feature logic.

4. Navigation boundary

- Routing is centralized in lib/core/router/app_router.dart.

- Screens are navigated through go_router, with custom transitions mentioned in the README.

- The routed destinations are the feature screens, mainly home, product details, and favorites.

5. Products feature: end-to-end data flow

- The products module is the primary online data path:

- data/datasources/product_remote_datasource.dart calls the public FakeStore API through Dio

- data/models/product_model.dart maps JSON into app data objects

- data/repositories/product_repository_impl.dart bridges data access to domain

- domain/usecases/get_products_usecase.dart exposes the product-fetching operation

- presentation/providers/products_provider.dart drives UI state

- presentation/screens/home_screen.dart and product_details_screen.dart render the result

- This is the main request/response pipeline in the app.

6. Products UI composition

- The product UI is split into reusable widgets:

- product cards

- shimmer loading placeholders

- error-state views

- The home screen includes product grid browsing, search/filter behavior, and pull-to-refresh.

- The details screen shows a product’s full information and supports favorite toggling.

7. Favorites feature: local persistence flow

- Favorites are stored locally and do not depend on the remote API at runtime.

- The flow is:

- data/datasources/favorites_local_datasource.dart uses Hive

- data/repositories/favorites_repository_impl.dart abstracts persistence operations

- presentation/providers/favorites_provider.dart manages favorite state

- presentation/screens/favorite_screen.dart shows the saved items

- This subsystem is the main offline/stateful boundary in the app.

8. State management model

- The app uses Riverpod throughout, with generated provider files under *.g.dart.

- Providers act as the bridge between UI and repositories/use cases, keeping widgets mostly declarative.

- The codegen indicates riverpod_annotation/build_runner are part of the architecture, not just tooling.

9. Data, errors, and offline behavior

- lib/core/network/connectivity_checker.dart is used to distinguish connectivity problems from other failures.

- Shared failure/exception classes in core/errors/ flow upward into UI error states, including retry actions.

- This separation means the UI can present specific “no internet” and “server error” experiences rather than generic failures.

10. Theme and app preferences

- Theme is treated as application-wide state through core/theme/theme_provider.dart.

- The README indicates dark mode preference is persisted in Hive, so the theme subsystem has both UI and local-storage responsibilities.

- This is another cross-feature state boundary similar to favorites, but global rather than domain-specific.

11. Shared UX services

- Snackbar behavior is centralized in core/services/snackbar_service.dart, which suggests transient messaging is handled outside individual screens.

- Extensions and string helpers in core/extensions/ provide small shared presentation utilities.

12. External dependencies that matter architecturally

- FakeStore API is the only remote backend; there is no custom server in this repo.

- Hive provides local persistence for favorites and theme preference.

- Dio handles HTTP.

- connectivity_plus informs network-aware error handling.

- cached_network_image, shimmer, and flutter_rating_bar support key product-listing UI behaviors.

13. Platform layer

- The native Android/iOS/macos/windows/linux/web directories are mostly standard Flutter runners and build scaffolding.

- There is no sign of heavy native business logic; the architecture is overwhelmingly shared-Dart with minimal platform-specific code.

14. Diagram takeaway

- The cleanest architecture diagram would show:

- a single Flutter UI shell

- two main feature domains: Products and Favorites

- a shared Core layer underneath

- remote FakeStore API on the products side

- Hive local storage on the favorites/theme side

- Riverpod as the state bridge between repositories/use cases and screens.