Let’s Deep Dive into Android Project Architecture

Let’s Deep Dive into Android Project Architecture
Hello World!
When I started coding with Microsoft Visual Basic, from then my only intention was to make things work. I think for most programmers, this happens at an early stage of their carrier. But when we get the chance to write our first line of code that I am actually paid for, after that very soon we can realize that we also have to care about our codes.

Cause people are using what we are developing, and users want more features, and your client pushes you to add features or change features. We also know that the one and only constant in software development is “CHANGE”. That’s why you are late to join the party, which we are already taking advantage of.
I know you have a question in mind, If my application runs well without any errors, then why are you pushing me to those complex and messy things?

Why do you follow Android Project Architecture?

Yes! You are right, you can develop applications without following any architecture, and even you can make the application bug free as well without following architecture. Then why?
I did appreciate your question, just a few months away from now, but now I can realize why “Uncle Bob” wrote a whole book on clean coding and architecture. The one and only answer are to make your code “Reusable, Readable, Testable” and believe me you will give me Thanks when you deep diving into it really! And it’s more than worth it to start diving into it.
I should tell you that, you will get tons of articles over the internet about how to use MVP, MVVM, MVC without even knowing why to use them.
That’s why at first I tried to answer some of them!

So let’s start the journey!

When we started with Android most of us only know about Activity, Fragment is the default class provided by Android to write codes. And we only write some other classes like Adapters and other things. But only care about the Activities and Fragments. Where we do all the things like any UI stuff, network calls to get data from a server, and even make a query into the local database to get data and then bind that with the UI.
And when your project gets bigger and bigger, you see lots of Fragments and Activities full of codes, sometimes 1000 thousand lines and above. And you start to think of yourself as a great programmer as you have already written this many codes, and it’s working and going in production and also people already started using it.

Also Read: MP3 Rocket Download For Windows 7,8 and 10

But when you open the project after 1 month or 2 months you will deep dive into the “Mariana Trench” the deepest point on the sea known by now.

Which is the best Android Project Architecture? MVP, MVVM, MVC, Clean Architecture?

When I started writing this article, I was fearing this question of you, I did know that you will throw this at me. But I thought I have an answer for you.

MVC (Model View Controller):

This pattern was the only thing for the mobile and web developers when they just need to separate the business logic from the UI and also where business logic doesn’t need to change much like the UI

  • Model — the data layer, responsible for managing the business logic and handling network or database API.
  • View — the UI layer — a visualization of the data from the Model.
  • Controller — the logic layer, gets notified of the user’s behavior and updates the Model as needed.

MVVM(Model View ViewModel):

This pattern is very new and future-oriented and is also recommended by the Android JetPack team. And the pattern actually

  • The View — This informs the ViewModel about any user action taken by the User
  • The ViewModel — The sends data to UI from the data source
  • The DataModel — This abstract the data Source and connect to the ViewModel

 MVP(Model View Presenter):

This pattern is the most used Architecture of the Android community! And the one and only reason are the Presenter himself. We will explore it with a very simple example project as we are selecting this pattern to deep dive into the Android project architecture

  • The Model— This is responsible for managing all your data and source like local database, Network, and other data streams as well
  • The View— All your User Interfaces are done those classes
  • The Presenter— That’s where all your business logics are, (Real programmers love this part)🤔

But the real answer is, it’s completely up to you, Every architecture have different pros and cons, but I suggest you start from the MVP, and later on you can switch as per your needs and will!

Let’s start learning the MVP pattern, Later you can switch by yourself. I know you will!

Hint: I assume that you have basic knowledge about Android development and Android Project Architecture. So I am not going to discuss how to create a project or the other noob things.
Our main target is to separate the business logic from the UI.
We are now writing a very simple application just to show a simple list of students in a screen, I know you have made 100x complicated things until now. But if you haven’t used MVP earlier, this small thing will make you happy!



See the above project in the screenshot, I have put the package’s name to make you understand what we are going to do.
In the model package, we have a Student DAO class to represent the data of each student. We all know about the model (POJO classes), as the Model is a layer that handles data, so we kept that inside the model package.

