How to Build an App Using Android Architecture Components?

Android architecture components (AAC) are a set of library functions that help to build the applications hassle-free. The architecture components are part of the android jetpack and help to manage UI component lifecycle and handle data persistence.

When an app is developed using some of the core components, such as activity, service, a broadcast receiver, and a content provider. It would be more difficult to resolve things. In order to eliminate this problem, Google introduced "architecture component" in 2017.

Why architecture component?

Android systems don't recommend any specific architecture to develop an application. You're completely free to adopt any model, such as MVC (Model View Controller), MVP (Model View Presenter), MVVM (Model View ViewModel), or no pattern. This architecture pattern improves the application by increasing the testability.

In case, you want to use (MVP) in your application then starting from scratch come up with your own solution, writing a lot of boilerplate code or adopt a library without any official support.

Reasons why use an architecture component:

1. Persist Data

2. Manage Lifecycle

3. Make your app modular

4. Defence Against Common Error

5. Prevents from having boilerplate codes

Before Android Architecture Component, the developer finds difficult to handle the application development. It could be tough to resolve the issue, which needs a new code to maintain development.

Example:

If the user changes the device orientation from portrait to landscape or vice versa, the developer has to save that instance every time.

Let's discuss here regarding Lifecycle, ViewModel, LiveData, and Room Architecture Components. Google has introduced new components, like Navigation, Paging, WorkManager, and much more.

Room:

This is a new SQLite object maps the library functions to process the database. It will check error at compile time and return queries directly with observable LiveData. Room will automatically convert your POJO object into the corresponding database tables and back again

To set up the table using Room, define a Plain Old Java Object. Mark the POJO with @Entity. Every POJO needs a Database Access Object (DAO).

Example

@Entity() data class Employee( public @PrimaryKey String id; public String name; ... ) @Dao public interface EmployeeDao { @Query("SELECT * FROM Employee") public List findAllEmployee(); @Insert(onConflict = IGNORE) void addEmployee(Employee employee) @Query("DELETE FROM Employee") void deleteAll(); //... other operations }

LiveData with Room:

Use LiveData with Room to monitor changes in the Database. It's an observable data holder that holds the data and notify you when the data changes by updating the UI.

Basically, it will wrap into the object and allow UI to automatically update whenever properties of the user object change.

LiveData is lifecycle aware component.

Example

@Query("SELECT * FROM Employee") public LiveData> findAllEmployee(); Update the UI using LiveData and Room employeeLiveData.observe(this, employees -> { //update UI in case RecyclerView mEmployeeRecyclerAdapter.replceItems(employees); mEmployeeRecyclerAdapter.notifyDataSetChanged(); })

What are Lifecycle aware components?

The magic of LifeCycle observation is, LiveData knows when your activity is

1. On screen

2. Offscreen

3. Destroyed

If the activity is non-active, it doesn't send a database update to UI.

There are two interfaces; Lifecycle Owners and Lifecycle Observer.

Lifecycle Owners are objects with lifecycle like fragment and activity. On the other hand Lifecycle Observer, notify the changes by observing Lifecycle Owners.

Example

MyLibraryClass implements LifecycleObserver { @OnLifecycleEvent(Lifecycle.Event.ON_START) void startup(){ .... } @OnLifecycleEvent(Lifecycle.Event.ON_STOP) void cleanup(){ .... } }

ViewModel:

It's designed to hold the data that's related to the UI, maintaining its integrity during configuration changes like screen rotate. The main thing is ViewModel doesn't need to make new calls to the Repository after configuration changes, which optimize the code.

Example:

public class EmployeeViewModel extends AndroidViewModel { private AppDatabase mDatabase; private LiveData> employees; Public EmployeeViewModel(Application application ) { super(application) mDatabase = AppDatabase.getDb(getApplication()); employees = mDatabase.employeeModel().findAllEmployee(); } //Getter and setter } //in Activity onCreate method employeeViewModel = ViewModelProviders.of(this) get(EmployeeViewModel.class); //get a reference to the ViewModel and use it. employeeViewModel.getEmployee().observe(this, employee -> { mEmployeeRecyclerAdapter.replaceItems(employee); mEmployeeRecyclerAdapter.notifyDatasetChanged(); });