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.
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:
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.
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:
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:
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!
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.
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:
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”:
Then, click the adjacent “Configure…” button and choose Kotlin from the “Language” drop-down in the resulting dialog:
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.
