Previous parts:

What is MVP architecture?

In the previous part, I wrote about some pitfalls of the MVC architecture and attributed them to the fact that the Controller does not DIRECTLY pass the data to the View and informs the View to get it directly from the Model. Well, this is not an issue in MVP… here is how.

In MVP architecture, in fact, the Presenter layer has a much more prominent role than the Controller in MVC. The presenter now acts as a complete mediator between the View and Model so that they don’t need to know each other directly (diagram below).

MVP architecture

In other words, the Presenter now directly gets the data from the Model, applies any required task on it make it presentable to the View, and finally calls the appropriate method from the View to show it. Therefore, the View is completely passive and only knows how to show the data the Presenter provides it with.

MVP in simple words

User: Click click …

View: Who’s that?

User: I just clicked on the search button …

View: Ok, hold on a sec … .

( View calling the Presenter … )

View: Hey Presenter, a User has just clicked on the search button, what shall I do?

Presenter: Hey View, is there any search term on that page?

View: Yes,… here it is … “dummy search term”

Presenter: Good,… meanwhile I’m looking up the search term on the Model, please show him/her a progress bar

( Presenter is calling the Model … )

Presenter: Hey Model, Do you have any match for this search term?: “dummy search term”

Model: Hey Presenter, let me check …

( Model is making a query to the database … )

(After a while, Model comes back with some result to the presenter)

Model: I found a list for you Presenter, here it is “dummy search result”

(Presenter thanks Model for the list and gets back to the View)

Presenter: Thanks for waiting View, I found a list of matching results for you from the Model and arranged them in a presentable format. Please show it to the user in a vertical list.

View: No worries,… This is what I’m good at …

Presenter: … and don’t forget to hide the progress bar

( View gets back to the user and hides the progress bar …)

View: Thanks for waiting User, here is the list of matching results in a vertical list

User: oh, what a lovely app, can I know the developer’s name by any chance?

Let’s see it in action …

Now, let’s see how the above conversation comes into reality in our example app introduced in the first part… . The complete app is in the ‘MVP’ branch of my Github repo.

Starting from MainActivity , we first instantiate the structural components of the MVP architecture: Model, View and Presenter in onCreate :

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    mMainPresenter = MainPresenter(MainModel())
    mMainPresenter hasView this
    loadView()
    respondToClicks()
}

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

mMainPresenter = MainPresenter(MainModel())

mMainPresenter hasView this

loadView()

respondToClicks()

}

private fun loadView() {
    setContentView(R.layout.activity_main)
    addressAdapter = AddressAdapter()
    main_activity_recyclerView.adapter = addressAdapter
}

private fun loadView() {

setContentView(R.layout.activity_main)

addressAdapter = AddressAdapter()

main_activity_recyclerView.adapter = addressAdapter

}

View: receives the click action, gets the search term from the EditText, and calls Presenter:

private fun respondToClicks() {
    main_activity_button.setOnClickListener({ mMainPresenter.findAddress(main_activity_editText.text.toString()) })
    addressAdapter setItemClickMethod {
        mMainPresenter doWhenItemIsClicked it
    }
    addressAdapter.setItemShowMethod { mMainPresenter fetchItemTextFrom it }
}

private fun respondToClicks() {

main_activity_button.setOnClickListener({ mMainPresenter.findAddress(main_activity_editText.text.toString()) })

addressAdapter setItemClickMethod {

mMainPresenter doWhenItemIsClicked it

}

addressAdapter.setItemShowMethod { mMainPresenter fetchItemTextFrom it }

}

Presenter: Calls the Model to lookup the search term. At the same time it invokes the showProgressBar() method from the View. If there is some result for the search term, onSuccess() method is called which in turn invokes the hideProgressBar and updateMovieList methods of the View. Otherwise, onError() is called.

fun findAddress(address: String) {
    val disposable: Disposable = mainModel.fetchAddress(address)!!.subscribeOn(schedulersWrapper.io()).observeOn(schedulersWrapper.main()).subscribeWith(object : DisposableSingleObserver<List<MainModel.ResultEntity>?>() {
        override fun onSuccess(t: List<MainModel.ResultEntity>) {
            mainView.hideProgressBar()
            mainView.updateMovieList(t)
        }

        override fun onStart() {
            mainView.showProgressBar()
        }

        override fun onError(e: Throwable) {
            mainView.hideProgressBar()
            mainView.showErrorMessage(e.message!!)
        }
    })
    compositeDisposable.add(disposable)
}

