My Hexaville
Spead the Word

Android Architecture Components

android architecture components

Hi, as follows from the previous post about a tricky Android life cycle bug, today we’re going to look at the latest memory leakage-free solution for handling Activity life cycles. That’s the new stuff that was introduced on Google I/O – Architecture Components.

This is an early alpha by the way, super fresh. From what I learned, they have a better solution for those areas: handling state restoration and making objects aware of Activity life cycles.

For example, currently none of your objects are aware of activity being destroyed. Which means that if they hold a link to that activity (it could be a View, Context, whatever) that activity won’t be garbage collected. Even though it was destroyed. That’s why you have those onPause/Stop/Destroy overridden callbacks to dispatch activity lifecycle evens to your objects. LocationManager, video media player and many more require you to handle that.


First of all you’ll need to add those dependencies

Device Rotation

If you have some data that you want to persist across device rotations – putting it to bundle when saving state and reading it after rotation is what you would do

And you ether save fields one by one or wrap them in some pojo which you have to make parcelable then.


I really like solution with ViewModel , especially well it works with Data Binding, which I always use. Let’s say you have a sign up screen, 5 inputs (EditTexts). With basic simple retrieve each time value from view you’ll have to get value in on saving state, on recreating it you set value for each EditText back and get value when signing up.

With Data Binding and warping inputs as pojo you kill two birds with one shot.

And that’s all the code for persisting data across rotations. As you see there’s binding.setUser method. I won’t go into details of Data Binding, will just say that you should definitely try it out. Lot’s of view related logic goes into XML which is very convenient.

And when you decide to sign up, your user pojo is up to date all the time with EditText inputs, you just put it into Retrofit body. We don’t call new keyword for creating User object as you might’ve noticed. It’s handled by library.

One more thing is of course you should make your pojo extend ViewModel

Lifecycle Aware Objects

This one is cool. There’s two core classes as far as I understand  – LifecycleOwner and LifecyclerObserver. You need to make your activity extend LifecycleActivity, which is a LifecycleOwner and then I have this demo observer

As you see this object knows about srart/stop activity events. It’s all about annotations, you can handle any events you want. Which means all that clean up code can be moved away from activities to libraries.


Both of the above mentioned elements are super awesome. Better late then never, right? The problem I see is that for now you’ll have to write your own wrappers for libraries, because I don’t think many of them will start applying arch libraries any time soon. Maybe later this year we’ll see some, when it’s in stable release.

Although if you reuse some libraries like location manager etc in different activities, then you’ll benefit already now by creating one LifecycleObserver wrapper and reusing it in all your activities. This will reduce number of duplicated code already.


OK, great stuff. Super exiting. For more details check here. Don’t forget to subscribe, follow me on Twitter, Facebook, G+ and share with friends!

About the Author Ihor Klimov

Formerly an Android developer, lately picked up some Flutter. This blog is everything that I find exciting about Android and Flutter development. Stay tuned and hope to see you again!