Simplifying Android Architectures for Developers — MVC, MVP, MVVM, Clean, MVI, VIPER, VIPER — part 1 : MVC

3 min readSep 19, 2022

I’m writing the article that I wish I had read. I have been studying software architectures and their applications in android development for some time, but I never found any practical comparison between the main architectures, I only read some articles about conceptual differences.

If you’re researching architectures for your android application, I’m going to assume you already know the basics of Android.

Methodology

I created the same app in each architecture (link). Pick a branch at will and check the implementation

App

This app is extremely simple. It can save and restore a name, and that's it.

Disclaimer: Regarding the practical part, I will avoid using some recommended libraries that would increase the complexity of this.

Introduction

It’s important to note that architecture isn’t just how you name your classes and packages. However, this is important to make your code easier to read and maintain, it's wrong to limit an architecture by only this.
If you understand software architecture like where you store information and the path that information travels through, I’d say you’re on a good path.
I’m being purposely generic because I don’t want you to get caught up in the technicalities.
The flow of information in your app goes through a set of layers. Layers are a kind of category common to a set of classes.

MVC

Theory

For a long time, Google has not commented on the importance of having a well-defined architecture in a project. At that time it was as if everything was allowed, so it was common to see projects where the activity did practically everything. And unfortunately in these cases, they mistakenly called it MVC.
But let’s focus on the correct form of this architecture.
In this architecture we have 3 layers:

The Model contains Databases, business rules, and access to external resources.

View: This architecture understands as a view only the layout .xml files.

Controller: This architecture assumes that these classes do a lot more than just show, hide, and change the colors of things. Here we will have logic and calls to model classes.

Data flow:

- The view requests information from a controller- The controller requests information from a model- The model return information to the controller- The controller returns information to the view

Conceptually this makes sense, the problem is that in practice our view is not an independent layer.
The activity is that which is responsible for displaying the view:


setContentView(R.layout.your_layout)

In practice, the view accumulates the responsibility of the view and the controller.

Practice

Model

Person.kt: This is a representation of a business class

PersonModel.kt: This is a class to access and store information.
I preferred using a SharedPreference for simplifying this sample. But this could be replaced by a database, API Rest, or another kind of data provider.
I used a static delay and an AsycTask to simulate work that takes time.

I created my own BaseAsynk that receives a high-order function to handle these events: onPreExecute, doInBackground, onPostExecute
I'd like to warn you: Some block codes have to be out of this explanation, so you can check all projects on GitHub.

View

Controller

There is made UI setup and calls for the model layer

You can check this project on GitHub. Remember to select the architecture that you wish to study on the build variants: