Adam McNeilly

Posted on Aug 16, 2019 • Updated on Jan 20, 2020

MVWTF: Demystifying Architecture Patterns

#android #architecture #cleancode

Originally published on Android Essence.

You can watch this talk from Android Summit on YouTube:

As an Android developer, one of the questions I constantly see asked within the community is "what architecture pattern should I use?"

This discussion usually leads to a handful of buzzwordy acronyms:

MVC
MVP
MVVM
MVI
MVU?? (We don't talk about this but apparently it's the new kid on the block)

This can be really intimidating to new Android devs, as well as seasoned veterans who are constantly questioning if they're using the right one. Whether you're trying to decide which one to learn, or wondering if the one you already use is best for you, this post will help lead you to the right decision.

We should first start off by understanding why we even need architecture patterns. When that question is asked, we get even more buzzwords, saying we want code that is:

Maintainable
Extensible
Robust
Testable

At face value, these may not sound like buzzwords, but are often just filler. What does it mean to write maintainable code anyways? The word robust means strong and healthy. What is strong and healthy code?

We're going to start at the beginning. Putting all of the buzzwords aside, we need to start with one single truth that is the basis for the rest of this post:

You can't put all of your code in the Activity.

Implicitly we all know this, and we put our code into separate files. However, it's more than just putting various classes into their own file. How we decide to break apart our code is very important, and that process is what architecture patterns are for. An architecture pattern is the way of describing how you split up your code.

Let's work through some options we have for splitting up our code by tackling the list of acronyms from the beginning, starting at the top.

Model-View-Controller

MVC deserves a quick section simply because it's one of the oldest architecture patterns. It was developed in the 1970s as a way to break up your application into three components: a model, a view, and a controller. It's important to understand the function of each component.

Model

The model component is your data source. This can be a database, remote server, local text file, or anything else. The important thing to remember is that it does not care about the view.

Your model should not be responsible for any behavior related to how data is displayed, just retrieving it.

For example, if you want to fetch a user and display a label that has the username and age together, you will create that label elsewhere. Not inside the model component.

View

The view component is the visual representation of your data. That is all it is responsible for. It should not care where that data came from. The view should not be making any decisions. If you find yourself writing a conditional logic in your view component, consider refactoring that.

Controller

Being the last component, the controller is responsible for just about everything else. It should:

Handle user input
Validate that input if necessary
Pass that input into the model
Pass that model response into the view

An easy way to think about this flow is to consider a form. The controller reads all of your text inputs, makes sure you've filled everything out, sends it to the model, and then tells the UI to show a success screen.

MVC Diagram

Let's take a look at how this all connects together:

Why Don't We Use This On Android?

At face value, this looks pretty good. Our concerns are separated and the flow of information is pretty clear.

However, of all the patterns in this post, MVC is the one discussed the least on Android. There's a quick explanation for this.

When you consider the responsibilities of a controller (accepting user inputs) and the responsibility of a view (displaying data), you may recognize that these are handled by the same thing in Android. This is your Activity or Fragment.

Why Is This Bad?

I'd like to highlight two reasons we wouldn't want this on Android:

We can't write Junit tests for an Activity or Fragment, so we should move as much code out of there as we can.
Our concerns aren't actually separated if two of three components are in the same class.

How Do We Fix This?

Let's move the controller/UI logic out of the Activity/Fragment.

Model-View-Presenter

By breaking the UI and business logic out of the Activity/Fragment, we create a slightly different flow of information. This creates the MVP pattern.

Now we have a separation of concerns where all of our non UI code is outside of the Activity/Fragment, and we can unit test all of it.

MVP Implementation

Before we move on to the next pattern, I think it's important to understand a little bit about the implementation of a pattern like MVP, so we can compare how the code evolves along the way, too.

Contract Class

The first thing we need to do to build a feature in MVP is design a contract class that has the interfaces defining the behavior of our three components:

class TaskListContract {

    interface View {
        fun showTasks(tasks: List<Task>)
    }

