Mar 06, 2018

First Thoughts on Android Architecture Components 1.0

Blake Marley

Blake Marley

First Thoughts on Android Architecture Components 1.0

Managing asynchronous events around the lifecycles of activities and fragments is a hassle. The lack of standard practices and methodologies allow the uninitiated to make mistakes and land face first into some tricky “gotchas.” In the middle of a project, these “gotchas” can amount to an untenable solution and/or costly rework.

Even if, as an experienced Android developer, you’re aware of the pitfalls and understand what it takes to avoid them, you end up having to implement your own custom solutions. It’s something every Android developer has had to devote time to address, though it feels like much of what ends up being written should be provided out of the box. It’s a problem that has irked me ever since I ran into the pitfalls myself, and has made its way to the top of my list of Android woes. “Why wouldn’t the framework take care of this?” became a common refrain. I even went so far as to make an attempt at paving over some of the pitfalls in my own experimental library.

Solid Solutions From Android

Thank goodness the Android Framework team at Google has been listening. On Nov. 6, 2017, the Android Architecture Components were announced stable and officially released to the masses. Please take a minute to read the official announcement. The libraries themselves reside in distributed jar files and you’ll be able to use the lifecycle-aware components with Support Library versions 26.1.0 and later.

These libraries give us some solid solutions to the maladies that every Android developer has dealt with. On top of that, the team also provides a guide of best practices and describes how each of the pieces fit into the overall design. From the announcement: “These foundational components make it possible to write modular apps with less boilerplate code, so developers can focus on innovating instead of reinventing the wheel—and we hope to keep building on this foundation in the future.” I’m excited that they’re providing thought leadership, and I believe that this endeavor is going to greatly benefit the Android community going forward.

Exploring the Additions

I think there’s still plenty of room for an opinionated framework to tie together some of the concepts and reduce boilerplate even further. The following are some general opinions that I’ve formed after reading the guide and looking over the framework’s additions.

Lifecycle-Aware Components/LiveData

Lifecycle-aware components are going to reduce complexity quite a bit. I think they’ll be most effective in libraries, saving the consumer the hassle of registering/unregistering “correctly.” Their implementation in the LiveData class is likely going to supplant the use of RxJava, for most use cases. The LiveData guide gives a great list of advantages that can be gained from its use, so find a way to incorporate it into your app!

Side note, if anyone from Google is reading, some of the LiveData examples are confusing, notably:

@MainThread public static StockLiveData get(String symbol) {

Which is then called in an example by passing an Activity in place of a String:

@Override public void onActivityCreated(Bundle savedInstanceState) { StockLiveData.get(getActivity()).observe(this, price -> {


ViewModels bring us closer to a native, reactive design. I’m glad we have a native class that will act as a standard place to hold data for the view layers. My only dislike here is that observing the LiveData within these models feels like it might add a good bit of boilerplate. In a perfect world, I’d like to see the observers bind themselves, perhaps with a standardized way to reference the LiveData within the underlying views/layouts. I’d also like a standard, configurable way of caching data built into either the LiveData object or the ViewModel—rather than having to update/cache manually as shown in the examples. I’m planning to build an opinionated library to address some of what I’ve described above, so stay tuned!


I don’t have too much to say about the Room or Paging additions. Room provides offline caching benefits when applications are dealing with complex objects or query data often; however, it can be overkill when caching simpler, primitive data. There’s also this bit that I’d like to read more about, though the information seems pretty sparse. The general idea mirrors what I plan on building, albeit replacing Room with Retrofit. The Paging library will likely be the last feature of these components that I get around to experimenting with, but if you need to display large data sets, definitely give the overview a read.

Final Thoughts

So far I have yet to implement or use these components, but I’m looking forward to their potential. If you disagree, or you have any questions, thoughts, etc., leave a comment and let’s start a discussion! If you’re looking to work with some talented people on challenging projects, Credera is hiring. And last, but not least, if you need help building or designing a mobile solution that makes sense for your company, don’t hesitate to reach out!

Conversation Icon

Contact Us

Ready to achieve your vision? We're here to help.

We'd love to start a conversation. Fill out the form and we'll connect you with the right person.

Searching for a new career?

View job openings