aljaz/flutter_server_box
1
1
Fork 0
mirror of https://github.com/lollipopkit/flutter_server_box.git synced 2026-02-14 20:24:29 +01:00
Code Issues Packages Projects Releases Wiki Activity
Files
a1968b371ba54d569072eff9e6ff83bade1d0b05
flutter_server_box/docs/src/content/docs/development/architecture.md
lollipopkit🏳️‍⚧️ 6338c6ce6b opt.: docs l10n (#1036) 
* opt.: docs l10n
Fixes #1035

* opt.

* rm: redundant docs

* rm: features chapter

* opt.: docs l10n
Fixes #1035

* fix
2026-01-29 20:27:21 +08:00

2.9 KiB
Raw Blame History

title, description
title description
Architecture Architecture patterns and design decisions

Server Box follows clean architecture principles with clear separation between data, domain, and presentation layers.

Layered Architecture

┌─────────────────────────────────────┐
│          Presentation Layer         │
│         (lib/view/page/)            │
│  - Pages, Widgets, Controllers      │
└─────────────────────────────────────┘
                 ↓
┌─────────────────────────────────────┐
│         Business Logic Layer        │
│      (lib/data/provider/)           │
│  - Riverpod Providers               │
│  - State Management                 │
└─────────────────────────────────────┘
                 ↓
┌─────────────────────────────────────┐
│           Data Layer                │
│      (lib/data/model/, store/)      │
│  - Models, Storage, Services        │
└─────────────────────────────────────┘

Key Patterns

State Management: Riverpod

  • Code Generation: Uses riverpod_generator for type-safe providers
  • State Notifiers: For mutable state with business logic
  • Async Notifiers: For loading and error states
  • Stream Providers: For real-time data

Immutable Models: Freezed

  • All data models use Freezed for immutability
  • Union types for state representation
  • Built-in JSON serialization
  • CopyWith extensions for updates

Local Storage: Hive

  • hive_ce: Community edition of Hive
  • No manual @HiveField or @HiveType needed
  • Type adapters auto-generated
  • Persistent key-value storage

Dependency Injection

Services and stores are injected via:

  1. Providers: Expose dependencies to UI
  2. GetIt: Service location (where applicable)
  3. Constructor Injection: Explicit dependencies

Data Flow

User Action → Widget → Provider → Service/Store → Model Update → UI Rebuild
  1. User interacts with widget
  2. Widget calls provider method
  3. Provider updates state via service/store
  4. State change triggers UI rebuild
  5. New state reflected in widget

Custom Dependencies

The project uses several custom forks to extend functionality:

  • dartssh2: Enhanced SSH features
  • xterm: Terminal emulator with mobile support
  • fl_lib: Shared UI components and utilities

Threading

  • Isolates: Heavy computation off main thread
  • computer package: Multi-threading utilities
  • Async/Await: Non-blocking I/O operations