The Model-View-View Model as explained to a 6-year old

Every software engineer develops sophisticated applications to give users an amazing user experience. However, sometimes things don’t go as planned once it’s time to add a new feature, write test cases, or even debug code as things become difficult due to the codebase’s complexity.

For this, a clean code structure is needed.

In this tutorial, you will understand the logic behind the MVVM architecture in the simplest way possible.

Model-View-ViewModel (MVVM) is a software design pattern structured to separate program logic and user interface controls.

Let’s talk about the book definition of these concepts before breaking them down.

Activity/ Fragment:

• Activity is where the user will interact with your application.

• The fragment represents a behavior or portion of the user interface in an Activity.

You can combine multiple fragments in a single activity to build a multi-pane UI and reuse a fragment in multiple activities.

ViewModel:

• A ViewModel object provides the data for a specific UI component, such as a fragment or activity, and contains data-handling business logic to communicate with the model.

Live Data:

• LiveData is used to build data objects that notify views when the underlying database changes.

Repository:

• Repositoryalso known as the Single Source Of Truth modules handle data operations. They provide a clean API so that the rest of the app can retrieve this data easily. They know where to get the data from and what API calls to make when data is updated.

Model:

• It represents the data and the business logic of the Android Application. It consists of business logic, local and remote data sources, and model classes.

Remote Data Source:

This is where we communicate with the REST API so that the data source can fetch data remotely.

Now that we’ve learned the logical definitions of all the concepts, let’s move over to simpler explanations.

Storyline

It’s a hot afternoon and Mom decides to make some smoothies for Anna and her sister Emily.

Mom looks into the fridge to get some fruits and realizes she’s short on blueberries. Mom quickly orders the blueberries from an online store.

Everything is set to get started on the smoothies, so Mom quickly sends the variety of fruits over to be blended in a blender. And voila!

The smoothies are ready and are served straight from the blender to the drinking cups.

Mom decides to try out a new recipe and adds strawberries to the mix. Anna was so excited to try out this new mix that she went to the blender to get some more smoothies.

Explanation

Mom: Mom is our Repository, she is the single source of truth to our data(fruits) and she is in charge of getting fruits from local storage or an external source.

Fridge: The fridge is our local store, more like our SQLite.

Online Store: This is our remote data source that fetches data from outside.

Blender: This acts as our ViewModel and is in charge of managing our data as well as the logic. It basically does all the manipulation and mixing up.

Anna & Emily's Drinking Cup: This is either our Activity or Fragment that displays data from our ViewModel (the blender). It doesn’t bother to know how the smoothie it made, it just collectsdisplays it.

New Mix: Once the strawberries are added, the data is changed a bit – this is where LiveData comes in. The ViewModel (Blender) notifies our drinking cups with the new data (new smoothie mix).

Conclusion

From the concept above, we can see that all our components are have their own distinct functions.

The application UI has nothing to do with the program logic or how to fetch data – this is one of the few benefits of using the MVVM Architecture.

I hope that, with this simple story, I’ve been able to break down complex information about the MVVM Android Architecture into tiny bits and pieces.

Let’s have a smoothie!