Model View ViewModel: Usage of MVVM in LinqTV's App Architecture

For any software development process, code structuring is an extremely important aspect. And personally, we think MVVM is the best way to structure code (in most situations).

The thing we like most about it is the compartmentalization of the various components in a project.

When we were not using MVVM, we often used to face issues like:

We noticed three important key things after applying MVVM which are as follows.

When we use the MVVM pattern in the application, It allows us to reuse the codes/modules without any complications. For Ex:-

We have developed an application that supports multiple templates on top of a single code base. It allows us to have easy and quick customization on a specific template without changing the core business logic. It’s only possible when your View and Data part is completely separate. It also allows you to template switching without any hassle.

build.gradle app file.

def version= ‘1.1.1’

Implementation “android.arch.lifecycle:extensions:$version”

annotationProcessor “android.arch.lifecycle:compiler:$version”

Repository classes handle data operations. Creating a repository is a clean way to provide clear distinctions between how an application retrieves data, and how it uses/displays that data.

Repositories know where to get the data from (ex: what REST API to query, what internal SQLite database to query, etc…) and what API calls to make when data is updated. You can consider repositories mediators between different data sources, such as persistent models, web services, and caches.

The ViewModel class is described perfectly by its name. It’s a model, for a view. The view can be a fragment or an activity. And the model can be anything. It’s a model for the data you want to display in the view.

A ViewModel can tell other components to retrieve data (for example a repository), and it can handle incoming requests from a user to modify the data (for example a user adding a new element to a RecycerView full of list of items).

Like a repository, a ViewModel is another form of mediation. It separates the act of retrieving or updating data sets (represented by the repository), and the current state of the UI. A ViewModel doesn’t know about the lifecycle of an activity or fragment. If a configuration change occurs, it doesn’t care. Its only concern is holding an accurate reference to the data for the view. If the user were to close the app and reopen it several hours later, they would see exactly the same thing as when they closed it.

Now that you have an idea of the overall structure of this design pattern, let’s talk about how the different components communicate. How does a view (an activity or fragment) display the data represented inside the ViewModel?

This is a difficult concept to understand conceptually, so I’ll use an example.

Suppose you were constructing a ViewModel for an activity that displays a user profile. The