Android Architecture: Journey from MVP to MVVM

“Overchoice is a cognitive process in which people have a difficult time making a decision when faced with many options. Making a decision becomes overwhelming due to the many potential outcomes and risks that may result from making the wrong choice.

The same principle is applicable to Android development as well. Today we have so many android architectures like MVC, MVP, MVVM, MVI, Clean Architecture and so on. It becomes very difficult for a developer to choose the best architecture as almost every architecture is mainly based on separation of concerns, i.e UI based classes like Activities/Fragments should only contain logic that handles UI and so on. So how to choose one from many ?

If we do some research, we’ll find that MVP & MVVM are the most common architecture which is being used right now in the industry. Let’s discuss these two briefly with the help of below image.

MVP Vs MVVM

If we observe carefully, we will see that View & Model is there in both architectures. The only difference is Presenter is there in MVP and ViewModel is there in MVVM architecture. Now let’s see what is the difference between these two.

1. Presenter keeps reference to Views which it uses to callback view’s methods like showProgress(), hideProgress(), showErrorMessage() and so on. ViewModel, on the other hand, doesn’t keep any reference to views but exposes LiveData for the view to observe. We’ll understand it better when we walk through some code shortly.
2. Presenter is NOT lifecycle aware component by default. Views can be either destroyed or recreated (screen orientation change) while presenter is fetching data from the network. This might result in leakage of data or worse, it can crash the app. ViewModel, on the other hand, is a lifecycle aware component. It survives configuration change. ViewModelProviders knows how to give ViewModel. When we make below call the very first time,

it gives a new instance. When the rotated activity comes back, it reconnects to the same ViewModel. We can understand it better with the help of below image which clearly shows that ViewModel survives configuration change.

Enough chit-chat, let’s see some code!

We’ll be seeing the same app written using MVP and MVVM architectures. This is a very simple app which takes user birth year as input and prints his age after 2 seconds (intentionally added to mimic API request). Let’s dive in!

kgaurav23/FindMyAge

Using MVP Architecture:

MVP Folder Structure

As we can see, we have view and presenter packages containing Activity (view) and Presenter classes. Also, we have created two interfaces namely IViewContract and IPresenterContract so that these two layers can communicate with each other. If you remember from the above image (MVP vs MVVM image), Presenter and View both keeps a reference to each other

Let’s see what’s written inside Activity and Presenter.

Activity Code

Presenter Code

So when user enters birth year and clicks on ‘Find Age’ button, presenter method ‘findAge()’ is called. This method takes care of updating the UI like showing progress loader, showing error message on UI if the user enters invalid input etc. using IViewContract interface methods.

Everything seems to be working fine except for one small problem. Try to rotate the device while presenter is fetching the data (Here I have added explicit delay of 2 seconds to demonstrate the issue). What do you see ?

What happened when we rotated the device?

When we rotated the device, android destroyed the existing activity and recreated it. So old presenter also died with activity and a new instance of presenter is created which is unaware of user request. So we see that ongoing loader disappears from the screen (as activity is recreated and default visibility of loader is View.GONE) and age is NOT displayed on UI. We can solve this issue by writing some boiler plate code , but we can do better and that too without writing any extra code.

MVVM to rescue

kgaurav23/FindMyAge

Using MVVM Architecture:

MVVM Folder Structure

As we can see, we don’t have any interfaces defined here in MVVM. So lots of boiler-plate code have been removed. We have two packages namely view and ViewModel. The view has a reference to ViewModel but ViewModel has no reference to View. ViewModel survives rotation and other configuration changes.

Let’s see code written inside Activity and ViewModel.

Activity Code

ViewModel Code

So when activity is created for the first time and we ask for ViewModel instance, ViewModelProviders creates a new instance and gives it to us. But once the activity is recreated (on screen orientation change) it reconnects back to same ViewModel. Since ViewModel doesn’t have any reference to view, it shares data with activity with the use of LiveData.

LiveData is an observable data holder class that is lifecycle-aware, one of the Android Architecture Components. You can use LiveData to enable your UI to update automatically when the data updates.

ViewModel objects are scoped to the Lifecycle passed to the ViewModelProvider when getting the ViewModel. The ViewModel remains in memory until the Lifecycle it’s scoped to goes away permanently: in the case of an activity, when it finishes, while in the case of a fragment, when it’s detached.

Now when you run this app and rotate the screen while ViewModel is fetching data, everything works fine and UI is updated as soon as ViewModel updates the age LiveData.

• MVP architecture enforces View and Presenter to be tightly coupled with each other whereas, in MVVM View and ViewModel are loosely coupled.
• In MVP, lots of code is needed for setting up callbacks between View and Presenter making code size excessive. In MVVM, we don’t need much boilerplate code for setting up callbacks. Less code means fewer bugs.
• In MVP, we need to write some boilerplate code inside view and presenter to check whether the view is alive or not before posting any data back to view whereas, in MVVM ViewModel and LiveData solves the lifecycle issue without writing much code.

If you have made it so far, give yourself pat on the back. I hope I was able to clearly explain the differences present in MVP and MVVM. If you learned something by reading this article, do share with your friends. Your feedback/suggestions are welcome.

Thank you!