The CommonsBlog


"Elements of Android Jetpack" Version 0.5 Released

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

This update adds two new chapters:

It also updates everything for Android Studio 3.5, adds some Android 10 notes, updates many of the dependencies used in the book, and fixes lots of bugs.

Sep 09, 2019


Introducing AndroidX Tech

AndroidX Tech (https://androidx.tech) is a site that I am maintaining that contains additional information about the various androidx libraries, beyond what is offered in the official documentation. It arose from a variety of frustrations when trying to use these libraries and classes.

For example, earlier this week, I wanted to know when saved-state support was added to the ViewModel classes. I knew that it involved the SavedStateHandle class, but the official documentation does not show the artifact that this class resides in, let alone any version information about that artifact (e.g., when was this class added?). In some cases, the release notes help, and a search of the lifecycle release notes would turn up some information. That’s not a reliable solution, though, as not everything gets mentioned in release notes.

Instead, I went to the AndroidX Tech page for the androidx.lifecycle package. There, every class that has appeared in that package is listed, along with the artifact and versions. There, we can see that SavedStateHandle was introduced in androidx.lifecycle:lifecycle-viewmodel-savedstate:1.0.0-alpha01 and the most recent version is androidx.lifecycle:lifecycle-viewmodel-savedstate:1.0.0-alpha03.

In addition to lists of classes and their associated artifacts, I have:

  • Pages per artifact, including:
    • Links to the release notes
    • Links to details about each artifact version
    • Links to documentation, articles, samples, and so forth, that I am manually collecting (though I’m only a tiny way through all of the artifacts at this point)
    • Some notes about the role of the artifact, for artifacts that you are likely to use directly
  • Pages per artifact version, including:
    • The release date
    • The SHA-256 checksum of the AAR that I am seeing
    • The minimum and target SDK version information
    • Any permissions that the artifact requires
    • The transitive dependencies that the artifact requires
    • Links to each of the source files found in that artifact version
  • Formatted source for every source file from every artifact version
  • Blog-style posts for new artifacts and versions that I am seeing, including an Atom feed

In addition to building out the manually-curated content and updating the site for new artifacts and versions, I am still working on the site layout. The site is built using MkDocs, which is a nice tool that does not scale to thousands of pages very well. So, I will be rebuilding this in some other static site generator eventually, though I will be keeping the existing URL structure.

If there are other bits of information that you think would be useful on this site — whether it is automatically built from the AARs and POMs or manually added — let me know!. Similarly, if you encounter any problems with the site, tell me!. If you have content about AndroidX that you would like to contribute, the curated content GitLab repo has details about that.

Aug 22, 2019


Android Studio 3.5 Upgrade XML Reformatting Problems

If you upgrade Android Studio 3.4 to 3.5, you may run into a problem where reformatting an XML file (e.g., via Ctrl-Alt-L) reorders the XML elements in each level of the hierarchy. So, for example, you might have a <uses-permission> before <application> in your <manifest> element; reformatting would flip the order of those elements. It seems to be alphabetizing them.

For the manifest, this might almost be survivable. However, lots of things in Android are dependent upon XML element order, such as the children of a LinearLayout, the children of <menu>, the children of <layer-list>, and so on.

The original issue for this appears to be this one. It is marked as “fixed”, though that appears to be overly optimistic. A number of developers are running into the problem, filing other issues and asking Stack Overflow questions. I ran into it myself in my “daily driver” Android Studio setup.

Based on some experiments, the problem seems to be limited to upgraders. I cannot reproduce the effect with a fresh Android Studio 3.5 installation.

The simple fix is outlined in the aforementioned Stack Overflow question:

  • Go into the Settings screen (File > Settings, or Apple > Settings, depending on your OS)

  • Navigate into Editor > Code Style > XML

  • In the upper-right of that dialog, choose Set From > Predefined Style > Android

The real problem lies in the “Arrangement” tab in that XML code style screen. After an upgrade from 3.4 to 3.5, you wind up with arrangement rules like these:

Broken Android Studio 3.5 XML Arrangement Rules

There may be a more surgical fix that can be applied to those rules, editing each of them to limit them to attributes, but I have not tried this. Applying the Android predefined style replaces the buggy post-upgrade rules with valid rules:

Repaired Android Studio 3.5 XML Arrangement Rules

Because the problem lies with an upgrade, it might be tricky for Google to fix it with yet another upgrade to some future 3.5.1 version. With luck, they’ll find a solution.

Regardless, when you upgrade to Android Studio 3.5 from 3.4, double-check these arrangement rules and fix them if they appear broken.

Many thanks to Birju Vachhani for his writeup of the steps to fix the problem!

Aug 21, 2019


"Elements of Kotlin Coroutines Version 0.1 Released

Subscribers now have access to Version 0.1 of Elements of Kotlin Coroutines, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page to download it, or set up an account and subscribe!


Originally, I thought that I would just have a chapter on basic coroutines in Elements of Kotlin. However, I quickly realized that to cover enough for Android app developers, I would need a lot more than just one chapter. Elements of Kotlin Coroutines is the result.

As with all my 0.x editions, this one is partially complete, with a number of placeholders for future chapters. However, it covers the basics of coroutines, including suspend functions and Flow. It also includes a “hands-on” appendix that walks you through converting a small RxJava-based app to use coroutines. And most of the samples are in the Klassbook, so you can run and modify them from the comfort of your favorite Web browser.

This book will get updated every month or two for a while, as I flesh out the remaining material.

Aug 19, 2019


Enabling Type Hints in Android Studio

Android Studio offers type hints for Kotlin code. Basically, the IDE adds “fake” type declarations where your code does not have them, for places where the compiler is inferring the type:

Type Hints in Android Studio

The types with the gray backgrounds (e.g., PackageInstaller) are added by the IDE. Other types (e.g., Uri) are really there in the typed-in code.

This can be handy for helping to ensure that your types are being inferred the way that you expect. They are also good for educational scenarios, such as conference presentations, to help make the implicit more explicit for people spending a limited amount of time in the code.

I got these by default with IntelliJ IDEA, and I wanted to enable them on Android Studio, particularly for tomorrow’s Android Summit workshop. This is possible, but you have to dig a bit in Settings to find them. Or, you can stumble across a helpful Stack Overflow answer.

In Settings > Editor > General > Appearance, you need to check “Show parameter name hints”:

Type Hints Setting in Android Studio

Then, click the adjacent “Configure…” button and choose Kotlin from the “Language” drop-down in the resulting dialog:

Kotlin Type Hints Configuration in Android Studio

The “Options” set of checkboxes are where you indicate the scenarios in which you want the type hints to show up. The large text field above those checkboxes are a blacklist, indicating situations where the IDE will skip the type hints, even if they otherwise would qualify based on your “Options” choices.

Aug 13, 2019


Older Posts