nahid1126/book-orbit

1. What this repo is:

Book Orbit is a single-module Android app built in Kotlin with Jetpack Compose. Architecturally it is organized like a clean/MVVM app inside the app module rather than split into multiple Gradle modules.

2. Top-level layer separation:

The codebase is divided into ui, domain, data, and core. ui owns Compose screens and ViewModels, domain defines repository contracts, data contains the concrete implementations and storage/network adapters, and core holds cross-cutting helpers such as results, logging, enums, constants, and exception utilities.

3. Application bootstrap and DI:

BookOrbit.kt is the app entry point, and dependency wiring is centralized in Koin modules under data/di (AppModule, FirebaseModule, RepositoryModule, ViewModelModule). This is the composition root that connects ViewModels to repository implementations and external services.

4. Presentation layer shape:

The UI is split by feature under ui/presentation: welcome, home, books, book details, gems, profile, and main. Each feature typically has a Compose screen plus a ViewModel, which means state is pushed into the UI via observable state rather than managed directly in composables.

5. Navigation boundaries:

Navigation is handled with Jetpack Compose Navigation in ui/navigation. There are separate navigation graphs for the welcome flow and the main app flow, which implies a gate between onboarding/authentication and the authenticated/book-browsing experience. Destinations.kt centralizes route definitions and type-safe argument passing.

6. Key user flows:

The app appears to start in a splash/welcome path (WelcomeActivity, SplashScreen, LoginScreen) and then transition into the main app (MainActivity, NavGraph). The main experience includes browsing books, opening book details, viewing PDFs, managing gems, checking purchase history, and visiting profile/legal screens.

7. Domain and data contracts:

The domain/repository package defines the repository interfaces for auth, books, gems, and billing. The concrete implementations live in data/repository, which keeps the UI and ViewModels insulated from Firebase, local storage, or billing SDK details.

8. External service integrations:

Firebase is an important backend dependency, evidenced by google-services.json and FirebaseModule. The app also integrates Google Play Billing through BillingRepositoryImpl, supporting gem purchases as a monetization path.

9. Data persistence and models:

Local state/persistence is handled through data/local/AppPreference and type converters. Remote-facing data shapes are defined in data/remote/dto for books, gems, and gem transactions, suggesting the app maps backend or cloud data into app-facing models through repository logic.

10. State and concurrency model:

The app uses Kotlin Coroutines and StateFlow for async work and UI state updates. This makes the data flow one-directional: user actions in Compose screens trigger ViewModel logic, which calls repositories, then emits new state back to the UI.

11. Shared UI and error handling:

Common Compose components such as dialogs, typography helpers, and bullet text live under ui/presentation/component. Shared runtime helpers in core/utils and core/utils/exception standardize result handling and exception translation across features.

12. Architecture diagram summary:

A useful diagram would show: Compose screens at the top, ViewModels beneath them, repository interfaces in the domain layer, repository implementations in the data layer, and then Firebase/local preference/Play Billing as external adapters. The app has two main navigation branches: welcome/auth and authenticated main app, with gems/billing acting as a side business flow connected to the content access experience.