Sep 19, 2019
Now in Android #4
Android 10, AndroidX stable libs, codelabs and samples, and View binding. It’s been a busy couple of weeks.
Android Dials It Up to 10
On one hand, shipping preview releases is great because we get important feedback on APIs and features and can improve things before we ship the final release.
On the other hand, preview releases make the actual launch of the OS slightly less exciting because everyone already knows what’s in it. It’s like unwrapping a present that someone wrapped right in front of you; there’s just not a lot of surprise.
But there is a feeling of satisfaction, knowing that the thing is done, we can count on all of the APIs for real and build our apps against it, with the added advantage of having the source code available. And, of course, now users are going to start getting and using this release.
Android 10 was released last week — open source, developer downloads, and all — with the final versions of all of the features that we’ve been working on: gesture navigation, privacy features, live caption, smart replies in notifications, dark theme, ART optimizations, and more! Check out the overview in the Android Developers Blog article, or just go straight to the developer site to get the extended docs and the downloads.
Stable Full of Stables
A veritable plethora of AndroidX libraries just went stable, including many of the fundamental modules as well as some of the architecture components and media libraries. Just check out that long list to the left ⬅︎.
AndroidX Versions, Categorized!
My favorite AndroidX versions page has gotten more useful recently. For those of you that only care about stable versions (or those that only want to know what’s bleeding-edge alpha new), there are links at the top to filter the information for you. For example, if you want to know about the plethora of stable libraries mentioned above, just click on that Stable link on the top-right of that page and you’ll see a list like the one in the previous item on stable releases.
The Great Samples Migration
Organizing code is a bit like organizing a household: It starts out well with a logical place for everything, and a few years later the butter dish is on a shelf in the garage, the stapler is next to the sugar bowl, and the holiday decorations are up all year because they no longer have a place to live.
Our Android samples were a bit like that household; organization didn’t matter so much when we started out, but after a couple hundred projects, things got a bit messy.
Jeremy Walker has cleaned up our Android samples significantly. Now you should be able to find them in a single place, github.com/android. Even better, they’re now organized into 17 group repos to make it easier to find samples in related areas. Also, the new system allows us to take pull requests if you want to contribute fixes (the old system, for historical and not very interesting reasons, didn’t accept fixes because the external version was downstream of an internal version).
The migration project isn’t quite done yet, but so far we’ve moved 127 out of 136 total; the rest will land in the next few weeks.
Check out Jeremy’s article for the details.
Java-Friendly Kotlin Codelab
One of the reasons why Kotlin has become so popular for Android developers (besides the part where it’s a nice language) is its great interoperability with the Java programming language. After all, most Android developers have existing code bases, and the Android SDK is a set of Java APIs, so smooth integration between the languages is pretty important.
But there are some things to be aware of when adding Kotlin code which will make future use of Java code easier. Which is why Nicole Borrelli published a codelab recently to help Kotlin developers that want to ensure smooth interaction with Java code.
View binding
Programmers hate boilerplate code. We only have a finite number of characters we get to type during our lifetimes; why waste those clicks on unnecessary syntax and expressions?
One of the ongoing repositories of boilerplate code in Android development that annoys developers is findViewById(). Whenever you want a reference to a view in the hierarchy, you have to use the right view ID and repeat the type info.
You end up writing something like this:
var b: Button = findViewById(R.id.button23)
// or
var b = findViewById<Button>(R.id.button23)
// or even
var b = findViewById(R.id.button23) as Button… which isn’t a lot of code, but it adds up when you have to do it for every view everywhere.
A popular workaround for this verbosity is found in the library ButterKnife, which allows you to annotate variables like this instead:
@BindView(R.id.button23)
lateinit var button: ButtonPeople also use Data Binding to achieve a similar effect, essentially creating a variable for the view in the binding object associated with the layout file.
Back at Google I/O 2019, we talked about a new mechanism that Jake Wharton was working on, called View binding. View binding is closer to data binding, avoiding the annotation processing approach of ButterKnife. In Jake’s words, “It’s a middle-ground between findViewById and full-on data binding.”
To use View binding, you first need to enable it in your gradle build:
android {
viewBinding.enabled = true
}Then, in your code, you can get a reference to a binding object and refer to views as fields on that binding object. This works similarly to how it does with data binding, but without the need for a specialized data resource file; you just use the normal XML layout file.
View binding is now available as of Android Studio 3.6 Canary 11. You can also read more about View binding here.
Now then…
That’s it for this time. Go download the final bits for Android 10! Play with the latest stable AndroidX libraries! Check out the samples on Github and submit a pull request! Mess around with View binding and the Android Studio 3.6 canary build! And come back here soon for the next update from the Android developer universe.
