[MUSIC PLAYING]
CHET HAASE: Hi, and welcome to "Now in Android,"
episode number 16.
Let's get into this and see what happened
the last couple of weeks.
First of all, AndroidX releases-- pretty much
every time, there's a bunch of releases.
This time, there were a couple of stable releases, mostly
bug fixes.
So check out Navigation 2.2.2 and Preference 1.1.1
for those stable versions.
There were a ton of alpha, and beta, and RC releases,
so check those out to see exactly what came out there.
The two that I want to call out in particular
are about animation, partly because I love animation,
but also because it's sort of interesting--
the history that resulted in these.
So first of all, there's a backport of the Animator APIs
into AndroidX.
And you may be asking yourself, why do we do this?
After all, the Animator APIs date way back to Honeycomb 3.0,
and the view property animator stuff was 3.2.
All that stuff is way in history.
Why do we need it in AndroidX, which doesn't even
go back that far?
It's because of the other library that came out,
which is Vectordrawable-Seekable.
So what we wanted to do, what developers wanted us to do,
for years was provide them the capability
of programmatically setting the time of a VectorDrawable
animation.
So instead of just saying start, and then
it runs, what they wanted to do was actually pause it
along the way, resume it, and even programmatically set
the time set, the fraction of animation
that it's going to go to, which is a great idea.
But it depended upon platform capabilities
that were not introduced until later,
and so we really couldn't put it in AndroidX
because it didn't have the platform capabilities to depend
on.
So what we needed to do was pull out all the Animator stuff
into this unbundled library, along with all of the bug fixes
and API enhancements that we've had over the years,
and then Vectordrawable-Seekable could depend on those changes,
instead.
So we released two of those.
One of them is Core-Animation 1.0.0, as well as
Vectordrawable-Seekable 1.0.0.
These are both alpha releases.
On the other hand, they depend on long-term capabilities
from the platform, so they're certainly not
as new as some things that you may find in an alpha 1 state.
But check those out.
If you've been waiting for that capability,
please try that out.
We have also come out with lots of articles and videos
along the way.
First of all, in the data space, Murat Yener
has released an article on the new Database Inspector.
This is in Android Studio 4.1 canary level 6.
So with this tool, you can see what's
going on with your database.
So if you're using SQLite directly or through Room,
you can actually see what's going on with the data.
You can do live updates in the tool
or you can also even make changes in the tool
and see live updates in the app itself,
especially if you're observing on that data
using the Room APIs.
We had another Kotlin vocabulary article posted by Meghan Mehta.
And this one is about operator overloading.
So this is a capability that was not in the Java programming
language, but is in the Kotlin programming language,
because it can be.
This is a convenience that makes your code more
readable for some cases where it's really easier to read code
that is showing exactly what the operation is,
instead of calling a function.
So for example, if you have two Point objects
or if you have two Matrix objects,
it's kind of logical to be able to see in the code
that you are adding these things together or multiplying them
with the operators, like add and multiply.
So through operator overloading in Kotlin,
you can use things like overloads of plus,
and minus, and multiply, or plus plus, or even access things
like square brackets, or comparison operators,
like less than or greater than.
So the article goes into details on how this stuff works
under the hood, as well as when to use
it, as well as some cases where you don't want to use it.
There was also an article on Material Design Components
and how to migrate your app to the latest, greatest stuff.
So Nick Rout posted this article on the 1.1.0 Material
Design Components library, as well as lots of information
on migrating.
So if you are currently using the old Design Support library,
the recommendation is to first migrate to MDC 1.0.0.
That will get you up into AndroidX world.
And then migrate to 1.1.1.
Sorry, 1.1.0.
When you do migrate to that, you'll
get new features like dark theme,
full Material theming for things like color and typography,
as well as shapes, and new widgets
like the extended floating action button and the date
picker, and lots of accessibility improvements
and bug fixes along the way.
There are tons of links in there to further resources
not just on migration, but also Material Design
Components in general.
And there's also a video version of the article embedded
directly in that article.
So check out all of that and migrate your stuff.
One Tap was an article posted by Sean
McQuillan about the new One Tap API for authenticating users.
It turns out that a lot of users sort of drop off of apps
at the point where they are being asked to authenticate,
either to sign in or to sign up for your services,
because sometimes, that can be a confusing, error-prone,
and frustrating experience.
So One Tap aims to make that easier and smoother
for the users, and therefore retain more users
in your application, which is probably what you want.
So check out that article for information on that new API.
In the LiveData space, Jose Alcérreca posted another couple
of screencasts--
it's actually a two-part video.
Part one is one-shot Operations that
shows how to use the LiveData coroutine builder, which
is an extension function or a set of extension
functions in KTX, to save on a bunch of boilerplate code
for doing the things that you want to do, anyway.
Part two builds on that same capability,
and then shows how to use SwitchMap
for passing parameters with live and dynamic data
that's going to be updated.
There was also a bunch of sample code posted.
First of all, on the Location side,
we've made a bunch of changes to Location
in the last few releases, specifically
around user privacy, and sharing of user data,
and making it clear when the user's location is being
accessed and when it is appropriate or inappropriate
to do so.
And then developers need to react to these changes
because let's do the right things for users.
But sometimes, it can be tricky to understand
exactly what the right thing is or what the best practices are.
So Jeremy Walker has rewritten the codelab
that we have for Android Location
to have more detailed instructions on how
to do this stuff and include best
practices for the new policy changes
that we've had over the last couple of releases.
It also includes some support for the new Android 11
restrictions.
So if you're getting up to speed on Android 11,
you'll want to pay attention to that.
And it covers the most common use case,
which is actually getting the location when the app is
in the foreground, when either the user is using
the application or there's at least a foreground
notification that gives it that visibility to the user
that this is going on.
It is not best practice, actually,
to retrieve location while the application is
in the background.
There are some specific use cases where that is required.
So if your application actually does need that use case,
then Jeremy also updated the sample
that we have to show the best practice for how
to do that in the proper way.
In the accessibility area, Shailen Tuli
created a couple of codelabs to show
how to make your application more accessible.
So it turns out that if you use the standard widgets
in the platform-- things like button--
then we generally do the right thing for developers.
So a lot of accessibility capabilities
just come for free.
It's when you're using custom widgets
that you may run into problems.
But more importantly, maybe you're running into problems,
and if you're not testing for it, then
maybe you're not even aware of it.
So there are two codelabs.
One shows you how to identify the problems,
and then what the generally easy fixes are for those problems.
And then the second codelab is about building
testing infrastructure.
So why go to the trouble of actually making
your app accessible if you don't also
build in the automatic testing infrastructure that makes sure
that your app stays accessible over time with future changes?
So the next codelab talks about how
to integrate accessibility testing into the existing
Espresso tests that you have.
And then finally, we've had a couple
of "ADB" podcasts that are posted since the last "Now
in Android."
First of all, there was "ADB" 136, where it was just
a casual chat between me, and Romain, and Tor,
and we talked about the changes that a lot of developers
have had over the last few weeks as we've
shifted to working-from-home full-time thing.
So just chatting about the tools and the techniques
that we personally are using, and having a conversation,
because isn't that what we all should be doing
in these work-from-home times?
And then finally, ADB 137 just came out.
It's accessibility, strangely enough and coincidentally,
also talking about how to make your apps, and apps in general,
more accessible.
We talked to Qasid Sadiq and Sally Yuen
from the accessibility team about what their team does,
the frameworks that they work on for enabling accessibility
and accessibility frameworks and functionality in the platform
in general, as well as what app developers can
do to address the problems in their apps
to deal with what tends to be sort of a management
or organizational issue in making sure that accessibility
is a priority.
So check those out and check out everything else.
As usual, all of this information
is linked in the original article on Medium,
so check out "Now in Android Number 16"
in Android Developers publication on Medium.
And if you liked the video, go ahead and like and share,
and then subscribe to the Android Developers
channel on YouTube.
Thanks.
[MUSIC PLAYING]