33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# Application Architecture
|
|
|
|
## Overview
|
|
|
|
The application follows a modular structure separated by responsibilities (models, pages, components, services).
|
|
|
|
## Layers
|
|
|
|
### 1. Data Layer
|
|
|
|
- **Models**: `Pokemon` class defines the data structure for a Pokemon, including serialization/deserialization logic.
|
|
- **API**: `PokemonApi` handles communication with the Tyradex REST API using the `http` package.
|
|
- **Database**: `PokedexDatabase` manages local persistence using SQLite (`sqflite`). It uses batch operations for performance during initial sync.
|
|
|
|
### 2. Business Logic & State
|
|
|
|
- **State Management**: Uses Flutter's `StatefulWidget` and `setState` for local page state.
|
|
- **Reactivity**: `ValueNotifier` in the database layer notifies the UI when data changes (e.g., catching a Pokemon updates the list).
|
|
- **Persistence**: `shared_preferences` is used for simple key-value storage like best scores.
|
|
|
|
### 3. UI Layer
|
|
|
|
- **Pages**: Top-level screens like `MainPage`, `PokemonListPage`, and `GuessPage`.
|
|
- **Components**: Reusable UI elements like `PokemonTile`.
|
|
- **Navigation**: Managed in `MainPage` using `IndexedStack` to preserve tab state across navigation.
|
|
|
|
## Data Flow
|
|
|
|
1. At startup, the app checks the local database.
|
|
2. If the database is missing generations, it fetches the full list from Tyradex API and performs a batch insert.
|
|
3. User interactions (like a correct guess) update the local database.
|
|
4. The database triggers a notification, causing relevant UI components to refresh their view.
|