Architecture Learnings Part #1 {What is in a Model?}

Image by Lubos Houska from Pixabay

As a developer we come to hear these words MVC, MVP, MVVM, MVI daily and we do a lot of brainstorming to decide which architectural pattern we have to use in our app. Do you notice something by just looking at these abbreviations? Yes, you are right! They all talk about “M” i.e Model. Understanding and defining a Model is very crucial in laying the foundation of your architecture no matter which architecture you choose.

So what’s in a Model ?

It is often realised that most of the times developers did not have a Model at all or confused where their Model lies. Amidst confusions, we “model our Models in a wrong way”.

Let’s consider an example of loading a list of items from backend in a traditional MVP architecture pattern.

What is the “Model” in the above code snippet?

• Is it the backend, api — No
• Is it the items — No
• Is it the item in the list — No

Now let’s define a class ListModel for this example.

Let’s see how we re-write our presenter(v2) with this class defined above

Observations

Our View now has a Model which represents the state of the view. View observes the Model for any changes and renders accordingly.

Achievements

Having a well defined Model solves a lot of issues we quite often struggle in our development process.

State Problem

Well, most of the time we describe state as what we see on the UI. e.g “loading state” when the View displays a loader or a “data state” when list is displayed or an “error state” when the list fetch is failed.

Let’s consider the following view Model code snippet with DataBinding without a ListModel

The Presenter or View Model, even Business Logic layer and the View itself can have their own states which may also depend on the underlying host system. e.g in Android OS, the app process might be killed in low memory

The Presenter or View Model has arbitrarily many inputs to process actions and multiple outputs to deliver as well. Eventually, it leads to conflicting states of View, Presenter and business logic especially when working with multiple threads. And, this results in Bugs.

Solution

ListModel reflects the state. A single source of truth for state passed from bottom (business logic) to the top (the UI). Our presenter (as shown in ItemListPresenterV2) can now have only one output. i.e getView().render(ListModel). This can further be enhanced by making the ViewModel or Presenter view lifecycle aware. For example, in Android, we can use the ViewModel class to store and manage UI-related data in a lifecycle-conscious way.

Model ≈ State

Immutability

One more thing that Model can help us with is immutability. We want an immutable state, because as we said earlier that we want only one single source of truth i.e our ListModel in our example. We don’t want that other components in our app can manipulate the state we pass the Model object around.

Let’s imagine we are going to write a simple score maintaining Android app that has an increment and decrement button and displays the current score in a TextView.

Now, if our Model (counter value — an integer) is immutable, how do we change the counter?

Observations

First, we should build our UI for the Score View as dumbed as possible to just have a render(Score) method.

Second, our Model is immutable, so no direct change of score, i.e the Model is possible.

Third, there is only one single source of truth, i.e the business logic. Click events from UI move unidirectionally to the business layer. The business logic knows the current Model (i.e. has a private field with the current Model) and will create a new Model with the + /- score value according to the old Model.

Model ≈ Immutable

Easy Debugging

A unidirectional data flow ensures that our app is easy to debug as without immutability single source of truth is violated and we are not sure who has actually changed the Model.

Conclusion

In this first part of this blog post series we discussed that how important it is to understand a Model. How it can help us to prevent some issues, we otherwise would struggle with.

Model ≠ Business logic. It’s the business logic that produces a Model.

I would like to thank you for visiting this blog and taking a moment to read. Hope we can provide some useful information here.

The next part of this series talks about the nitty-gritty in designing the View layer of your application.

Architecture Learnings Part #2 {How to build a View that reacts on model changes?}

Stay tuned…

Don’t forget to hit the clap button more than once :)