    interface Presenter {
        fun viewCreated()
        fun viewDestroyed()
    }

    interface Model {
        fun getTasks(): List<Task>
    }
}

Model

Our model can be a simple in memory list for this example.

Notice that our model doesn't actually reference other components.

class InMemoryTaskService : TaskListContract.Model {
    override fun getTasks(): List<Task> {
        return listOf(...)
    }
}

View

The view really only needs to do two things here:

Notify the presenter of any relevant life cycle methods, or click listeners if that was relevant
Override any methods from our contract class to display data

Notice that our View only has a reference to the Presenter.

class TaskListActivity : AppCompatActivity(), TaskListContract.View {
    private val presenter = TaskListPresenter(this, TaskRepository())

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...

        presenter.viewCreated()
    }

    override fun onDestroy() {
        presenter.viewDestroyed()
        super.onDestroy()
    }

    override fun showTasks(tasks: List<Task>) {
        taskAdapter.tasks = tasks
    }
}

Presenter

The presenter needs to override the methods from the contract class, call the view when necessary, and do any clean up required to avoid memory leaks (like removing a reference to the view).

Notice that our presenter has both a reference to the View, and a reference to the Model.

class TaskListPresenter(
        private var view: TaskListContract.View?,
        private val model: TaskListContract.Model
) : TaskListContract.Presenter {

    override fun viewCreated() {
        val tasks = model.getTasks()
        view?.showTasks(tasks)
    }

    override fun viewDestroyed() {
        view = null
    }
}

Is This Good Enough?

Our view is only responsible for displaying data
Our model handles fetching data
The presenter handles all inputs and UI logic
Everything is well separated and everything is testable
If you think this is good enough, use it!

What Is Different About MVVM?

Each architecture pattern in our original list leads into the next. MVP serves as a base for our discussion about MVVM, because there's really only one nuanced difference between them: the presenter doesn't need to care about the view.

Model-View-ViewModel

In the last pattern, we see that the presenter explicitly tells the view what to display. As an alternative, we can consider an event based approach where we just expose the state that our view should be in and anyone who needs to display that state can subscribe to those changes.

That's exactly how MVVM works. It breaks the connection between the presenter and the view and instead exposes information via some observable type, like LiveData or RxJava.

MVVM Implementation

Let's look at the code comparisons between implementing MVP and MVVM.

Model

The model component doesn't actually change much. Since we no longer have a contract class, though, I still recommend setting up an interface for your data fetching behavior.

interface TaskRepository {
    fun getTasks(): List<Task>
}

class InMemoryTaskService : TaskRepository {

    override fun getTasks(): List<Task> {
        return listOf(...)
    }
}

View

The view behaves similarly to the last example, in that we need to:

Create a reference to our ViewModel
Observe changes from that ViewModel to update the UI accordingly

class TaskListActivity : AppCompatActivity() {
    private val viewModel = TaskListviewModel(repository = InMemoryTaskService())

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...

        subscribeToViewModel()
    }

    private fun subscribeToViewModel() {
        viewModel.getTasks().observe(this, Observer { tasks ->
            adapter.tasks = tasks
        })
    }
}

ViewModel

Our ViewModel will look similar to the presenter, with a few key differences:

We no longer have a reference to the view, only the model component
We expose information via a LiveData object
We can fetch information as soon as we initialize, so we don't need to be notified of view creation

class TaskListViewModel(
        private val repository: TaskRepository
) {
    private val tasks = MutableLiveData<List<Task>>()
    fun getTasks(): LiveData<List<Task>> = tasks

    init {
        fetchTasks()
    }

    private fun fetchTasks() {
        tasks.value = repository.getTasks()
    }
}

What Makes MVVM Better Than MVP?

Up to this point, our code looks exactly like it did before, minus a direct reference to the view. The benefit of dropping that connection is that now we can leverage Android's ViewModel architecture component to help handle configuration changes better.

