The CommonsBlog


Making Sense of the Architecture Components Versions

A new version of the Architecture Components was released today.

Well, OK, actually, three versions of the Architecture Components were released today.

Though, in truth, it’s more like the Architecture Components have undergone mitosis, with different component cells going their own way with respect to version numbers and versioning systems.

Confused yet?

“Iceberg, Right Ahead!”

When we depend upon artifacts like com.android.support:support-v4 or android.arch.persistence.room:runtime:1.0.0-alpha9-1, we perceive the artifacts that show up in the dependencies roster in our Gradle build files. However, like an iceberg, we are only seeing a fraction of the actual artifacts, with the rest being pulled in via transitive dependencies.

And, when it comes to Android libraries from Google, those transitive dependencies frequently are undocumented.

In general, that lack of documentation isn’t usually a problem. Sometimes it is, and it is the source of some of the confusion around today’s release(s).

Specifically, when we depend upon android.arch.lifecycle:runtime, there is a transitive dependency on android.arch.lifecycle:common. And android.arch.lifecycle:common is undocumented.

So, What Went to 1.0.0?

The 1.0.0 Alpha 9-1 release notes state:

This is a major release where core lifecycle artifacts (runtime, common) and arch core (common) reach to stable version 1.0.0.

Exactly what reached “stable version 1.0.0” is undocumented, because the quoted passage refers to undocumented things.

Compounding the problem is that the documentation cites an artifact version (android.arch.lifecycle:runtime:1.0.0-alpha9-1) that does not exist, or at least is not being served by Google’s Maven repository. (UPDATE 2017-09-15: fixed now, points to android.arch.lifecycle:runtime:1.0.0)

The 26.1.0 support libraries (e.g., com.android.support:support-compat:26.1.0) depend upon android.arch.lifecycle:runtime:1.0.0, which in turn depends upon the undocumented android.arch.lifecycle:common:1.0.0. So, those two artifacts are at a stable 1.0.0 version.

Near as I can tell, nothing else of the “classic” Architecture Components are at a 1.0.0 just yet. The artifacts that I tested all resolved to a 1.0.0-alpha9-1 version. So, for example, android.arch.lifecycle:extensions:1.0.0-alpha9-1 depends upon android.arch.lifecycle:runtime:1.0.0.

FWIW, there are also other undocumented artifacts, with disparate versions:

  • android.arch.core:common, where the current version seems to be 1.0.0

  • android.arch.core:runtime, where the current version seems to be 1.0.0-alpha9-1

These appear to be what the quoted passage refers to as “arch core”.

Enter Paging

The Architecture Components now have a new component: Paging. The release notes state that “Paging is released as alpha1 and will have its own release cycle.” Indeed, android.arch.paging:runtime:1.0.0-alpha1 does exist. It, in turn, depends upon an undocumented android.arch.paging:common:1.0.0-alpha1. But, at least those versions are in sync.

However, 1.0.0-alpha1 is not 1.0.0-alpha9, nor is it 1.0.0, so we have three different version numbers within the same family of artifacts.

FWIW, android.arch.paging:runtime:1.0.0-alpha1 and android.arch.paging:common:1.0.0-alpha1 depend upon a mishmash of 1.0.0 and 1.0.0-alpha9-1 dependencies from other libraries.


In the fullness of time, this will all get cleared up, in all likelihood. For now, it’s more than a bit confusing, requiring rummaging through POM files to see what is going on.

Sep 14, 2017


Android's Architecture Components Version 0.3 Released

Subscribers now have access to an update to Android’s Architecture Components, known as Version 0.3, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page and download away, or set up an account and subscribe!

This is a small update, bringing in two new chapters on RxJava in Room and packaging a Room database with your app. It also covers the current 1.0.0-alpha9 version of the Architecture Components, fixes a variety of errata, and makes other small improvements.

The next update to this book should come in early November or thereabouts.

Sep 13, 2017


GraphQL and Android Version 0.3 Released

Subscribers now have access to Version 0.3 of GraphQL and Android, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page and download away, or set up an account and subscribe!

In this update, there are… call it “one and a half” new chapters:

  • One on paginated GraphQL queries, using the Relay connection pattern, and how we can consume them in Android

  • One partial chapter on advanced Apollo-Android techniques

In addition:

  • All URLs in the samples and prose now point to 0.3/ instead of 0.2/ in their paths

  • The samples using Apollo-Android now use 0.4.0 of that library

  • There are a few errata fixes and the like.

The next update to this book should be out in 1-2 months.

Aug 30, 2017


Platform Resource Aliases

One of the reasons why I keep close tabs on Stack Overflow is that, every now and then, I’m reminded of a technique that I should be promoting more.

Today’s example of this comes from this question, where a developer inheriting an existing Android Studio project questioned why the project had a res/values/drawables.xml file that contains a bunch of <item> elements:

<resources xmlns:android="http://schemas.android.com/apk/res/android">
    <item name="ic_menu_camera" type="drawable">@android:drawable/ic_menu_camera</item>
    <item name="ic_menu_gallery" type="drawable">@android:drawable/ic_menu_gallery</item>
    <item name="ic_menu_slideshow" type="drawable">@android:drawable/ic_menu_slideshow</item>
    <item name="ic_menu_manage" type="drawable">@android:drawable/ic_menu_manage</item>
    <item name="ic_menu_share" type="drawable">@android:drawable/ic_menu_share</item>
    <item name="ic_menu_send" type="drawable">@android:drawable/ic_menu_send</item>
</resources>

What the original developer did was set up project aliases for platform resources.

There are lots of resources available in the Android SDK. You are welcome to refer to them directly if you want, such as @android:string/ok or android.R.color.black.

However, platform resources have two key problems:

  1. They tend to be very specific. android.R.color.black is a color resource that resolves to black. It should always be black.

  2. They might vary by Android version or even device manufacturer build. Some manufacturer, or even Google itself, might decide that orange is the new black and have android.R.color.black resolve to some shade of orange.

Ideally, you add a bit of indirection here, so that all of your Java code and other resources that today might use platform resources could switch tomorrow to some other implementation of those resources, without having to change all of the references to the resources.

Sometimes, we do this via styles and themes. However, that gets confusing, can be overkill, and does not necessarily cover all scenarios.

Resource aliases are another approach, the one taken by the original developer of the code from the Stack Overflow question. <item> elements, with type pointing to the type of resource, gives us indirection. With the above XML in a project, the project code and other resources can refer to R.drawable.ic_menu_share and such. Right now, the implementations of those drawables happen to be platform resources, by means of the <item> elements. However, later on, you could get rid of the <item> elements and add custom drawables as replacements. Nothing that refers to the resource needs to change, courtesy of the indirection.

Even in cases where you do not think that you will need to switch to a custom resource, using this sort of indirection technique lets you use logical resource names (e.g., R.color.divider instead of android.R.color.black, to make it easier for you to switch to android.R.color.holo_orange_dark later on without other code changes). Again, styles and themes may supplant the need for a lot of these aliases, but not everything belongs in a style resource.

Aug 22, 2017


Android's Architecture Components Version 0.2 Released

Subscribers now have access to an update to Android’s Architecture Components, known as Version 0.2, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page and download away, or set up an account and subscribe!

This is a small update, bringing in two new chapters on M:N relations in Room and LiveData transformations. It also covers the current 1.0.0-alpha8 version of the Architecture Components, fixes a variety of errata, and makes other small improvements.

The next update to this book should come in late September or thereabouts.

Aug 14, 2017


Older Posts