In the Presenter package

In the Presenter package, StudentListPresenter class is responsible for making ready the Student list by getting it from a server by network calls or by querying the local database. And pass it to the UI.
In the View package, we have two classes, that we are very familiar with. The StudentListActivity and the StudentListAdapter. These two are the class from the context or UI. An adapter for building the list and another one is the activity or screen.

Also Read: Why My Laptop is So Slow & How to Fix It

But In the View package, we don’t know the StudentListView, that’s actually an interface, this will be used for triggering the View from the Presenter.
The StudentListView contains these two functions that will be implemented by the Activity(UI/VIEW) to trigger the event from the presenter in simple words for communicating with the presenter.

These are the codes of StudetnListView: 
public interface StudentListView {
   void onSuccess();
   void onError();
By the above two methods of the interface, we will do the communication from the presenter to View
Let’s see the codes of the Presenter:
public class StudentsListPresenter {
private StudentListView studentListView;
//This is the constructor to get the StudentListView view injected from the class that implements this interface(StudentListActivity)
public StudentsListPresenter(StudentListView studentListView) {
  this.studentListView = studentListView;
public void populateStudetnList() {
// Let's populate a list of student, assume this list is coming from the server
List<StudentDAO> studentList = new ArrayList<>();
studentList.add(new StudentDAO("Mujahid", 21, 2));
studentList.add(new StudentDAO("Asik", 11, 4));
studentList.add(new StudentDAO("Faisal", 18, 7));
//trigger the onSuccess method of StudentListView so we can get this event is the StudentActivity where the interface is actually implemented!

The presenter actually has the reference of the interface. And here we do any network call, calculation, data operation, or any type of logical terms. But we want to update the user interface after we have updated the data. For that, we actually use the interface to communicate.

We have a Student Model Class named StudentDAO: 
public class StudentDAO {
   private String name;
   private int age;
   private int id;
   public StudentDAO(String name, int age, int id) {
       this.name = name;
       this.age = age;
       this.id = id;
  public String getName() {
       return name;
   public int getAge() {
       return age;
   public int getId() {
       return id;

We are using the above model class for the Student information.
Now we have just one part remaining which is the actual UI/View part. That is our activity where we did not want to make any logical works or data operations. We just want to work with UI there.

Here is the code of StudentListActivity:

public class StudentsListActivity extends AppCompatActivity implements StudentListView {
   StudentsListPresenter studentsListPresenter;
   RecyclerView studentRecyclerView;
   protected void onCreate(Bundle savedInstanceState) {
       studentRecyclerView = findViewById(R.id.
       //initialize the presenter
      studentsListPresenter = new StudentsListPresenter(this);
/*The two implemented method from the StudentListView*/
   public void onSuccess(List<StudentDAO> studentList) {
       StudentListAdapter studentListAdapter = new StudentListAdapter(studentList);
   public void onError(String message) {
(this, message, Toast.

I tried to make a very very easy implementation of this architecture. I think by seeing the code most of the things you have understood, but I don’t want to assume that. So I am going to tell a summary again.
We have the StudentActivity as the screen(though Activity in Android is much more thing. But assume as a single screen for now).
Then we have an interface StudentListView, we have a Presenter named StudentListPresenter, and a Model class name StudentDAO.
We are actually using the presenter class to separate the main logical part of our View class. I mean the Activity class. So we are using the interface to trigger the event from our presenter to View.
Carefully see the StudentListActivity class, you will see that we have a reference for the presenter in the class.
We want to show the StudentsList when a user clicks a button from our view. I mean Activity or any other events like button click. So for this, we need to call the populateStudentList() method from the Activity.

 //initialize the presenter
     studentsListPresenter = new StudentsListPresenter(this);

Final word 
I know what you are thinking now! We are doing a lot of extra work for every single screen(Activity, Fragments) that could be done without those. But in the beginning, I promised you that, using any of the architecture, you will love your work. You will see and love your code more often!