Introduction to Android Architecture Components
Content
Abstract
During Google I/O 2017, Android Team did an excellent move by announcing architecture components and guidelines for building an Android app.
I’ll be writing series of articles exploring the components, understanding the purpose, how to use and little bit of working internals of them. Lastly we will build a sample app to fully understand and get your hands dirty using architecture components in your app.
TL;DR
Previously I haven’t used any other architecture pattern like MVP, MVVM or clean architecture while building my Android apps but when I first saw “Architecture Components announcement at I/O”. I immediately got excited and could imagine how useful and interesting they would be.
Why there was a need of Architecture Components?
How many of you previously wrote all of your code in
Activity?
Almost everyone did at least once! Right?
Android framework allows the freedom to do it. But later we realized the problems of doing the above scenario, to the rescue came different architecture patterns like MVP, MVVM which made writing robust and testable easy still there was no such single official direction from Android Team. Moreover we as developers love to fight on which is better.
Until the Android Team realized that they need to take a clear stand on it and tell us how apps should be built, result of which is release of guidelines and components.
What are the Architecture Components?
A new collection of libraries that help you design robust, testable, and maintainable apps. Start with classes for managing your UI component lifecycle and handling data persistence.
In a nutshell these set of libraries will help us address common issues of configuration change, memory leaks, writing testable apps, reduce the boiler plate code while maintaining the architecture.
Final architecture
The following are the components you can use them together or separately. In this article we will just have a overview of the components.
Lifecycle
Lifecycle provides classes and interfaces that let you build lifecycle-aware components — which are components that can automatically adjust their behavior based on the current lifecycle of an activity or fragment.
It is the component which allows other objects to observe the lifecycle. This component is used to add lifecycle awareness. It will be helpful for library makers to clear up their resources depending upon the lifecycle.
ViewModel
It is the component designed to store and manage UI-related data so that the data survives configuration changes such as screen rotations. It should never access your view hierarchy or hold a reference back to the Activity or the Fragment.
It has following responsibilities:
- It’s main responsibility is to manage the data for the UI
- It handles the communication between
Activity/Fragmentand rest of the application - Retains the data during the configuration change
This means our Activity or Fragment won’t have the responsibility of holding the data and it will contain UI related code only.
PS: ViewModel is lifecycle aware hence we don’t need to worry about clearing up stuff to prevent memory leaks.
LiveData
LiveData is a component which holds the value (data holder) and allows to observe for changes in the value. It is designed to hold the data of ViewHolder but it can also be used in sharing data in your application. It is lifecycle aware that means it is aware if the Activity is alive to receive the data or not preventing crashes.
Advantages of LiveData:
- Always up to date data
- Proper configuration change
- No memory leaks
Lifecycle — ViewModel — LiveData
Room
Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.
In short, it is an ORM for SQLite database which means you directly save objects into database and Room will do the heavy lifting of saving the object properly into the database. It
Advantages of Room:
- Compile-time verification of raw SQL queries.
- Eliminates the boilerplate code to convert between SQL queries and Java data objects.
- No need of writing Cursor or Loader
PS: It is important to note that with these new components you don’t need to delete your existing architecture and re-build your app with these new components. If you have something in place which works great for you then keep it. In case you found the components really cool then make a gradual move to them.
Conclusion
I hope the article gives you fair overview of the Architecture Components. In the next articles we will deep deeper into each component and finally use them all together.
These new Architecture components solve the common problems which developers face and relax the debate between which architecture pattern to use while building an Android app.
Lastly I feel this is how building Android app should have been since start. Better late than never we have these architecture components to build amazing apps
