Image by Freepik
Over the years, android developers need to handle some tricky challenges while development, such as database mappings, lifecycle management resulting in errors and boilerplate code. In this blog, we’ll explore the standardized architecture proposed by the Android team at Google I/O conference and look at the main elements of the new Architecture Components:
In November 2017, Google introduced the Android Architecture Components, a collection of libraries which assists developers in addressing two problems:
- Managing UI components lifecycle
- Persist data over configuration changes
Table of Contents
- 1 1. Room
- 2 2. LiveData
- 3 3. ViewModel
- 4 Wrapping Up
One of the good things about Android development is having the ability of a real SQLite database to store data, along with built-in support in the framework using Room.
Room is an abstraction layer over SQLite. Despite of having a lot of features, it also has certain drawbacks. For example, there is no mechanism to express a one-to-one relationship and no backing for an UPSERT (Insert or Update of a row). As it is a relatively new library from Android, I would anticipate that it will get better over time.
Note: It depends on the projects requirements if you want to store large amount of data than you should use Room Database
Saving a list of videos a user has added to their watchlist (In this case a table is needed with columns)
Storing a list of offline download video’s metadata, so when a user isn’t connected to the internet, he gets to view somethings from the room database, this is the technique used in most media apps like Panteao,Vipa.
What is LiveData?
As a starting point, let’s examine the definition provided in the official Android documentation:
An observable data holding class is called LiveData. Unlike regular observables, LiveData is lifecycle aware. It respects the lifecycle of other application components such as activities, fragments, etc. Because of this understanding, LiveData will only update application component observers that are in an active lifecycle state.
So, here are a few pointers that will encourage developers to use LiveData in applications:
- Developers can use LiveData with libraries like Room, Coroutines, Flow etc.
- Observers are notified of changes as soon as the data changes
- However, before notifying the observer, LiveData will check if the observer is live or not. Notifications will be sent if they are live, otherwise they will not be sent. This will stop crashes due to stopped activities.
- You don’t have to worry about unregistering observers while using LiveData.
- If an inactive observer resumes in the future, the latest data will be sent to that observer.
- Only updated data is sent, so you don’t have to worry about recovering activity due to screen rotation.
By using the LiveData you can easily communicate between the Views with ViewModel and Repositories. LiveData will post or set values from ViewModel or Repository in form of Mutable LiveData
What is Mutable LiveData
MutableLiveData is only a magnificence that extends the LiveData. MutableLiveData is commonly used since it provides the public methods like postValue(), setValue(), that LiveData class doesn’t provide. LiveData/MutableLiveData is commonly used to update the RecyclerView’s data from a collection type (List, ArrayList, etc.). In the next section, we’ll create an application that adds/deletes RecyclerView rows from a SQLite database. Use MutableLiveData to update RecyclerView records when LiveData changes. Use DiffUtil to update the minimum number of RecyclerView rows by comparing the old and new ArrayList.
ViewModels provide data between repositories and views. Unlike Activities that are destroyed by configuration changes, ViewModels survive configuration changes, keep their data safe, and keep their state intact.
An alternative to a ViewModel is a simple class that holds the data to display in the UI. This can be a problem when navigating between activities or navigation destinations. During the navigation you will lose the data if you don’t store it using the saving instance state mechanism. ViewModel provides a convenient API for data persistence to resolve this issue.
The main benefits of ViewModel classes are basically two:
- It allows you to persist UI state.
- It provides access to business logic.
- Persistence- ViewModels enable persistence, both through the state they maintain and the operations they initiate. Persistence means that you don’t have to fetch data again through common configuration changes, such as a screen rotation.
- Scope- When instantiating a ViewModel, developers pass it an object that implements the ViewModelStoreOwner interface. This can be a Navigation target, Navigation graph, activity, fragment, or any other type that implements the interface. The ViewModel is then mapped to the ViewModelStoreOwner lifecycle. It remains in memory until the ViewModelStoreOwner dies completely.
Data binding makes it easy to communicate between views and data sources. This pattern is important to many Android designs, including Model View ViewModel (MVVM), which is one of the most popular Android architectural patterns today.
According to the Android developer documentation:
A data binding library is a support library that allows you to bind UI components in your layout to data sources in your app declaratively, rather than programmatically.
What exactly is the use of DataBinding?
Before we go any further, we need to understand the importance of using data binding in Android.
Data binding is the process of combining a view of an XML layout with a data object. The Data Binding Library is responsible for generating the classes required for this step.
Unlike other types of layout XML files, data binding layout XML files start with a root layout tag, followed by data elements. Each layout file is then associated with a data binding class created by the library.
In most cases, the default class name is the layout file name followed by the binding suffix, e.g. SplashActivityBinding.kt.
The advantages of using the Data Binding Library in Android applications are:
- You can reduce calls to findViewById and improve your app’s performance
- Helps eliminates memory leaks or nullPointerExceptions
- Use a more customizable declarative layout
- Improves developer productivity by creating bug-free, short, understandable, and maintainable code.
- If you use type safety and try to assign the wrong type to a variable, the compiler will check the type at compile time and display an error.
The Google preferred architecture also demonstrates the true potential of data binding by leveraging libraries in every way, from expression declarations to binding adapters. Implementing UI logic and testing UI becomes much easier.
Having a sound knowledge of architecture components is crucial for developers while android applications development. Hope this article has given you proper understanding of the each layer of architecture components. If you need to discuss how to build an app using these components, reach out to us now!