[MUSIC PLAYING]
CHET HAASE: Welcome to "Now in Android," episode number 30.
First off, MAD Skills, we keep on rolling
through more and more content.
We are still playing through some app bundle stuff, which I
think I talked about last time.
So there's been the finish of that series.
So we had a tip from a Google Developer Expert,
followed by a live and recorded Q&A
with me asking some questions.
And then we had Ben Weiss and Wojtek Kalicinski and Yuri
Makhno providing actual answers for those.
So you can check that out to find out
some questions and answers in the app bundle space.
After that, last week we started publishing a new series
on Material Design Components.
First up, episode from Nick Butcher
talking about why we recommend using Material Design
Components, and giving an overview of some
of the capabilities of MDC, including
theming support, built-in transitions, and the components
themselves, that make it much easier
to take that design guidance that we provide
and actually encapsulate it into components that you can just
plug and play in your application.
Next episode was from Nick Rout talking about how
to do Material Theming.
And he walked through the Material Theme Builder sample
app to show you how to use and customize
themes in your application.
Both of these, actually all of these,
are also accompanied with articles on various related
topics.
And those are linked as usual.
This week, Chris Banes posted an episode
on creating a dark theme with MDC.
And that uses both Android 10's Force Dark feature,
as well as MDC's DayNight theme that you can then
use as well as customize.
We have more MDC content coming this week, probably
around the time that you are watching this video, as well
as next week.
We will again have a live Q&A with me asking some
Q's and other people hopefully supplying some A's.
For our ongoing content in MAD, just
check out the playlist on YouTube,
as well as the articles on "Medium."
And there's also a landing page for all things modern Android
development, including MAD Skills.
Finally-- next, not finally--
app bundles and target API requirements.
So we have mentioned this before,
that app bundles in late next year
will become a requirement for new applications.
And now we've gotten specific about timing of that,
as well as specific about target API requirements
as we continue to increment that into the future.
So the specifics were covered in an article by Hoi Lam.
And very briefly, in August of next year, all of this
is for new apps, so new apps will
need to target API level 30.
New apps will also need to use app bundles for distributing,
for uploading to the Play Store.
And new apps will also, if you have assets or features that
are over 150 megabytes, you will need
to deliver them via Play Asset Delivery
and/or Play Feature Delivery.
Note that extension files, OBBs, will no longer be
supported for new applications.
And then in November of next year, November of 2021,
app updates will also need to target API level 30.
Documentation.
There were a couple of important documentation
updates on d.android.com.
First of all, Fragments.
The team did a substantial rewrite
of all of that documentation to help you understand
both how things work, as well as best practices for using
Fragments.
This includes things like up to date guidance,
life cycles, states, testing with Fragments,
and much, much more.
So check out the new guides as well as
the subsections of those.
Also, if you want more information,
a little annotated guide to what each of those changes were,
Ian Lake, who's been working on actually fixing
a lot of this stuff as well as helping document it,
annotated what those changes were in his Twitter feed,
so you can check that out.
Also, Kotlin Flows, we provided an entirely new guide,
new documentation there to help you
understand how to use the basics of the Kotlin Flow feature.
And this includes everything from testing
to using the new State Flow, as well as shared Flow APIs.
Articles, speaking of articles and videos,
we have tons and tons of those available,
starting with-- so I wrote a guide
on testing startup performance.
So for something I've been working on recently,
which I will be posting additional articles
for in the next couple of weeks, I really
wanted to get good automated measurement of startup time
for a particular application.
I wanted to run it lots of times and then time those
durations and do A/B comparisons with other runs.
And it wasn't obvious how to do that,
so I chased down the details of one approach
to doing that, including running a shell script in the A to B
shell, as well as how to lock the clocks to make
your timings more consistent, as well as
just how to derive that information from the system.
Because we are tracking startup time in the system.
We issue it to the log and I go over all the details
of how to get that information if you want
to track your startup performance, which
is an important step toward improving your startup
performance.
There was a new article from Manuel Vivo
on migrating from Dagger to Hilt,
trying to answer the question of whether you should do this.
If you're already using Dagger, should you
spend the effort on your team to actually migrate?
And there are several reasons to do so.
But it kind of depends on your situation.
So he covers all this information
in the article, including advantages
for doing so if they apply to you,
such as good testing of the APIs,
consistency in approach to dependency injection,
as well as integration with various AndroidX extensions
that we have.
Speaking of Hilt, we also have a Getting Started guide that
was published by Filip Stanis.
He posted this article to help developers spin up on this
and get going on Hilt in your application.
And this article is even for developers
that may not have any prior experience
in dependency injection or in Dagger.
It's just about Hilt and dependency injection overall.
I should point out that the title of the article
could be a little misleading.
It's called "Getting Started in Hilt with Kotlin" or something.
That's really a reference to the fact
that the code snippets in the article are in Kotlin.
So it's certainly easy to understand as Kotlin developer
what's going on.
But actually, all of the techniques and technologies
talked about in the article are also
applicable to people using Java programming language.
So don't be misled by the title.
If you're a Kotlin developer, great.
If you're not a Kotlin developer, also great.
Check out the article.
Going with the Flow, Manuel Vivo published a new video.
So I talked about the earlier documentation on Flow,
but we also have a video to help you understand
how to get started with Flow.
We use Kotlin Flow for emitting streams
of data related to coroutines, but coroutines basically
can return a value.
You use Flow for actually returning a series of values
that you can then act on.
It builds on a previous video that I
think I talked about in "Now in Android"
in a previous episode called "The ABC's of Coroutines."
So you might want to check that out first and then
get in the Flow.
Kotlin extensions, there's a new article
published by David Weiner that talks specifically
about view binding versus Kotlin synthetic.
So Kotlin synthetics was introduced as a mechanism
to make it easier to avoid all the boilerplate
and tedious of calling findView by ID to find
that view in your hierarchy.
View binding is the new approach to doing that.
And synthetics will be deprecated in a later version
of the Kotlin Android plugin.
So this is sort of a heads up that that is going to happen.
You should really be using view binding
instead for various reasons that are covered in the article.
Also, the article discusses the use of the parcelize extension,
which is still perfectly supported
and will continue to be recommended and supported
going forward.
Finally, background location.
We've been making a lot of behavior changes
in the platform over the last several releases,
specifically around user data and making it easier
to understand for users who has access to their data,
and whether they should have access to that data.
Sort of increasing the transparency, as well as
their level of control over how the data is used.
One of the major areas ongoing in the last several releases
that we're buttoning down is in location.
The user may want to know why your application needs access
to that location, and they may not
agree that you need access to their location.
They really want to keep that data private.
So there is a new Google Play policy
that will soon require that apps that need location
while they are in the background, actually
need to get permission for doing that.
They need to request permission from the Play Store
for doing that.
And this article covers all the details,
makes it more transparent how to get that, what the process is,
so go check that out for that information.
And check out the "Medium" article version
of "Now on Android" 30 for all the links of everything
that I talked about.
And if you like the video, go ahead and like and share,
and subscribe to the Android Developers Channel on YouTube.
Thanks.