How komikku-app/anikku works
<explanation>
1. Project Type & Purpose
- Anikku is a multi‑module Android application (Kotlin + Jetpack Compose) for discovering and watching anime.
- It follows a Clean‑Architecture approach (layered modules for presentation, domain, data) and ships as a feature‑rich client with local database, network calls, file I/O, sync, extensions, and widgets.
2. Key Modules & Patterns
- app: Android application entry point (UI hosts, Compose screens, ViewModels, DI wiring, WorkManager jobs).
- presentation‑core / presentation‑widget: Shared Compose UI components & Glance widgets.
- domain: Business logic (use‑case interactors, models, repository interfaces).
- data: Data layer implementations (SQLDelight repositories, mappers, network services).
- source‑api / source‑local: Extension‑point modules for pluggable remote and local “sources”.
- core‑common / core‑archive / core‑metadata: Utility and shared network, archive (CBZ), metadata models.
- i18n modules: Multi‑platform resource providers.
- buildSrc: Centralized Gradle conventions.
- DI: DomainModule, AppModule, PreferenceModule – likely using Koin or Dagger/Hilt for dependency injection.
- MVVM: ViewModels in app module talk to domain use‑cases.
3. External Services & Infrastructure
- Remote anime sources: HTTP parsers (source‑api), trackers (AniList, MyAnimeList, Kitsu, Simkl, Bangumi).
- Backup & Sync: Google Drive, SyncYomi services.
- Discord Rich Presence via RPC service.
- Torrent server API.
- Local persistence: SQLDelight database, SharedPreferences/DataStore.
- File I/O: CBZ/unzip, image caching (Coil), downloaded media files.
- WorkManager: background jobs for backup, library updates, syncing, downloads.
4. How to Draw the Diagram
a. Identify Components (boxes):
• UI Layer: Compose screens, ViewModels (app + presentation‑core + presentation‑widget)
• Domain Layer: Use‑cases (interactors) & Domain models
• Data Layer: Repositories & Mappers (data module), SQLDelight DB
• Core Libraries: core‑common, core‑archive, core‑metadata
• Extension Framework: source‑api + source‑local
• External Services: HTTP API endpoints (tracker APIs, Torrent, Backup), Google Drive, Discord RPC
• Background Scheduler: WorkManager jobs
• Build & CI: Gradle buildSrc + GitHub Actions (optional to show)
b. Relationships & Flows (arrows):
• UI → ViewModels → Domain Use‑Cases → Repositories → Data Sources (DB / Network / File)
• Data sources call External Services (HTTP, local FS)
• Use‑Cases may invoke WorkManager to schedule background jobs
• Domain & Data modules depend on core‑common utilities
• source‑api plugins are discovered by app at runtime via ClassLoader
c. Architectural Patterns & Principles:
• Clean Architecture: Strict dependency rule (UI → Domain → Data → Framework)
• MVVM: ViewModels as mediators between UI and Domain
• Modularization: Feature modules (i18n, presentation, data, domain) to reduce coupling
• Dependency Injection: Centralized modules in di/
d. Technologies & Frameworks:
• Kotlin + Coroutines + Flow
• Jetpack Compose for UI
• SQLDelight for typed database access
• WorkManager for background tasks
• Coil for image loading
• Gradle multi‑module, buildSrc conventions
• Glance for widgets
• Moko‑resources for i18n
• HTTP clients with OkHttp + custom interceptors
5. Diagram Tailoring Guidelines
- Full‑stack Mobile App: Emphasize separation UI vs. domain vs. data, local DB, network layers.
- Show plugin architecture: source‑api modules for remote extension sources.
- Illustrate background jobs and sync flows (backup, library update).
- Highlight external trackers and backup endpoints as separate boxes.
6. Visual Elements to Include
- Clear labels for each box and module.
- Solid arrows for synchronous calls (UI → Domain → Data).
- Dashed arrows for asynchronous/background flows (WorkManager → Data).
- Different colors/shapes:
• Blue: UI & presentation
• Green: Domain
• Orange: Data & core libs
• Gray: External services
• Yellow: Background/scheduler tasks
7. Detail & Completeness
- Capture all multi‑module relationships, not just classes.
- Show buildSrc as the root of build conventions (optional).
- Don’t overcrowd: group similar modules (e.g., all i18n under “Localization”).
- Ensure the directional flow matches the Clean‑Architecture dependency rule.
- Add a legend explaining colors and arrow styles.
With these guidelines and a layered breakdown of the modules, the diagram will accurately reflect Anikku’s architecture, its plugin‑based source system, data/sync workflows, and the role of each Gradle module.
</explanation>