MvvmKotlinJetpackCompose 🚀

A Comprehensive Guide to Modern Android Architecture

Welcome! This project is a professional learning template designed to bridge the gap between "writing code" and "designing systems." It demonstrates how to build a robust, testable Android app using Clean Architecture, MVVM, and the latest Jetpack tools.

<div align="center"> <img src="https://user-images.githubusercontent.com/24357731/143909939-01d0fa4c-47f6-467f-a927-d3fa6e5c2d51.png" width="250"> <img src="https://user-images.githubusercontent.com/24357731/143911861-996649a9-3df4-44ff-b000-7300e5085950.png" width="250"> <img src="https://user-images.githubusercontent.com/24357731/143912106-8a5fb378-1f13-4f44-8596-e9740fd460a0.png" width="250"> <br> <img src="https://user-images.githubusercontent.com/24357731/143912270-ae660f16-0c7f-4d67-8aae-ae34421bf67f.png" width="250"> <img src="https://user-images.githubusercontent.com/24357731/143912389-6ab7063a-fd82-4567-a395-1a3f372ba3f1.png" width="250"> <img src="https://user-images.githubusercontent.com/24357731/143912529-fda38601-0925-4270-995b-f14c6e36d37d.png" width="250"> </div>

---

🏗 Why do we need an architecture?

Let's say you created a project without any architecture, simply doing everything in the Activity class (e.g., calling APIs, database interaction, parsing logic, etc.). Even if you have separate classes, your Activity handles multiple responsibilities, making it a God Object.

The Problem: When requirements change (like a UI update), the tight coupling between UI and logic makes changes slow and risky. You might break the API logic while fixing a button. It becomes hard to maintain, difficult to track bugs, and impossible to reuse or test.

The Solution: Architecture breaks the system into independent parts that talk to each other through defined rules. This reduces chaos and makes your code Robust, Extensible, and Testable.

---

🧩 The SOLID Principles

We keep our architecture clean by following these techniques:

S - Single Responsibility (SRP)

“A class should have only one reason to change.” Compare class names with their behaviors. If a method looks "out of place," it belongs elsewhere. In this project, an Activity only renders UI, while a Repository only fetches data.

O - Open/Closed (OCP)

“Open for extension, but closed for modification.” You should be able to add new features without changing existing code. For example, our BaseViewModel provides standard loading logic that any new ViewModel can extend without modifying the base class.

L - Liskov Substitution (LSP)

“Subtypes must be substitutable for their base types.” Well-designed inheritance ensures that if you swap a parent class with a child (e.g., a RealRepository with a TestRepository), the app continues to function perfectly.

I - Interface Segregation (ISP)

“Don’t force a class to depend on methods it doesn't use.” We split large interfaces into small, specific ones. This keeps our classes lean and prevents them from implementing "empty" methods just to satisfy an interface.

D - Dependency Inversion (DIP)

“Depend on abstractions, not concretions.” High-level logic (UI) shouldn't depend on low-level tools (Retrofit). They both depend on Interfaces. This is why we use Dependency Injection (Hilt) to wire our app together.

---

🧩 Business Rules vs. Presentation Rules

A critical part of Clean Architecture is separating these two:

| Rule Type | Layer | Example (LoginUseCase) | | :--- | :--- | :--- | | Business Rule | Domain (UseCase) | "If login succeeds, save the token and update headers." | | Presentation Rule | UI (ViewModel) | "Show a circular progress bar while the network call is active." |

---

🔄 The Data Flow (UDF)

This project uses Unidirectional Data Flow. Data only moves in one direction:

graph TD
    UI[Compose UI] -->|User Action| VM[ViewModel]
    VM -->|Execute| UC[UseCase]
    UC -->|Request Data| RP[Repository]
    RP -->|Fetch| DS[Data Source: API/Local]
    DS -->|Raw Data| RP
    RP -->|Success/Error| UC
    UC -->|Flow Result| VM
    VM -->|Update State| UI

---

🗺 Project Structure (The Map)

app/src/main/java/.../
├── data/                 # DATA LAYER: Repositories, API (Retrofit), Prefs (DataStore)
├── ui/                   # PRESENTATION LAYER: ViewModels, Compose Screens, Themes
│   ├── base/             # Foundation classes (BaseViewModel, etc.)
│   └── [feature]/        # Feature-based packages (Login, Dashboard, etc.)
├── di/                   # DEPENDENCY INJECTION: Hilt Modules
└── util/                 # THE TOOLBOX: Helpers, Coroutine Dispatchers

---

🛠 Modern Tech Stack

• Jetpack Compose: Modern declarative UI that reacts to state changes.
• Hilt: Automates Dependency Injection.
• Retrofit: The industry standard for type-safe networking.
• Moshi: A modern JSON library for Kotlin that makes parsing seamless.
• Coroutines & Flow: Handles asynchronous tasks smoothly.
• DataStore: A reactive local storage solution.

---

🧪 Unit Testing: The Safety Net

Unit testing isn't just about finding bugs; it enforces good architecture. If you can't test a class easily, your architecture is likely too "tight."

• Confidence: Verify that adding a new feature didn't break old ones.
• Speed: Run thousands of tests in seconds without needing an emulator.

---

📝 License

This project is licensed under the MIT License.