I guess I’ll be the last person on earth to have come aboard the MVVM hype train 🚂 😅. Google provides the wonderful ViewModel library for implementing MVVM painlessly. This article however, is a product of ‘what if there wasn’t the library’ thought.

MVP vs MVVM

According to a lot of the articles that talk about comparison between the architectures for Android (realm, this, this and many more), the basic difference that comes out between MVP and MVVM is that MVVM removes the strong coupling between View and Presenter that exists in MVP. In case of MVP,

Tight Coupling in MVP

We see that MainPresenter has MainView as a dependency and hence, is tightly coupled to the MainActivity(UI Controller) . This forces us to have only one presenter per ui-controller and for a screen with large number of modules in it, the presenter can get large and pretty difficult to handle.

However, in case of MVVM,

Loose Coupling in MVVM

We see that MainViewModel doesn’t have any view dependency i.e., it’s loosely coupled with UI-Controller . This gives us the freedom to have multiple viewmodels per ui-controller. So, even for a screen with large number of modules, we can have separate viewmodel for each module. This leads to a more modular way of development (you can just plug-n-play viewmodels with ease) and thus, improve the testability of code.

Existing MVP to MVVM

Here’s a look at our existing MVP.

MVP Presenter

MVP Activity (View)

So, the first step that we take towards converting this into an MVVM would be removing very the instances of MainView from MainPresenter . Thus, we are already half way through by removing the dependency of view from Presenter. MainPresenter now has no awareness of view and thus, if required can be flexibly plug-n-played to any UI Controller.

But, now that the Presenter has no medium to communicate with the view, we shall be implementing a Observer design pattern where all the view.xyz(..) statements in the Presenter will be replaced by Observer Interface (let’s call them data observers) statements xyzDataObserver.setData(..) . Theses data observers will be then implemented in the view, thus replacing the previous MainView function implementations.

//..MVP

override fun xyz(data) {

..do something

} //..MVVM

observe(object: IXyzDataObserver() {

override fun setData(data) {

..do something

}

})

This is roughly in line with the pattern that Android’s LiveData library follows, where all the LiveData objects can be “observed” for any data change. We’ll go ahead and add a similar syntactic sugar over our data observers to make it little more familiar.

DataObserver used in MVVM

So, our data observer is basically a wrapper over the observer interface, where setting a value would trigger the observer lambda that will be implemented in the view for example,

This, to be honest, looks exactly like LiveData 😅.

Thus we have, on a crude level, removed our dependency of View completely from the Presenter preserving the original functionality. In the next article, we will be discussing about implementing a crucial feature of Android’s ViewModel library i.e., retention over configuration change. We will not be retaining the instance of Presenter instead, we will be retaining all the data points of the Presenter over configuration change.

The entire source code for this article with step-by-step commit can be found in the repository.

Suggestions & feedbacks always welcome 😀