An Overview Of Android MVVM View Model With Live Data

An Overview Of Android MVVM View Model With Live Data

The Android operating system provides a solid foundation for building applications that work well across several devices and form factors. However, problems such as complex life cycles and the lack of recommended application architecture make it hard to build robust applications.

The components of the Android architecture provide libraries for simplifying usual tasks.

Architecture components help you structure your application in a robust, verifiable, and manageable way with less repetitive code. During Google I/O, Google introduced architecture components that include LiveData and ViewModel for the facilitation of developing an Android app using the MVVM pattern.

The android app development company empowers your business with advanced technology and optimal costs and helps you achieve your goals. When you hire

Android developers, you get the perfect balance of cost, time and quality. Android application developers work as an extended team and can deliver quality applications that meet business challenges in the shortest possible time. Android development services providers have sufficient knowledge regarding the latest technologies, trends, tools and frameworks.

Advantages of MVVM 1.Faster screen saving/loading (If rotate screen data will not recall through the internet) 2.Live data fetch and update.

MVVM has mainly the following layers:

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, which means the ViewModel should not be aware of whom with it is interacting with.

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]

MVVM using LiveData It is a container class for observable data. Unlike a normal one, LiveData is lifecycle aware, which means it respects the lifecycle of other application components, such as tasks, fragments, or services. This knowledge ensures that LiveData only updates observers for application components that are in an active lifecycle state.

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<Item> ) 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.

Important Guiding Principles for Implementing MVVM: As shown in the example, ViewModels does not and should not directly reference Views because if you do this, ViewModels could survive the life cycle of the View & a memory leak could occur.

We suggest that Model and ViewModel expose their data using LiveData, as LiveData respects the life cycle state of application components (activities, fragments, services) and leads the life cycle management of objects, assuring that objects LiveData are not refined.