sebasquintero123/mistockerapp

1) Overall shape

MiStockerApp is a single Android client module built in Kotlin with Jetpack Compose. The repository does not contain a custom server; the app talks directly to Firebase services for identity and persistence. That makes the architecture centered on the UI/navigation layer plus cloud-backed storage and authentication.

2) App entry point

MainActivity.kt is the Android entry point. Its job is to bootstrap the Compose UI and hand control to the app-level navigation. The manifest and Android resources define the standard Android runtime setup, launcher icon, theme, and app metadata.

3) Navigation boundary

AppNavigation.kt is the main screen router. It coordinates transitions across the app’s functional areas: login/registration, home dashboard, product management, stock viewing, and sales. For an architecture diagram, this is the hub that connects otherwise separate Compose screens.

4) Authentication and account lifecycle

The auth flow is split into dedicated screens:

• LoginScreen.kt

• RegistroScreen.kt

• RecuperarScreen.kt

• VerificacionScreen.kt

These screens form the user onboarding and account recovery boundary. The README indicates Firebase Authentication and email verification are used, so this subsystem depends on Firebase rather than local credential storage.

5) Inventory management subsystem

Product CRUD lives in the inventory screens:

• RegistrarProductoScreen.kt

• EditarProductoScreen.kt

• StockScreen.kt

This subsystem covers creating, updating, deleting, and listing products. It is the main operational flow for maintaining stock records and likely reads/writes user-scoped product documents in Firestore.

6) Sales subsystem

VentasScreen.kt handles sales capture, including multi-product sales and sales history per the README. This is a separate business flow from product maintenance, but it likely reuses product data from Firestore to calculate totals, stock impact, and history entries.

7) Home/dashboard layer

HomeScreen.kt acts as the application landing page after authentication. The README describes it as a financial dashboard with investment, stock, gains, and available units. Architecturally, this screen is an aggregator: it summarizes data from products and sales rather than owning the underlying records.

8) Data model and persistence

Producto.kt is the primary domain model present in the repo tree. The README shows the Firestore structure as user-scoped collections under usuarios/{uid}/productos and usuarios/{uid}/ventas. That means data is partitioned by authenticated user, and the app’s persistence boundary is Firebase Firestore. The included google-services.json confirms Firebase is wired into the Android app.

9) External services and device capabilities

Two external dependencies materially shape the architecture:

• Firebase Authentication for login, registration, password recovery, and verification.

• Firebase Firestore for persistent inventory and sales data.

• Google ML Kit Code Scanner for barcode scanning during product registration.

The barcode scanner is a device-facing capability embedded into the product workflow, not a standalone subsystem.

10) Shared UI and design system

Components.kt contains reusable Compose UI pieces, while OldDesignComponents.kt suggests a legacy component set kept alongside the newer one. The ui/theme folder defines color, typography, and theme configuration. This shared presentation layer reduces duplication across the multiple screens.

11) Project and platform boundaries

This is a conventional Android Gradle project (app/build.gradle.kts, root build.gradle.kts, version catalog, wrapper). The architecture is client-side only: UI, navigation, and cloud integration live in the app module. Testing is present via androidTest and test, but there is no separate backend, API gateway, or domain service layer in the repo.

12) How the main data flows connect

Typical flow is:

1. User authenticates through Firebase Authentication.

2. Navigation moves into the home/dashboard.

3. Product screens create/update Firestore product documents.

4. Sales screens read products, register sales, and update related records.

5. Home/dashboard aggregates product and sales data into business summaries.

For a diagram, the strongest boundaries are: Compose UI/screens, navigation, Firebase Auth, Firestore persistence, and the barcode-scanning device integration.