Model Views Coordinator for Android

This is not Model View Controller though you could argue it sounds like it. This is not also exactly Model View Presenter, but you could argue it’s a variant of it. So what’s is it?

Start from MVP

Imagine if you have a View Container (could be your Activity or Fragment) that doesn’t know what to show, and not having any knowledge of what to show at all. You now have a presenter logic that will tell the View Container what to show, and it will shows it.

In a simple illustration as MVP pattern below

Such a pattern sounds great, where the Presenter determines what view to show. Not only that, it provides the view so that the Container is totally agnostic of what view to be shown, but just responsible of showing it.

Isn’t that great?

Sounds good but …

As simple as the above sound… but if one thinks carefully,

What does it mean sending the view to the Container?

Is it, upon decide what to be shown, the Presenter will call the Container's API to show the view?


NO. This will need to have Container having knowledge of how to create the LoadingScreen.

Is it sending something to the view to the Container like below?


YES! But…

Something smells…

That sounds like a great idea! But somethings is not right…

This doesn’t seems clean!

In normal MVP pattern, the Presenter should be free from any Android Framework. This is to ensure the Presenter is much more easily unit tested without need to mock any Android framework.

However if Presenter now determines what view to creates, then it sounds like it has to create the view, and that also means it has to have Android object.

We need to maintain the clean boundary…

Problem Statement

With the requirements

  1. The Container should be agnostic of what view to shows (and not having the view information within)
  2. The Presenter shouldn’t be creating the Android Specific Framework view but still responsible for what view to be created.

How could we achieved that?


With the above problem statement provided, the below proposed pattern is made.

The Coordinator

Similar to the Presenter, the Coordinator is responsible for handling the logic and communicating with external model (and outside world).

Besides, it is also responsible to decide what view to be displayed. This is done through creation of an object call Presentation. Once created, the Presentation will be sent to the Container.

The Presentation

The role of Presentation is to store information that would be passed to the Container, and enable Container to create the respective view and the data the view need to show.

With that, the Presentation would contains

  1. data of type Serializable so that it could be stored in Bundle.
  2. getViewClass where it defines what view to be created e.g. Fragment.
abstract class Presentation {
open val data: Serializable? = null
abstract fun getViewClass(): Class<out Fragment>

A simple example of Presentation implementation as below

class ErrorPresentation(val errorMessage: String): Presentation() {
override val data = errorMessage
override fun getViewClass() =

The Container

The Container main responsibility is to create the respective View, e.g Fragment. It doesn’t know what View to create, but it gets the information from Presentation.

A sample of how it creates the View as below

private fun createView(presentation: Presentation): Fragment? {
val fragment = presentation.getViewClass().newInstance()
val arguments = Bundle()
fragment.arguments = arguments
(fragment as ViewPresentation).coordinator = mainCoordinator
return fragment

From the above code, you you’ll notice that it

  1. Instantiate the Fragment
  2. Provide the Fragment the respective data it needed
  3. Provide the Fragment a reference to coordinator through an interface of ViewPresentation.
I’ll elaborate item 3 further below. Hold on.

Upon Fragment created, it could be shown. From here, you could see that the Container is agnostic of what View it is showing, but just it is showing some view.

The ViewPresentation Interface

The View implements the ViewPresentation interface, so that it would contain a reference to the Coordinator.

interface ViewPresentation {
var coordinator: Coordinator

This is created for the View to be connected to the Outside World. E.g. a view that show result, that enable user to Load-More would need to update it’s data further, hence this could be done through the Coordinator.

If the View doesn’t need to interacts with the Outside World after being displayed, the link to Coordinator is not needed.

But for the sake of consistency and simplicity this interface is implemented so a generic step could be set in the Container to provide Coordinator to all Views.

Another problem to solve…

With the above pattern implemented, it looks like all works great.

However in Android world, the Container and the View might be destroyed by the system and restored by the system later.

Don’t worry, this is all taken care off.

In the Container, on state restoration, just provide the restored View the newly created Coordinator again as below, then all will work fine.

private fun restoreFragmentState() {
.findFragmentById( {
(it as ViewPresentation).coordinator = mainCoordinator

Demo Code Example

To demo the Model-Views-Coordinator, I use my example code from my previous blog in

The code just demo how to use RxJava to manage state of data loading, and upon loaded, it will show the view accordingly. However all views are residing within the MainActivity, hence if there’s a new view needed, MainActivity need to be modified.

Besides, it doesn’t manage State Restoration. If you turn on Don't Keep Activity, you’ll see the view always got reset to the initial state instead of where it is. This could be resolved, but might makes things a little complicated as one has to know what data was previously loaded, to determine what view to show.

Model-Views-Coordinator Example

With the above code, I have modified them to use Model-Views-Coordinator approach

It changes the view to respective Fragments and Presentation. So the Coordinator would decide which Presentation to sent to the Container.

With this in place, the state restoration is automatically taken care off, and all the View decision of what and how to shows now resides in the Coordinator and not the Container

I also add a functionality, where touch on the Icon, the View will send a message through the Coordinator to be toast. This is to demonstrate how the View would still connect to Outside World through the Coordinator.


This is one pattern that would be helpful if you ever need a Coordinator that will decide what view to shows, and also not worry about handling the State Restoration. It’s a useful pattern where your Container could be made more generic.

This is not a very conventional approach in Android, as most that I see, the ownership of the view code all resides within the Activity or Fragment. Hence this change the style a bit decoupling the view code from it’s parent container.

There might be some limitation on this pattern, e.g. the responsibility of the Coordinator could become huge if we have many View to interacts with it, with different type of interactions across them.. etc.

But I’m all ear to hear your view of such approach.. hence share it here, in case I miss something…

I hope this post is helpful to you. You could check out my other interesting topics here.

Follow me on medium, Twitter or Facebook for little tips and learning on Android, Kotlin etc related topics. ~Elye~