With the release of the Android M Developer Preview SDK,
developers are jumping in to make
sure their apps are up to date with changes in the framework.
I'm Wojtek Kalicinski, and I'll show you
how new features that we're introducing in Android Studio
1.3 can help you with the transition.
The single biggest change in Android M
is the overhaul of the permission system.
From now on, before using certain APIs,
you need to make sure your app asks
for the necessary permissions during runtime.
But given the large code base, how do you
know which methods actually require this special handling?
In Android Studio 1.3, we're adding a [? lint rule ?]
that detects methods marked with a new "requires
permissions" annotation from the support library.
The editor will now highlight code
that uses permissions which are missing from your Android
manifest.
Moreover, if it detects you haven't performed
the necessary runtime check in your code,
it will suggest a quick fix.
Static code analysis like this can
help you catch common programming mistakes
even before you run your app on the device or emulator.
The "requires permission" annotation
is actually defined in the support library
and works in tandem with a Link Checker in Android Studio.
Let's go through some other annotations
that you will find in the latest release.
Threading annotations guard you against calling methods
on the wrong thread.
Let's say you're doing some background processing,
like in this AsyncTask example.
Because the AsyncTask methods are already properly annotated,
the IDE will alert you if you try
changing the UI from here by calling methods
on the text view instance.
On the other hand, Android Studio
knows it's safe to invoke UI code in unpost execute,
as it is marked with the main thread annotation.
Up next, the size and range annotations for integers
and floats.
They can be used for controlling the length of your arrays
and strings, or making sure a number is in a specified range.
They're especially handy for annotating method parameters,
so that the caller can immediately
know what kind of values are expected.
If you want to study those in more detail,
as well as learn about other annotations, like check result
and call [? super, ?] click through to the documentation
here.
Remember that you don't have to rely on the annotations
that we've included in the Android framework.
You are free to add them to your own methods and classes
so that anyone using your code will
benefit from the additional checks performed
by Android Studio.
Speaking of sharing code, Android Studio 1.3
introduces support for hiding resources in library modules.
Perhaps it's easiest to demonstrate on an example.
Here's what used to happen when you tried to use autocompletion
in a Layout file when you have appcompat in your dependencies.
And here is the same operation using
the newest versions of both studio and the support library.
Most of the resources we see on the left
are used internally by the creators of the library
and were never meant to be available
for third-party developers.
Not only do they introduce clutter
and pollute your project's name space,
things might also break with any update
if you decide to use them in your layouts.
To define which resources should be visible
for users of your library, simply
put a public XML file in your values folder.
Provide an entry containing the type and name of each resource
you want to set as public.
This information will also be bundled and available
to Android Studio if you decide to distribute
your library in AAR format.
With the release of 1.3, we're bringing more tools
that were previously available as external applications
into Android Studio.
You can now open your object allocation
trace files in the new allocation tracker, which
shows you a visual overview of where allocations
happen in your code, and gives you a way
to dig right into the data.
Another memory inspection tool that is now available
right in the IDE is the HPROF viewer
for opening hprof profiles.
It gives you access to the reference tree
of any object in memory, as well as a property inspector,
similar to the variable debugger window.
Use it to examine the state of objects
at the moment when the memory snapshot was taken,
and to track down any rogue references that prevent them
from being garbage collected.
By the way, we've also added small improvements
in the traditional debugger interface.
From now on, when you inspect a variable that holds a resource
identifier, you can easily see the human-readable name
instead by switching to the Android typed integer view.
There are many more new features in Android Studio 1.3--
integration with the data binding library,
adding developer services from the project structure dialogue,
live code templates, and finally,
a preview of the upcoming C/C++ editing and NDK support
in the IDE.
So upgrade Android Studio now, and as always,
please report any bugs in our Google+ community here.
Thanks.
[MUSIC PLAYING]