fun findAddress(address: String) {

val disposable: Disposable = mainModel.fetchAddress(address)!!.subscribeOn(schedulersWrapper.io()).observeOn(schedulersWrapper.main()).subscribeWith(object : DisposableSingleObserver<List<MainModel.ResultEntity>?>() {

override fun onSuccess(t: List<MainModel.ResultEntity>) {

mainView.hideProgressBar()

mainView.updateMovieList(t)

}

override fun onStart() {

mainView.showProgressBar()

}

override fun onError(e: Throwable) {

mainView.hideProgressBar()

mainView.showErrorMessage(e.message!!)

}

})

compositeDisposable.add(disposable)

}

Thanks MVP and RxJava, you’re a great match together!

What I like and dislike about MVP in android

All of my concerns in the previous article for MVC are now gone for good:

View is only dependent on Presenter, contrary to MVC which depends on both Presenter and Model
Model is not doing too much work compared to MVC. Here is the entire Model for our sample app:

class MainModel {
    private var mRetrofit: Retrofit? = null

    fun fetchAddress(address: String): Single<List<MainModel.ResultEntity>>? {
        return getRetrofit()?.create(MainModel.AddressService::class.java)?.fetchLocationFromServer(address)
    }

    private fun getRetrofit(): Retrofit? {
        if (mRetrofit == null) {
            val loggingInterceptor = HttpLoggingInterceptor()
            loggingInterceptor.level = HttpLoggingInterceptor.Level.BODY
            val client = OkHttpClient.Builder().addInterceptor(loggingInterceptor).build()
            mRetrofit = Retrofit.Builder().baseUrl("http://bechdeltest.com/api/v1/").addConverterFactory(GsonConverterFactory.create()).addCallAdapterFactory(RxJava2CallAdapterFactory.create()).client(client).build()
        }
        return mRetrofit
    }

    class ResultEntity(val title: String, val rating: String, val date: String, val year: String)
    interface AddressService {
        @GET("getMoviesByTitle")
        fun fetchLocationFromServer(@Query("title") title: String): Single<List<ResultEntity>>
    }

}

class MainModel {

private var mRetrofit: Retrofit? = null

fun fetchAddress(address: String): Single<List<MainModel.ResultEntity>>? {

return getRetrofit()?.create(MainModel.AddressService::class.java)?.fetchLocationFromServer(address)

}

private fun getRetrofit(): Retrofit? {

if (mRetrofit == null) {

val loggingInterceptor = HttpLoggingInterceptor()

loggingInterceptor.level = HttpLoggingInterceptor.Level.BODY

val client = OkHttpClient.Builder().addInterceptor(loggingInterceptor).build()

mRetrofit = Retrofit.Builder().baseUrl("http://bechdeltest.com/api/v1/").addConverterFactory(GsonConverterFactory.create()).addCallAdapterFactory(RxJava2CallAdapterFactory.create()).client(client).build()

}

return mRetrofit

}

class ResultEntity(val title: String, val rating: String, val date: String, val year: String)

interface AddressService {

@GET("getMoviesByTitle")

fun fetchLocationFromServer(@Query("title") title: String): Single<List<ResultEntity>>

}

See? Model here only contacts the api services for the lookup task and is even Presenter agnostic.

Presenter controls the UI logic, contrary to MVC which was not clear who was responsible for that.

Having said that, is there anything about MVP that I don’t like?

Well, not much really…

testability is excellent (don’t forget to check the unit tests on the ‘MVP’ branch on my Github repository.,

modularity is fantastic,

… but one thing does not interest me much in MVP and that is the large amount of boilerplate code the developer should write for doing the simplest feature…

I removed the hassle by writing an android MVP library which not only removes the boilerplate code but also handles lifecycle-dependent operations like cancelling network connections when the View is no loner visible to the user (read the relevant article here).

However, the best way of getting rid of boilerplate code as well as retaining modularity, testability and all other strong points of MVP is using MVVM architecture, which is the subject of part 4 of this series.

android architecture: Part 3: MVP

What is MVP architecture?

MVP in simple words

Let’s see it in action …

What I like and dislike about MVP in android

Leave a Reply Cancel reply