An Overview of Android MVVM View Model with Live data

Model

It represents the data and business logic of the app. It has business logic with a receptacle, which in turn has local and remote data classes. It communicates with local or remote data sources based on the ViewModel request.

ViewModel

ViewModel has all the logical part of the user interface. ViewModel works as a bridge between the View class and the Model. ViewModel can optionally provide hooks for the view to pass events to it. The ViewModel does not have a direct reference to the View class but sends the data via observables. The View part contains observed data & the user interface is updated when the reportable data is changed. One of the significant implementation strategies of this layer is to decouple it from the view that means the ViewModel should not be aware of it whom with it is interacting.

View

Views are to observe a ViewModel to get data for updating UI elements accordingly. It consists of a part of the user interface (i.e. activity, fragment, and so on). Clickable buttons or any actions are sent to the ViewModel but do not receive a response directly. For an answer, the view examines some data exposed by ViewModel. It means that it works with the Observer and Observable patterns.

[Also Read: Android 12 – Things You Need To Know About It]

Benefits of LiveData:

1.No Memory Loss – Watchers are tied to lifecycle objects and clean up after themselves when their associated lifecycle gets destroyed.

2.No crashes due to interrupted activities – If the view is destroyed or back stacked, it will not update it. With this approach, accidents can get withdrawn.

3.No manual lifecycle management further– As LiveData automatically manages lifecycle changes in the user interface, it is lifecycle aware.

Sample App Interaction Diagram

The following figure shows the package structure of the Sample App of MVVM lived.

Here Model has an API and repository from where all APIs is listed.

In the above structure,
Apiclient class has a retrofit builder that builds OkHttpClient.Builder ()
API service has our entire API list

ApiResponse, as the name convey, it has a data class to store data.

data class AResponse (

val total_count: Int,

val incomplete_results: Boolean,

val items: List

)

data class Item (

val id: Int,

val name: String,

val full_name: String,

val score: Double

)

And 1st RepoRepository class contains API response.

It also has one companion object for live data.

companion object {
private var INSTANCE: RepoRepository? = null
fun getInstance() = INSTANCE
? RepoRepository ().also {
INSTANCE = it
}
}

That’s all about what model class contains.
Now, let’s look at the View structure.

Here the example uses the recycler view in a fragment with an adapter class of recycler view and fragment adapter.

The fragment has function on view created from where call two methods setupAdapter () and setupObservers ()
The setupAdapter () sets the recycler view. The adapter of the recycler view has listed in the adapter folder.

The adapter class displays the data and click on the other events on the on BindViewHolder function.
Now, coming back to the setupObservers () observed the live data and call when the data gets changed.

Here you can see the android lifecycle that shows the same thing.

Now back to fragment fun setupObservers () if there is any data change, it will call pass updateRepoList with data & that function is known in recyclerview by notifying data change.

Now the question is how live data calls API.
In the above image where fragment onViewCreated () call there is one line
override fun onViewCreated (view: View, savedInstanceState: Bundle?) {
super.onViewCreated (view, savedInstanceState)
viewDataBinding.viewmodel?.fetchRepoList ()
setupAdapter ()
setupObservers ()
}

The fetchRepoList () call RepoRepository.getInstance () to getRepoList with MutableLiveData.

That’s all about MVVM Live data.