Dec 5, 2017

Android Architecture Components

Near the start of November, the Google team finally hit the 1.0 stable release of its architecture components. Originally announced at Google IO 2017, these components were designed to allow Android developers to create maintainable and easily testable code. The new ViewModel class allows developers to remove logic from their Activity/Fragment so it can be reused across the application and decoupled from the views. This creates a better experience when writing unit tests. Along with the new ViewModel class comes LiveData. LiveData is a great way to take an observable and manage it in a life-cycle conscious way. For example, all Android developers know the pain of handling saving and restoring data on a rotation change. With LiveData, the responses received from network calls persist across Activity/Fragment OnDestroy and OnCreate, which saves time and effort without having to suffer this Android development obstacle.

Below I will cover examples with ViewModel and LiveData. Keep in mind that there are other classes released under Architecture Components, and I encourage you to explore them all.


The ViewModel class is a life-cycle conscious way to manage data you would normally want decoupled from your Activity/Fragment. This means your data is not lost in the usual life-cycle destroy/create when your phone does a configuration change, such as an orientation change. To get started with adding ViewModel, you must first add:

implementation "android.arch.lifecycle:extensions:1.0.0"

to your application build.gradle file.

From there, we can create a class that extends ViewModel like so:

Keeping data in this ViewModel class allows the developer to not only decouple logic from the Activity/Fragment (which makes creating unit tests easier), but to also save the developer from writing boiler plate code to save/restore data on configuration change.

A basic (though incomplete) implementation of a ViewModel class might look something like this:

Once we are happy with our ViewModel and how the data is stored there, we can access it from our Activity/Fragment like this:

The ViewModel is a great resource to store data, however it would be remiss of us to not consider wrapping data stored in our ViewModel with LiveData.


The benefits of using LiveData are listed extensively on the Google Developer site, so I will shamelessly copy and paste from there:


Ensures your UI matches your data state
LiveData follows the observer pattern. LiveData notifies Observer objects when the lifecycle state changes. You can consolidate your code to update the UI in these Observer objects. Instead of updating the UI every time the app data changes, your observer can update the UI every time there’s a change.

No memory leaks
Observers are bound to Lifecycle objects and clean up after themselves when their associated lifecycle is destroyed.

No crashes due to stopped activities
If the observer’s lifecycle is inactive, such as in the case of an activity in the back stack, then it doesn’t receive any LiveData events.

No more manual lifecycle handling
UI components just observe relevant data and don’t stop or resume observation. LiveData automatically manages all of this since it’s aware of the relevant lifecycle status changes while observing.

Always up to date data
If a lifecycle becomes inactive, it receives the latest data upon becoming active again. For example, an activity that was in the background receives the latest data right after it returns to the foreground.

Proper configuration changes
If an activity or fragment is recreated due to a configuration change, like device rotation, it immediately receives the latest available data.


LiveData and ViewModel work hand in hand. It’s almost like they were designed to work together! If we want to modify our previous example from ViewModel to use LiveData, it might look something like this:

Wrapping our data with LiveData allows us to observe the data in a life-cycle conscious way in our Activity/Fragment like this:

Now that our list of users is wrapped with LiveData, we are able to observe any changes to our user list. This means our User Interface (UI) and our data will never be out of sync!


ViewModel and LiveData work well together and help the developer write safer, more manageable, and more easily tested code. For further reading on LiveData, ViewModel, or any of the other Architecture components released by Google, please have a look at the reference section below.


About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]