In MVP, our presenter had a reference to the view, which is often an Activity. If I rotate my phone, that activity is recreated, and now the presenter is referencing an Activity that no longer exists.

With a ViewModel, we have something that outlasts those configuration changes, and never has to lose state.

Handle Rotation in MVP

In MVP, we had to follow a lot of steps to handle rotation:

Add two new methods to our presenters contract to getState() and restoreState()
Update our view to call those methods in the corresponding lifecycle steps
Implement the methods to retrieve state and restore it in the presenter

Depending on how complicated your state is, step 3 can take a lot of time and require a lot of code.

Handle Rotation In MVVM

To make sure we easily handle rotation in MVVM, we do the following:

Update our ViewModel to extend the Android ViewModel architecture component
In our Activity, use ViewModelProviders to get the ViewModel that already exists
Re-subscribe to the LiveData to get the state

The first two steps are the same level of effort as those in the previous section, but now we don't have to think about saving and restoring state. We just need to re-subscribe to LiveData.

This saves us A LOT of time.

If you want to see the code comparisons there, please check out the slides from when this was post was given as a presentation.

Why Isn't MVVM Good Enough?

As we work through these architecture patterns, each one sounds even better. Now we have all the separation and testability benefits of MVP, and we have better state management on rotation!

There's still one more acronym in our list, though, which spoils the fun that MVVM isn't the best we can do. To understand where it falls short, let's look at a more complicated state.

Consider a feature that fetches a list of tasks and supports both a loading and an error state. You may try to put your state into some Kotlin sealed class:

sealed class TaskListState {
    object Loading : TaskListState()
    data class Loaded(val tasks: List<Task>) : TaskListState()
    data class Error(val error: Throwable?) : TaskListState()
}

Next, you update your ViewModel to show the state according to what's happening:

class TaskListViewModel(private val repository: TaskRepository) : ViewModel() {

    init {
        showLoading()
        try {
            fetchTasks()
        } catch (e: Exception) {
            showError()
        }
    }

    private fun showLoading() {
        state.value = TaskListState.Loading
    }

    private fun fetchTasks() {
        val tasks = repository.getItems()
        state.value = TaskListState.Loaded(tasks)
    }

    private fun showError() {
        state.value = TaskListState.Error(Throwable("Unable to fetch tasks."))
    }
}

This looks pretty good. There are some risks to the showLoading(), fetchTasks(), and showError() methods, though.

Any methods in the class can call them
We can't guarantee they're associated with a specific action or intent
We have multiple methods manipulating our state that we have to ensure don't conflict with each other

For a simple example like this one, MVVM may be fine. I can easily test everything to ensure I call these methods in the right order and avoid those risks. However, they would become more prevalent as our ViewModel gets more complicated. The next pattern works to solve that.

Model-View-Intent

Unlike the previous patterns, "Intent" doesn't refer to some specific component, but rather the intention of doing something that we want to capture in our state.

Managing Predictable State Changes With A Reducer

The first problem with MVVM that we can tackle is the lack of predictable state changes. Instead of having multiple methods that manipulate our state, we should have one pipeline. This flow will take in some action, and a current state, and output a new state for us.

Here is what that method signature would look like:

abstract class Reducer {
    abstract fun reduce(action: Action, state: State): State
}

If you are using a sealed class like we saw earlier to represent your state, we can have very clearly defined inputs and outputs:

class TaskListReducer : Reducer<TaskListState>() {

    override fun reduce(action: Action, state: TaskListState): TaskListState {
        return when (action) {
            is TaskListAction.TasksLoading -> TaskListState.Loading()
            is TaskListAction.TasksLoaded -> TaskListState.Loaded(action.tasks)
            is TaskListAction.TasksErrored -> TaskListState.Error()
            else -> state
        }
    }
}

If you're not using sealed classes, we can also leverage the copy() methods from data classes to handle updating our state here as well:

class TaskListReducer : Reducer<TaskListState>() {

