sezanhaque/kahf_flutter

1. Overall shape

This is a Flutter cross-platform app, with the actual application architecture living under lib/. The android/, ios/, web/, linux/, macos/, and windows/ directories are standard Flutter host shells rather than separate app logic.

2. Entry point and app bootstrap

lib/main.dart is the startup entry. The app appears to boot into a shared splash flow (lib/src/screens/splash_screen.dart) before moving into the main feature screens. The bootstrap likely wires dependency injection and global state before rendering feature UI.

3. Core foundation layer

lib/src/core/ holds cross-cutting infrastructure:

• result/error primitives in base/ (Failure, ResponseResult, Status, exceptions)

• app-wide constants in constants/

• network definitions in network/ (api_endpoints.dart, utf8_interceptor.dart)

• logging in logger/

• shared utilities and formatting extensions

• a global error_notifier provider for surfacing failures.

This layer is the main boundary for non-feature-specific behavior.

4. Dependency injection boundary

lib/src/core/di/ contains a code-generated DI setup split into externals, services, and repositories. This is where concrete implementations are assembled and exposed to the rest of the app, keeping feature code from constructing dependencies directly.

5. Shared UI components

lib/src/common/widgets/ contains reusable UI primitives such as loading and error widgets and a custom bottom navigation bar. These are intentionally outside feature folders so multiple screens can share the same presentation patterns.

6. Feature modularization

The app uses a clean-architecture-style feature split under lib/src/features/. Each feature is divided into data, domain, and presentation, which makes the architecture diagram fairly clean: infrastructure at the bottom, feature logic in the middle, and screens/widgets/providers at the top.

7. Home feature: main content pipeline

features/home is the main data-driven feature. It includes:

• data/services/video_services.dart for remote calls

• data/repositories/video_repository_impl.dart for data access orchestration

• domain/entities/video_entity.dart and repository contracts

• presentation/provider/video_notifier.dart and video_state.dart for UI state

• screens and widgets for the home feed.

This is the primary path for fetching, paging, and rendering the video list.

8. Home feature data flow

The typical flow is: Home UI → video_notifier/state → repository interface → repository implementation → video service → API endpoint → JSON model → domain entity → back to UI.

The data layer uses model classes for API serialization and the domain layer uses a separate VideoEntity, so the UI is insulated from raw API shapes.

9. Home UI composition and mini-player behavior

The home presentation layer is composed of reusable video widgets such as thumbnails, duration badges, info blocks, card widgets, and a video_pip_bar_widget. This indicates the home screen supports a draggable mini-player / picture-in-picture-style experience while the feed remains visible.

10. Video player feature

features/video_player is a second feature area focused on playback state rather than content retrieval. It has its own notifier/state pair and a video_player_dialog.dart, suggesting playback can be launched or controlled in a dialog-like overlay as well as a dedicated screen. This is the main boundary for player controls, options, and full-screen behavior.

11. Presentation state management pattern

The presence of *.notifier.dart, *.state.dart, and generated *.g.dart files strongly suggests Riverpod-style state management with code generation. The architecture therefore separates view state from widgets, with providers acting as the bridge between UI and repositories/player logic.

12. Data contracts and serialization

freezed and generated JSON files (*.freezed.dart, *.g.dart) appear throughout the models and states. That means immutable value objects and serialized API models are part of the app’s core design, reducing manual boilerplate and enforcing explicit data contracts.

13. Platform and asset boundaries

Assets are organized separately under assets/images and assets/logo, while platform-specific launch icons, manifests, and app entry stubs live in the host folders. These are support concerns only; they do not change the application’s feature/data architecture.

14. Build and tooling constraints

The repo is pinned with FVM (.fvmrc) and targets Flutter 3.32.5 / Dart 3.8.1, with code generation driven by build_runner. That matters for the architecture diagram because several core pieces depend on generated code and the app expects the Flutter toolchain to match the pinned version.