Architecture

Overview The app is a Flutter application targeting mobile (Android/iOS) and desktop/web, structured using a layered approach:

Presentation Layer: Flutter UI, screens and widgets under lib/presentation. Uses Riverpod for state management.
Domain Layer: Business models, repository interfaces, and data-source contracts under lib/domain.
Data Layer: Concrete implementations of repositories and networking under lib/data and lib/core.

Key Principles - Separation of concerns across layers - Unidirectional data flow (providers expose async data → UI observes) - Testable repositories and data sources

Layers and Responsibilities 1) Presentation (lib/presentation) - Screens: dashboard, components, DigiKey components, scanner, settings - Providers: expose domain data via Riverpod - Widgets: dialogs and small composables

2) Domain (lib/domain) - Models: component, category, enums - Repositories: abstract interfaces (ComponentRepository) - Data sources: contracts for remote/local sources

3) Data (lib/data) - Repository implementations: ComponentRepositoryImpl - Network: Dio service wrappers, token managers (DigiKey) - Persistence: local cache or DB (if applicable)

Cross-Cutting - core/constants and core/utils for shared config (e.g., dio_service, digikey_token_manager) - assets for fonts, images, and certificates

Navigation - MobileScafold holds bottom navigation, builds current tab on demand. - Each tab is a dedicated page with its own logic.

Error Handling - Providers expose AsyncValue; UI renders loading/error states accordingly. - Network errors surface in provider .when(error: …) branches.

Performance - Providers memoize results; explicit invalidation after mutations (adding/editing) keeps UI fresh without redundant calls.