Architecture Components / Lifecycle

Architecture Components: Lifecycle

Architecture Components were announced at Google I/O 2017 and provide some frameworks to help developers create more maintainable and more robust apps. The architecture components don’t specifically do anything which will prevent apps from crashing or otherwise misbehaving, but they offer some frameworks which encourages decoupled components within the app which should lead to better behaved app. In this series we’ll take a look at these components and see how we can benefit from them. In this first article we’ll take a look at lifecycle components.

In a recent article on LocationServices we had a Fragment implementation which was tightly coupled to the Play Services location provider. This is problematic because, if we need to use different location providers for different build variants then this tight coupling to our Fragment makes it difficult to abstract away. Architecture Components provides us with a new lifecycle framework which gives us the ability to invert the dependencies, so that our Fragment implementation is completely agnostic of the location provider.

To demonstrate how we can do this, we’ll create a project with two different location providers for different product flavors. One will use the Play Services location provider which we covered in the previous article, and the second will use a dummy provider which will always return the location of Vicarage Road Stadium (home of Watford Football Club).

Let’s first take a look at the build.gradle for our app module:

We define the two flavors named dummy and playServices; include the necessary lifecycle libraries and annotation processor; and include play-services-location but only for the playServices flavor.

We can then set up separate source trees for the two build flavors, each will contain its own LocationProvider implementation:

This is easy enough we can quite easily create this set up without any help from Architecture Components. Different location providers may have differing requirements as to where we need to hook them into the Fragment lifecycle. For the Play Services provider we want to kick off the registration early because it will be around 300ms until we get our first location update. However the dummy provider will be almost instantaneous. So we need to hook the Play Services implementation into onStart, whereas the dummy implementation will generate an immediate update, so we want to wait until later in the lifecycle (specifically onResume) to trigger it. Although this is a somewhat contrived example, different location providers may require different things to happen at different stages of the Fragment lifecycle.

One way of solving this would be to have the Fragment implementation make calls in to the LocationProvider at every lifecycle state transition. Then the LocationProvider is responsible for performing the necessary actions when certain lifecycle state transitions occur, but this requires us to add a bit of boilerplate to our Fragment implementation. If we then have other abstractions to external services, we need to start duplicating this for each of them.

This is where the Architecture Lifecycle Components can help us. They allow us to hook an external component, such as our LocationProvider, to the Fragment lifecycle with a minimum of code.

Let’s take a look at our LocationFragment implementation:

The first thing we must do is extend LifecycleFragment. This is a temporary measure while the Architecture Components library is not yet at a stable release. Once it has been released then the support library Fragment implementation will contain the necessary code and we need not bother with this.

We also implement LocationListener which is a callback interface which we’ll look at in a moment.

In onAttach() we create our LocationProvider instance which takes a Context, a Lifecycle, and an instance of LocationListener (which LocationFragment implements). The interesting one here is the Lifecycle – this is obtained from the getLifecycle() method, and it is this that is currently implemented in LifecycleFragment, but will move to Fragment once the library is fully released. The Lifecycle is an abstraction of the Fragment lifecycle and is what our LocationProvider uses to get notified of Fragment lifecycle state transitions.

Finally we implement the one method which is defined in LocationListener: updateLocation(). This will get called whenever our LocationProvider gets updated location data.

Let’s now take a look at the dummy LocationProvider implementation:

First we must implement LifecycleObserver to receive lifecycle callback. Next we need to register the class as an observer of the lifecycle. Finally we specify which lifecycle events we’re interested in using the @OnLifecycleEvent annotations, and the annotated methods will get called whenever those lifecycle events occur.

The PlayServices LocationProvider uses the same approach, but actually hooks up to different parts of the Fragment lifecycle:

So we have easily been able to hook up these different implementations to different parts of the Fragment lifecycle without having to leak any implementation specific in to the LocationFragment code.

If we consider what is going on internally, it’s pretty much the approach we looked at earlier: the Lifecycle object will make callbacks to any registered observers for every lifecycle state transition, and it is down to the individual observers to decide which ones they are interested in. However the additional code that we’ve had to add to the LocationFragment is actually pretty minimal, and this will reduce even further once the Architecture Components library is fully released and integrated with the Android framework.

While this certainly benefits us, there is actually a better way of doing it. I have quite deliberately done an initial implementation by hooking on to lifecycle events for two reasons: firstly, it is an important foundation for some of the principles which we’ll be covering later in this series; and, secondly, the lifecycle approach certainly is useful in some circumstances and is useful to know! In the next article we’ll take things a stage further, and see how we can further simplify our LocationFragment.

The source code for this article is available here.

Many thanks to Yiğit Boyar and Sebastiano Poggi for proof-reading services – this post would have been much worse without their input. Any errors or typos that remain are purely my fault!

© 2017, Mark Allison. All rights reserved.

Copyright © 2017 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at


  1. Hi Mark,
    Thanks for this nice series of articles. I have few questions:
    1. In do we need to explicitly call lifecycle.removeObserver() method? I am under impression that
    void unregisterObserver() {
    2. In what is the point of having “private final Context context;” variable?

    1. 1. I think it is best for the code that creates a reference to be responsible for releasing it. So I feel it is best practise to explicitly unregister.

      2. The context is used in registerForLocationUpdates() and getFusedLocationProviderClient()

    1. The articles are all released under license as defined here.

      You are more than welcome to translate the articles provided that you adhere to the terms of the license.

  2. Hello Mark ,
    I am a big fan of your writing . I am an android developer who thrives to learn new stuffs. I had made up my mind to learn reactive programming like rxJaxa , but before I got my hands dirty google Io came up with architect components. I looked into to , it was like have the same phylosopis just like the rxjava which is react to the change of data . Here I got confused if android provides us this robust library why do I need Rxjava , I am kind of thinking out loud . Can you please clear my confusions.

    Thanks in advance

    1. I’m not sure I understand what you’re asking. RxJava and the Architecture Components are two different technologies which address different problem domains. Although there are similarities in the concept of having ‘observable’ objects they are really not the same thing at all – but they do play nicely together.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.