Why do we need to follow an architecture pattern in Android? A beginner’s guide.

Android Development is a vast field and every developer bouncing to develop apps needs to take time and follow the good(read: best) pattern to develop, deploy, and test apps.

Good application architecture is the foundation of a good platform and well-designed software. I would say, the base of any application is its architecture. An application with improper architecture is like an apple-pie with no crust and just the pie going wigwag. But no one would trust me if I bluntly said architecture is important. So, here are some bullet points suggesting why are they important:

1. Code is more readable
2. Reverse engineering is tough
3. Many developers working at the same time find it easy.

4. Implementation and design do not colloid with each other.

5. Easy to test and write unit tests

6. Able to keep track of logic

7. Entire code looks neat

8. Uncomplicated and unchallenging to add and remove features.

So the whole point is when you have all your code shoved inside a single class or activity, it is very difficult to read and causes a severe torment to your eyes. Traversing a code to find the error is difficult and hence “Command + F” for your savior. But, that is a bad practice and hence architecture is the need of the hour.

“FOLLOW ARCHITECTURE”

Since we’re talking about architecture it won’t be righteous if I don’t give you a gist of available architectures and the pros and cons between them so that you can choose the best architecture for you in the future.

1. MODEL-VIEW-VIEWMODEL (MVVM)

“Keeping UI code simple and free of app logic in order to make it easier to manage”

The focus of every architecture is pretty much the same, to separate the UI from the logic and keep the UI logic-free.

Model:

The model represents the backend implementation or business logic. It does not have any relation with the UI. The major enactment of model is to discrete itself from the User Interaction with the application and treat every data variables or methods as obsolete to the user and user layer. It does not get affected by the apps life cycle

ViewModel:

The ViewModel is a middle-man between the Model and the View. The view is inaccessible to all the variables in Model and hence there is a need of this middle-man to make the variables available to the View so that it can access the functionalities related to the UI. It uses a binder that binds all the View properties into a module and ViewModel can access it which is a two-way binding strategy and hence the process is quite automated.

Two-way binding: Whenever a property or functionality in UI gets updated, the model also gets updated and vice versa.

View:

Finally, the View is what users can see as it is evident from the name. The view gets to absorb data from the ViewModel and update the elements in UI with its functionalities. The View does not have any relation with the Model and interacts only via ViewModel.

This must have given you an abstract idea. But for more knowledge and in-depth observation, please refer these links:

1. https://www.tutorialspoint.com/mvvm/mvvm_introduction.htm
2. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
3. For Android Implementation — https://www.journaldev.com/20292/android-mvvm-design-pattern

2. MODEL VIEW PRESENTER

Model:

As described earlier in the previous architecture, here in MVP the functionality of the Model is pretty much the same. Model stores application or system data, fetching data from API, GET or POST request and so on.

Presenter:

The only difference between a presenter and a view-model is that View-Model offers you two-way binding of data and the presenter here just acts as a middle-man without two-way data binding. But that doesn’t mean that MVP is not an efficient architecture. It all solely depends on the type of app and it’s functionality. It talks to the View, goes to the Model, and gets all that the View needs from the Models grocery store (:P).

View:

The view is the same in every architecture which is responsible for every user’s action and interactions with the screen or activity. The View is obsolete to the Model and the Presenter is responsible for the communication between View and Model.

For implementation, please refer:

1. https://www.journaldev.com/14886/android-mvp
2. https://github.com/MindorksOpenSource/android-mvp-architecture

3. MODEL VIEW CONTROLLER

As you can see, in all the architectures the middleman is varying and hence distinguishes one architecture from the other. When it comes to MVC, the “M” and “V” of MVC are the same as in the other two architectures mentioned above. Let’s talk about the deviating part which is “C”- the Controller.

C- Controller is a Software Code which is used to retrieve data from Model to View.

“Huh, Is there even any difference? That’s what you said for the previous two architectures!”

It is an older architecture compared to the other three. The controller also sends commands to its associated view to change the view’s presentation. As the name suggests- it the Controller of the entire architecture from traversing data from here and there. It is always represented inside an activity or fragment.

For more details, please see:

1. https://www.guru99.com/mvc-tutorial.html
2. https://blog.mindorks.com/mvc-mvp-mvvm-architecture-in-android

Now, that we’ve seen about all the three famous architectures, you might have a tough time upon which one to choose.

Here is an integrated table of all the features in all the architectures,

Thank you for reading!

Happy Coding :)

Bhavna!