Applying Architectural Principles to an Android MVVM Project (WanAndroid)

Preface

The article gathers well‑known architectural articles from the industry, reflects on architectural thinking inspired by building design, and reconstructs Jetpack MVVM. The associated GitHub repository will be continuously updated, and 23 design patterns will be practiced to deepen understanding of their business‑scene usage.

1. What Is Architecture

1.1 Architecture Introduction

Architecture, like Chinese characters, consists of two parts: “架” (framework) and “构” (components). The combination of overall structure and components forms an architecture. In an Android app, classes are the bricks, interfaces are the connectors, and task flows describe how the system fulfills a requirement such as a network request.

架: construction, support – the overall structure. 构: building, component – the individual bricks.

1.2 Architecture (Building Science)

Software architecture emerged in the 1960s and became popular in the 1990s, whereas building architecture dates back to the stone age. Thousands of years of building practice have produced styles and patterns that make a structure unique; the same idea applies to software.

An image of the ancient Maya site Chichen‑Itza illustrates how precise numerical design can be achieved even in prehistoric construction.

Winston Churchill once noted that the layout of the British House of Commons influenced the development of the party system, showing how architecture can shape behavior.

2. Goals of Architectural Design

Software architecture shares the same purpose as building design: to balance form and function. The article lists four main goals: scalability, customizability, extensibility, and maintainability.

1. Scalability : The app must handle rapid growth in UV/PV while maintaining performance.

2. Customizability : Different user groups may require distinct features, so the system should allow selective activation.

3. Extensibility : New technologies should be integrable without major rewrites.

4. Maintainability : Easy bug fixing and addition of new features reduces labor and cost.

3. Practicing an App: WanAndroid

The author implements a simple WanAndroid client to illustrate the discussed architectural points. Core features include a home page with hot‑search categories, a project page showing complete projects, and detail pages for articles and projects.

3.1 Architecture – Form

The project is divided into two main modules: core and features . The core module provides dependency injection (Dagger), utilities, base classes (BaseActivity, BaseViewModel), third‑party handling, and network error handling. The features module offers high cohesion, clear functional structure, modularity, and encapsulation.

Benefits of this layout include faster compilation, fewer Maven conflicts, reusable common functions, and strong package cohesion.

The author avoids excessive module fragmentation, which can lead to long build times (7‑8 minutes) and tangled dependencies.

All code is written in Kotlin, using build.gradle.kts for simplified Gradle scripts and buildSrc to manage Gradle dependencies.

3.2 Architecture – Function

The functional points (article and project retrieval) rely heavily on network requests. The article emphasizes that no single architectural pattern is universally best; the most suitable one fits the current business needs. Google’s recommended MVVM pattern is adopted, following the official Android Architecture Guide.

MVVM satisfies the previously described design goals and adheres to two main principles: separation of concerns (keeping UI logic out of Activities/Fragments) and model‑driven UI (ViewModel, LiveData, Model).

Separation of concerns : UI components remain lightweight, reducing lifecycle‑related issues.

Model‑driven UI : Models handle data independently of Views, enabling lifecycle‑aware data flow.

Data flows in a single direction: Activity → ViewModel → Repository . Reactive programming with LiveData handles callbacks safely, preventing memory leaks and crashes.

3.3 UseCase

UseCase is a Clean Architecture concept that connects the UI layer with the data layer and handles IO switching. The project replaces RxJava with Kotlin coroutines.

abstract class UseCase
where Type : Any {
abstract suspend fun run(params: Params): Either
operator fun invoke(params: Params, onResult: (Either
) -> Unit = {}) {
val job = GlobalScope.async(Dispatchers.IO) { run(params) }
GlobalScope.launch(Dispatchers.Main) { onResult(job.await()) }
}
class None
}

3.4 Complete Network Request Flow

View : Sends network request and observes UI data.

ViewModel : Provides data to the View and handles business logic.

LiveData : Lifecycle‑aware observable data holder stored in ViewModel.

UseCases : Bridge ViewModel and Model, updating LiveData.

Model : Retrieves data from network, database, or other APIs.

4. Conclusion

The article demonstrates the journey from architectural theory to practical implementation, inviting readers to share their own insights, especially regarding the “form follows function” principle. Future updates will continue to enrich the WanAndroid project with more design patterns and features.

References

Android Application Architecture Guide, Clean Architecture, LiveData Overview.