    override fun reduce(action: BaseAction, state: TaskListState): TaskListState {
        return when (action) {
            is TaskListAction.TasksLoading -> state.copy(
                isLoading = true,
                isError = false,
                tasks = null
            )
            is TaskListAction.TasksLoaded -> state.copy(
                isLoading = false,
                isError = false,
                tasks = action.tasks
            )
            is TaskListAction.TasksErrored -> state.copy(
                isLoading = false,
                isError = true,
                tasks = null
            )
            else -> state
        }
    }
}

Using A Store For A Single Source Of Truth

The other goal we want to accomplish with MVI is to have a single source of truth for our state. We can achieve this by creating a state container called a Store. It has the following responsibilities:

The store maintains the reference to our current state
The store holds the reference to our reducer
The store is responsible for dispatching actions into the reducer to update the state

Here's a quick snippet on how we can implement all of that. In this example I expose the state via some listener that gets called whenever it changes, but you can do this with RxJava, LiveData, etc.

class BaseStore<S : State>(
    initialState: S,
    private val reducer: Reducer<S>
) {
    private var stateListener: ((S) -> Unit)? = null

    private var currentState: S = initialState
        set(value) {
            field = value
            stateListener?.invoke(value)
        }

    fun dispatch(action: Action) {
        currentState = reducer.reduce(action, currentState)
    }

    fun subscribe(stateListener: ((S) -> Unit)?) {
        this.stateListener = stateListener
    }
}

This is better than what we had previously, because the state lives in one place only (the store) and can only be modified by one thing (the reducer). Not only do we get clearly defined inputs and outputs from this, but we are also able to get a unidirectional flow of data, as seen in this diagram from Esri:

Connect This To Our ViewModel Or Presenter

Note in the diagram that we have a component that dispatches actions. This can be anything, meaning you don't need to be using MVVM to implement this flow. You can create a store and reducer and plug them into a presenter, too!

For this post, we'll hook it up to a ViewModel. All we need to do is create a reference to the store, and where we were previously modifying state we will just dispatch actions to it:

class TaskListViewModel(private val repository: TaskRepository) : ViewModel() {
    private val store: BaseStore<TaskListState> = BaseStore(
        TaskListState.Loading(),
        TaskListReducer()
    )

    // ...

    private fun fetchTasks() {
        store.dispatch(TaskListAction.TasksLoading)

        try {
            val tasks = repository.getTasks()
            store.dispatch(TaskListAction.TasksLoaded(tasks))
        } catch (e: Throwable) {
            store.dispatch(TaskListAction.TasksErrored(e))
        }
    }
}

Recap

Wow! That was a lot to take in, and thanks for making it this far. Let's TL;DR everything we just saw:

MVP is helpful because it separates our concerns and gives us code that is all junit testable. However, state management is unpredictable and rotation requires more work to support.

MVVM is a step forward, because we break the two way communication between the View and the Presenter allowing for better rotation support, but we still have unpredictable state management.

MVI takes us even further, by giving us predictable state management with clearly defined inputs and outputs.

So What Should I Use?

While it is clear that MVI is the strongest pattern we discussed, it's not always right for everyone. If your feature is really complex and has confusing user flows, you can benefit a lot from having that predictable state management.

If your feature is simply fetching and displaying some data, though, the learning curve of MVI and extra code required might not be worth the effort. It's up to you as a developer to decide how much complexity you need.

You certainly shouldn't feel bad about using MVVM, and in fact in the majority of features I've built it works well for me.

Code Samples

Interested in seeing the implementation for a specific pattern? Check out this GitHub repository which has a sample app with a module for each architecture pattern.

If you have any questions, drop a comment below or reach out to me on Twitter! If you were inspired by any particular section and want to see a deeper dive into a specific pattern, let me know!

Top comments (17)

Dmytro Karataiev • Jan 29 '20 • Edited

I really liked the article and the examples. I tried to play with the MVI example a bit more and refactored your example here: github.com/dmytroKarataiev/MVI-Exa...
My main motivation was to understand if we can re-use viewmodels with different Stores and also merge multiple viewmodels in a single reducer. Which I think I was able to achieve. I'll have to experiment how different threads will work with the reducer and if I need to add synchronization.

Bernardo Bessa • Aug 19 '19

That soft explanation about Android app architecture was kind of sublime, sir... Really!
Avoiding some might complex architectural concepts as Flux or Redux, for example, allows a easy compreension of our need to think what we should consider when building something.
I'd add just a detail about MVC. A lot of Android apps are just some kind of frontend component in a bigger architectural perspective, so the MVC you suggest makes sense. However, if the app purpose is to be a "single point" connected with some kind of datasource (files, databases, web services, etc.), I suppose the model can follow a Domain Driven Design, where you apply the Business Logic on your models (where you can/cannot use it to handle data, as well, or apply other kind of layer responsible for that business logic.).
Anyway, it was a refreshing way to study some of the complexity around Android app architecture.

Sviatoslav Melnychenko • Sep 3 '19

MVC diagram is missing the link between a model and a view. The view observes the model in MVC.
MVI is not a pattern. Disagree? Try to draw a diagram, as you have for other patterns. It's hard because MVI really depends on implementation. Though, MVI is a good helper for any other pattern of choice.

Adam McNeilly • Sep 3 '19

I think MVI is a pattern and a diagram could be drawn easily. I would just replace the View portion of the redux diagram in the post with a ViewModel or Presenter from the other diagrams.

Eric Donovan • Aug 19 '19

I like the post! A broad overview of architectures (and with actual code samples) like this is very helpful. I personally ended up with a different conclusion for android architectures though:

For what it's worth, I don't like MVI much at all. In theory it sounds great, but in practice I've found it requires large amounts of boiler plate for even simple UIs. Once we get to non trivial UIs (multiple loading elements, form validation etc), screens seem to take days instead of hours to implement. (To be fair I am also not a massive fan of MVVM as it's typically implemented - but it's ok).

I wrote something quite similar to your article that details my thoughts on it here: erdo.github.io/android-fore/00-arc...

Adam McNeilly • Aug 19 '19

I agree, MVI is a lot of work that we don't often need for simple pages that just load and display data. If there are a lot of moving parts/components to interact with, or flows based on complex decision trees, having that unidirectional state management can help a lot, though. I just hope this post helps highlight the differences well enough that people are able to decide for themselves. :)

I like your post! Your diagrams were given much more TLC than mine haha

Jakub Narębski • Aug 18 '19

@adammc331 : There is an error in the article, namely all of the Model-View-Controller images are Model-View-Presenter diagrams.

Adam McNeilly • Aug 19 '19

MVC is often described in different ways unfortunately, there's usually not a consistent answer.

How do you view the flow of data in MVC? And if what we have here is really MVP, what would you change about the MVP diagrams in this post?

Jakub Narębski • Aug 19 '19

Maybe I was not entirely clear. What I menat is that three first figures use the same image, with Model, Presenter, View and User nodes. (One at the beginning of the "MVC Diagram", one in "Why Don't We Use This On Android?" subsection, and one in "Model-View-Presenter").

They use exactly the same IMG tag, with the same image URL, and the same ALT attribute.

Adam McNeilly • Aug 19 '19

Ah! So sorry! Will fix!

Adam McNeilly • Aug 19 '19

I thought I had the right picture but that the diagram itself was wrong. 🙈 Will fix once I'm at a computer.

Adam McNeilly • Aug 19 '19

Fixed! Thanks for pointing it out for me. :)

Daniel Gomez • Jun 16 '20

Thanks for sharing this, currently I use MVP, Don't get me wrong but it feels to me that mvvm was borned also from "the boilerplate that comes from MVP contracts", I saw some people criticizing that, without realizing that this is a problem from OOP languages itself besides than just an MVP problem. Another thing that worries me about MVVM is that all of the presentation code is moved into the view, and so, only testable via Espresso or Roboelectric, which makes me worry about moving into this patterns. What do you think about this two ideas?