Menu

What’s new in the support library – Google I/O 2016

11 Comments



CHRIS BANES: Hi, everyone
and welcome to What’s New in the Support Library. My name is Chris Banes, and I’m
an engineer on the Developer Relations team. TENG HUI: Hi. My name Teng Hui, and I’m an
engineer in the Android UI Toolkit team. ALAN VIVERETTE:
I’m Alan Viverette, and I’m Tech Lead for the
Support Library Project. So in the past year, a lot has
changed in the Support Library. We added a lot of great new
features in release 23.2.0. And since then,
we’ve added a lot of bug fixes and
some minor features. And today we’re happy to
announce the release of version 24 alpha 3, which coincides
with the developer preview three of Android N. So today we’re going to
be talking about some of the cool new
things in Support Lib, and some of the things
that we can look forward to in the future. We’re going to start out
by taking about Support v4. So everyone’s
familiar with this. It’s where you have
compatibility shims so you don’t have to
do an if version check. It also contains a bunch of
helper functions and utilities that you can use to make your
apps backwards compatible. As with each platform version,
we’ve put in back ports for various functions that
have smart fallbacks that you can use to target new
APIs on older versions. And we also have a
couple of features that we’d really like
to highlight today. So in fragments, we have
some life cycle improvements. Namely, fragment transaction
now has a synchronous commit. So if you’re creating an
encapsulated component that’s working with fragments
transactions, you can synchronously
commit your transaction. If your fragment
is being added, it will be added and brought to
the host state immediately. You don’t have to worry
about ordering conflicts with other fragment
transactions. Likewise, if your
fragment is being removed, it will be removed and
disconnected immediately so you can handle all
of your life cycle without having to
worry about ordering. This is especially useful
if you’re a library. So we actually use this in
the Viewpager Fragment Module in the library to prevent
ordering conflicts. Adam Powell is going to talk
more about some of the changes to fragments in What The
Fragment, which happens at 5:00 PM. So make sure to check that out. We’ve also made some
changes in notifications. In particular, we have a new
conversational messaging style. So when you have, say, a
Hangouts Conversation that’s multiple parties back and forth,
that shows up in notifications and shows you snippets
of the conversation. This is also
supported by Wear 2.0, so when you have a conversation,
that shows up on your watch. We’ve backported
this in Android. So if you have Wear running on
an API 18 and above device– so that’s when Notification
Listener was added, Notification Listener
Service, and you use the notification
Compat Builder to build your
notification, and you use messaging style– even
on an API 18 device, that’ll move to the Wear App, which
is also using Support Library, and understands that
communication channel. And you’ll get the messaging
style on your Wear device as well. We’re also giving
you more information about what users think
of your notifications. So one thing that
developers have really wanted to know for
a long time is, have users block
notifications from my app? So in Android N, there
is now an API that lets you tell exactly that. And we’ve backported
this to API 19, which is when users were first
able to block notifications from packages. So you will get an
actual value from this that reflects whether the
user has blocked notifications from your app on
API 19 and above. On API 18 and below, it’ll just
return false– or, sorry– true that the user has not
disabled notifications. We’re also giving
you more information about how users rate
your notifications. So if they think that
your notifications are less important or if they
want to block them completely, we have a compatibility
method that allows you to do that and use
the API on older versions. It’ll just return basically
a [INAUDIBLE] value that says your notification
is normal priority. We’ve also made some changes
in the media framework. So an API 21, for
compatibility with Android Auto and Wear media
browsing and playback, we added the Media Browser
Service and Media Browser. And in Support v4,
we’re now bring backported versions of those. So these are intercompatible
with each other on v4 and above. So if you have an app with
a Media Browser service that’s exposing media that can
be consumed by a media browser if they’re both running
compat from the Support Lib, they’re also compatible with the
framework implementations on 21 and above. So if you use the
Support Library versions, they’ll be maximally compatible,
work with a lot of devices. For a fully functional
implementation of both of these classes,
you should check out the Universal
Android Media Player, which is in the Google
samples on GitHub. Right. And for applications that
are presenting web content, you have a couple of
options right now. You have an embedded WebView. Maybe you launch a
browser instance. And these have some issues. They can be a little bit slow. If you’re launching a
full browser instance, you kind of bring the user out
of the experience of your app. So Custom Tabs are a new
way to present web content that we’ve already
presented, and we’re making some improvements to those. So this is new in 23.2 with
some improvements in v24. The minimum SDK
target for this is 15. And the reasoning
for that is primarily motivated by what most
apps are targeting now. So Chrome has a minimum
SDK target of 16 and above. So if you’re using
this on API 15, likely your user’s device
won’t have any targets and you’ll just launch the
regular browser instance or you’ll need to use
an embedded WebView. As I mentioned, this
alternative to embedded WebView that is performance focused. So it’s going to share a
cache with the browser. It’s also going to share
cookies with the browser. So if your user is already
logged in to web content, that’ll be persisted when
your application loads that into a custom tab. And because we
don’t want the user to feel like they’re
exiting your application, we have a high level of visual
customizability and navigation callbacks. So if the user
leaves the content that they landed in
initially, your application can perform something
in response to that. So here’s a quick example
from the Chrome Blog of how fast Custom
Tabs is compared to some of the other solutions. Because we have a warm
up that can spin up the Chrome process
in the background before you actually
launch your custom tab, and because we’re able to
preload and prerender content, you can have an almost
instantaneous transition from your app to your
web-backed content. And this is really
simple to implement. So here we have an example
of one-liner warming up the Chrome process
and launching a custom tab for a specific URL. One downside of this is that
because we’re just very quickly spinning up the Chrome
process and we’re not keeping any handle
to it, the process may be garbage collected
in the background if the system is
memory pressured. So one other thing you can
do is write a lot more code to create a persistent
connection to a Custom Tab service. For my examples, I’ve been
talking a lot about Chrome, but this could also be
implemented by other browsers. So you may see Firefox
Custom Tabs as well. But you’ll need to handle
connect and disconnect with your activity
life cycle here. And you can create a session. A session to the
Custom Tab Service is going to allow you to do
some cool things like preloading content. So here we have one
target URL that we know we’re going to land on. And we have a couple
of links out of that that we have a
pretty good chance that the user is
going to land on. So as we load these, that
means that we’re using data. That means we’re using battery. So you don’t want to
just indiscriminately put thousands of URLs in this. You want to have a
really good higher than 50% confidence that the
user is going to need these so that we can preload them
and show them really quickly. Right. In addition to being fast,
we want this to be seamless. So we provide a lot of
customization aspects that you can set up when you’re
building your custom intent. To that end, you can
customize the toolbar color. So here we’ve colored it
teal to match our app. And you can also
customize the action. So we have a favorite action
that we’ve added at the bottom. You can add actions
to the Overflow Menu. You can also set
up transitions so that you have animations
in and our of your activity that look like a
natural extension of the rest of your app. So this is really great. It’s really easy. So these are all just things
you set on your builder when you’re launching
your intent, and then you launch it out
to be Custom Tabs process. And as I mentioned, this
is API 15 and above. If you’re on older
devices or devices that don’t have a browser that
supports Custom Tabs, you can also have
a fallback path for either launching the
browser intent for view or simply launching
an embedded WebView in your own application. All right. So I’ve covered some
of the major features in recent Support
Library history. But there are some
other features that are highly
anticipated that I will let Teng Hui and Chris
talk about, so over to Teng Hui for VectorDrawable. TENG HUI: Thank you, Alan. [APPLAUSE] Great. Before we talk about
technical details for the VectorDrawables,
let’s start with some design
principles we have when redesigning these new classes. First of all, the first
question we may have is, why do we need
vector graphics? As we all know,
Android has been using Bing Maps for a long,
long time for the icons and the Drawables. And as the phones and
tablets grows bigger with higher resolution,
those PNG files is taking more and more
spaces in your APK file, and vector graphics is
the perfect solution to this problem. It is using a much
smaller compact file format to represent
those icons and can scale to any resolution. In this example, on
the left-hand side, the multiple PNG files can
take up too 10 kilobytes. But on the right-hand
side, we just need one single SML file to
represent the same icon, which can take only 1 kilobyte. With more and more
icons in your APK file, then that means
you can bring down the APK size significantly. The second question we
commonly get from developers, like why do we not
using SVG file format? I hope you all know that SVG
is very complicated for a spec, and is surly an overkill
for representing those simple, small icons
for your Android app. Moreover, we want this
newly designed drawable is consistent with all the
other Android APIs, especially those animation API
and theming API, and work nicely with
all the other resources. So we introduced
the VectorDrawable and AnimatedVectorDrawable
in Lollipop. And they work nicely
for API 21 and above. And they’re used heavily
inside Android OS to bring down our system image. And because our simple
design principle, we can continue to
improve the performance. On this note, I’m glad to report
that on Android N release, we improved the join
performance by two times faster and the initial file
passing performance up to five times faster. And here is a symbol of
how the VectorDrawable file format looks like. It’s basically just
a tree structure, and is quite similar
to SVG, but simpler. All the internal notes
here are the group notes, and they are using to
describing the transformation information, like scaling,
translation, or rotation. And the leaf notes
are the path notes. And they’re used to describe the
geometry and color information. Based on this
VectorDrawables format, the AnimatedVectorDrawable
is just simply adding the object animators on top. For example, we can
set the object animator to target it to one group now
through its rotation attribute, and set the value to change
from 0 degrees to 360 degrees. And when the animation
started, then you would see all the children nodes
will be rotating in a circle. Also, you can add more object
animators to different nodes, to their different attributes,
to make your animation look even better. There’s one caveat you
may be able to see here. That means one
AnimatedVectorDrawable could involve multiple,
sometimes even 10 or 20, XML files. To ease the pain, we actually
introduced a new XML bundle format to merge related
XML files into one. This is in the latest
Build 2 and is also backward compatible. And here is one example. The AnimatedVectorDrawable
is referring to a VectorDrawable
whose name is call icon, and sits inside a separate file. By simply changing the
Android Drawable attribute into this new AAPT tag,
then you can cut and paste the VectorDrawable, the
whole file, into this tag. And then you merge
two files into one. You can do the same trick for
all the object animators too. So basically, you’ll just need
one single file to represent your AnimatedVectorDrawable. Then hopefully,
that will be easier for you to read and
debug this Drawable. And now I will also briefly
talk about how do you generate those vector assets. And luckily, we have
Android Studio to help. The first thing you can use is
this Vector Asset Repository dialog. In here, you can see all the
material design icon library. And you can just
pick one you like, and it will be saved in
your Drawable Directory. Or, if you have your own
SVG files for those assets, you can also use this Vector
Assets Studio inside Android Studio to convert your own SVG
files into the VectorDrawable XML file. Now, I hope you feel you
can see this new class is useful to you. But the major questions we
often get from developer is, how can we get these new
classes is working in the older version of Android? We know this is so
important for you, we actually come up
with two solutions. The first one is
Gradle solution. Inside Android studio,
when you build your app, the Gradle will look at
your minimum SDK version, if that’s less than
21, and you also have VectorDrawable XML in
your Drawable Directory, it will convert this XML
file into multiple PNG files for different DPI automatically
in a generated directory. And then the XML file will
be used for API 21 and above. And the PNG file will be
used for older versions. The best thing for this
solution is simple adoption. So the only thing you need to
do is to swap out the PNG assets into the XML assets. And then Gradle would
do this by default, and it would check the minimum
SDK version automatically. There’s also some downside
for this solution. There’s no
AnimatedVectorDrawable support, and it’s only supporting
a limited features of VectorDrawable. And the last one is
the generated PNG file can still sit inside your APK. So on this, we also recommend
you have a separate APK supported by Play. You can’t have one for API
21 and above, which will only contain the XML file,
and have another one for the older version, which
will contain the PNG file. We know this sounds like
a hybrid solution here. So we continue to
work hard, and then we get out this more
purer solution here, and based on Support Library. In version 23.2 of
Support Library, we introduced two new classes. One is VectorDrawableCompat and
AnimatedVectorDrawableCompat. So from the name,
you can see we are supporting both static asset
and the animated asset here. The best thing for this solution
is it is XML files only. There’s no more PNG
involved at all. And the same XML
format file can be used for the Support Library
version and the Non-support Library version. And we also support
the full feature set of the VectorDrawable. There’s some caveat
for this solution. First, you will need to turn
on a special Gradle flag, which is vectorDrawables.
useSupportLibrary, which basically turns
off the PNG generation, and also have some special
treatment on the VectorDrawable XML file. Second, you may also need to
be aware of the API versions. Very simple, the
VectorDrawableCompat is only backported to API 7. And the AnimatedVectorDrawable
is backported to API 11. And here is one example. I am using the Support Library. I manually create those assets. And they actually can run all
the way back to Honeycomb. And as you can see, you have
the scaling, rotating, and even some clip masking,
moving objects. And there’s also
some color change. I know you developers will
be more creative than me. I hope you can also create
sweeter UI for your app and without any much
overhead to your APK size. Last thing for this Support
Library, the Drawable reference is somewhat different. If you’re using the old way,
the image view, for example, if you’re using
Android source, it may actually cause
some exception in the older version of system. For this one, I
actually have to ask our owner and expert of
AppCompat Library, Chris, to help. And he came up with a
really nice solution. So now I will welcome
him to talk about it. Thank you. [APPLAUSE] CHRIS BANES: Hi, everyone. So Teng Hui was just
spoke about the background behind VectorDrawables,
why you would use them, and the benefits of
actually using them. So I’m going to talk now about
how you actually use them in the Support Library. And I just one note
here, I’ve abbreviated VectorDrawableCompat and
AnimatedVectorDrawableCompat. So if you see it later in the
slides, that’s what they mean. So the first way you
can use it is manually. So each class has a static
method on it called create, which takes a context
and a resource ID pointing to your resource. And that will manually
inflate that resource and give you a Drawable back. But we know that’s kind of
clumsy to use for two reasons. Number one, you can only use
it in code, and number two, you can’t actually
use it from resources, which is the whole point
you actually have them. So we went back to
the drawing board, and we thought, how can
we actually implement it in AppCompat, because
that has a lot of resource management in it
anyway with views and stuff. So we’re thinking,
that’s probably the best place to actually
implement this feature. So we have a couple ways
of actually using it within AppCompat. We have a new attribute on
ImageView called SourceCompat. And that, basically, it
supersedes Android source, and it allows VectorDrawables
all the way back to API 7 for the
static versions, and 11 for the
animated versions. We’ve also overridden the
setImageResource method. So if you’re using that API
anyway to set Drawables, you can use VectorDrawabes
back to the same API levels. Now, for anything AppCompat
inflates itself– so here’s a good example of menus. When you inflate a
menu in AppCompat, AppCompat is doing
all of that for you. So as it is doing it, we can
inject the VectorDrawableCompat class into it and load
the Drawable for you. So basically, we never
touch the framework there, which means that you can use
vectors in those resources, and they work back API 7 and 11. Now, around 23.2,
I wrote a blog post on “Medium” called
“Age of the Vectors.” And that had a
section in it, which– there’s a section called
“The Magic Way,” which is really about name. But what it allows
you to do is it allows you to use
VectorDrawables within Drawable containers. Now, it is kind of
experimental in that it doesn’t work in every situation. So that’s why I put
a caveat around it. We had to remove
it in 23.3, though, due to some issues
around memory usage and also updating of
configuration objects. We’ll talk a little bit
about why in a minute. But thankfully, we’ve
brought it back in 23.4. You’ll see there’s the
asterisk next to it. And the reason for that is
because it’s no longer enabled by default. It’s now disabled,
which means by default, you won’t get the issues. But if you do want to
use this functionality, you can manually enable
it with the caveat that those issues still exist. If you have a look at the
JavaDoc of this method, it’s huge, and it tells
you exactly what you’re sort of letting yourself into. So the reason it has those
issues is the way it works. Internally, it creates a
special resources instance, but per context. In reality, that’s going
to be per activity. Usually in your application,
the resources instance, you’ll usually only
have one, which is reused across all your
activities and whatever else. But the way
AppCompat has to work and the way this
enables this feature, is by using an
instance per context. Now, the increase in memory
usage is because of the caches that each resource
instance holds. So instead of having
one cache for Drawables, you’ll have like– I don’t
know– x times the activity. Now, it isn’t a leak in that as
soon as the activity goes away, the resources instance will go
and you’ll get the memory back. For most apps, it won’t
really be a problem. But if you have a really
resource heavy app, you may see an
increase in memory. The second issue
is because we also have that multiple
resource instance, you can get into
problems if you manually call update configuration. And that’s quite
an advanced call. I don’t imagine many
people are using it. But if you do,
you probably don’t want to enable its feature. So to actually use
this method, this is how I’d advise you
to actually use it. It’s a really
lightweight method. And so in each
activity, you just stick a static block at
the top, which calls true, if you want to use the feature. It’s really
lightweight, so don’t worry too much about putting
it in every activity. So we talked about how
to actually enable it. Let’s talk about what
it actually gives you. So as I said earlier,
it allows you to reference vector resources,
and AnimatedVector resources, within DrawableContainers. So if you want to use a
vector in a StateListDrawable, or maybe a Layer, or Inset, or
LevelList, or whatever it is, you can do so with
this feature enabled. So here we’ve got
an example where we’re going to wrap
a VectorDrawable in an InsetDrawable. Now, this is quite good
because InsetDrawable, if you don’t actually
fit any Insets, is basically an
invisible wrapper. So you’ll basically just
have the VectorDrawable, and the container won’t
actually add anything to it, which means you
can actually then use it in more places. So here we got a TextView. And you can set that wrapper
as the drawable left, or it could be the right
or top, whatever it is. But basically, you can
use it in more places. Another example is a
RadioButton button. These are just two
examples, background works. There’s other places as well. So that leads us
nicely on to AppCompat. Now, AppCompat is designed
to be a mini-backport of the framework. So things like Tool
Bar, the Action Bar, all of those type of things
have been backported into here. And it currently
works back to API 7. So let’s look at
some of the things which we’ve added recently,
so the past six months. The first big thing that
I like is Night Mode. So that allows your application
to be themed light or dark based on the time of day. So here we’ve got an application
which is opened at noon. And it’s a light
background with dark text. And then if a user
opened that at 10:00 PM, it would be inverted, so a
dark background, light text, which is great for
users if they’re reading in bed, less glare. So there’s two things you
have to do to actually enable this in your app. The first is you
change your theme, and change it to extend from one
of the Theme.AppCompat.DayNight variants. So if you’re already using no
action bar or dark action bar, but you also have those
variants on top of it, so it should be a straight swap. Once you’ve done that, great. But you need to tell AppCompat
to actually enable the feature. And you do that via the
setDefaultNightMode method. Now, that method takes
one of four options. The first is FOLLOW_SYSTEM. Now, most people don’t know. But Night Mode has been in
the framework since API 8. But before Marshmallow, it was
behind a couple of scenarios. You had to be Car Mode
and Docked, if you remember what those were. In Marshmallow, the feature
is actually always there, but you can enable
it, basically, but there’s no usable,
visible feature. There’s no setting
in Settings for it. So if you use this
mode in AppCompat, basically, we will always
follow what the system is doing. The most interesting one is
probably MODE_NIGHT_AUTO. And that will automatically
change between light and dark based on the time of day. It will look at the last
known location of the device, and then try and work out
a rough, approximate sunset and sunrise time, and
then use that to say whether in day or night. So that’s very nice. And then follow
two, the last two, are YES and NO, which do
exactly what you think. Basically, day
mode or night mode. I wouldn’t advise you
use these unless you have some kind of user
setting in your app, because you can achieve the
same thing by just using the proper theme parents,
either the dark themed AppCompat or the light
themed AppCompat alone. If you want to know
more about this, Alan and I are talking
tomorrow morning at 9:00 AM. In the talk of Themes
and Styles Demystified, we’re going to go more into
this, and also generally into themes and styles. Another thing we’ve
added in AppCompat recently is ColorStateLists,
and specifically ones with themed attributes. So these were added to the
framework in Marshmallow, and we’ve backported
them back to API 7. And now this is in 24.0. So if you’re using the
preview, then you’ll have this functionality. Internally, AppCompat uses
this a lot for drawable tints. We’ve managed to reduce the
amount of ColorStateList codes by loads, by actually moving
all of it into resources. So here’s an example of
just a ColorStateList. The first item references
a themed attribute. In this instance, it’s
colorControlNormal. Now, the really neat thing
about here in this disabled item is that you can be
using the color. But you also have
this new functionality where you can change the alpha
of the color at the same time. So using the Android
Alpha Attribute, you can modulate the alpha of
the color to whatever you want. Now, it takes a float
value from 0 to 1. We’re just going to
reference the system default for disabled. But yeah, you can set
to it whatever you want. To actually use these
and inflate them, we added a new API called
AppCompatResources. So if you want to inflate
these, use this method. We’re going to add more stuff
to this class in the future. And so, more coming soon. So following on from AppCompat,
we have the Design Library. Now last year, last I/O
actually, we released it as a first party
take implemented on some of the components
from material design. Since then, we’ve
been in book fix mode, and trying to stabilize it. But we have added some
features recently. The first big one
is Bottom sheets. Now, in Spec, there
are two types. There’s Persistent and Modal. Persistent when the Bottom sheet
is always part of your content. You can’t dismiss it. So a good example is Maps here. And it shows the
detail for whatever, the address is or whatever. On the right, we
got the Modal ones. And that’s basically
described as being an alternative to dialog. So let’s take a quick look
at what they look like. So this is the actual
implementation. As you can see, as the
user scrolls up and down, in collapses and expands,
but you can never dismiss it. And to actually use it, the
first thing you’ll notice is that the parent needs
to be a CoordinatorLayout. So if you’re using app
file layout and whatnot, you’re all set already. And within here, you’d set
the rest of your content. So in the map example,
it would be a map view. And then we have
our Bottom sheet. Here we’re using
a linear layout, but it could be
whatever you want. And the way you actually
tell it to be a Bottom sheet is by setting this
special behavior on it. Now, Ian Light wrote a
great post on “Medium” about behaviors. So of you want to know more,
go and read that first. But this is the way you actually
tell it to be a Bottom sheet. And then we also have an option. By default, it’ll just sit at
the Bottom default peekHeight. But you can also set it
to be whatever you want. The peekHeight is how much
it sits at the bottom when it’s collapsed. The second type is Modal. So as I said, it’s like
an alternative to dialog. So as you can see here,
when the user clicks, you get this modal Bottom
sheet, which you can scroll and then dismiss. So we know that most– well,
we’ve already described them as an alternative to
dialog, so the way we’ve tried to implement this
is as simple as possible. We know that the majority
of people using dialogs will probably use
a Dialog Fragment. So we’ve tried to
implement this using that. So you should be
able to just extend, change the superclass
of any of your fragments to this new
BottomSheetDialogFragment, and then it will just suddenly
become a Bottom sheet. It’s really simple to use. I’m used it internally in a
couple of apps, and it’s nice. Once you’ve done that, you
just create the fragment, and then call dot show,
which is the same thing as DialogFragment. The other thing in
Design Library– it’s not really a feature,
it’s more of a bug we fixed– is that any
of the Elevation handling was previously hardcoded, just
for ease of implementation for last year. But we’ve been trying to fix it. So there are three
scenarios on the material spec of AppBar scrolling. The first is always elevated. So here the use of
scrolls, and regardless of the scroll
position, it is always elevated, which means it
casts a shadow, basically. You probably can’t see it
very well, but it is elevated. And then we have
the second type. So here the header
is not elevated. So it’s in line
with the content. And then as the user
scrolls and it collapses, it then becomes elevated. And then as I scroll off,
it’s no longer elevated. So that is implemented using
a CollapsingToolbarLayout. But there’s a third scenario on
spec which we didn’t support. And that is, when you
have collapsing content, but you also want
it to stay elevated. So we were trying to think
of ways to actually implement this in a nice way. And the way we fell with
was StateListAnimator. So we now have a
StateListAnimator, which controls all of the elevation. Now, the this is similar to
the button implementation on material. So when you click on
a button on material, it’s supposed to come to
your finger and enlarge. Now, that uses StateListAnimater
intended to actually do that. So we’re choosing the
same functionality. So we’ve added two
states, which you can use in your
StateListAnimators to actually implement this. The first is
collapsible, which means that there is
collapsible content within the AppBarLayout. And secondly is collapsed. And that means that there
is collapsible content and it is also collapsed. So let’s take a
look at an example. So here we’re going to
implement the scenario where you want it to be elevated
when it’s collapsed, so the second scenario. Now, this is already
given to you by default. You do not need
to implement this. We’re just going to use this
example to actually show you how to use the new states. So here we have two items
within this StateListAnimator. The first is run when we have
some collapsible content, and is also collapsed. So if you think back to the
scenario, in that point, it needs to be elevated,
which means that we animate the elevation up to 8dp. And that could be any
value, whatever you want. Look at spec for the actual
values you should use, which can use 8dp as an example. And the second item doesn’t
have any states, which means it’s the default item. Therefore, it will be run
whenever the first item doesn’t hold true. At this point, it is when
the collapsible content is no longer collapsed. Therefore, we want to elevate–
bring the elevation down to 0. And therefore,
it’s not elevated. So as I said, you don’t
need to implement that. That is done by default for
you– just using an example. Now, if you think back, there
was that third scenario, which we don’t currently support. Now, that’s a really
simple StateListAnimator. It just has one item,
so it doesn’t even look at the states. And it just sets the
elevations at 8dp. So that’s all it does. To actually use this, you just
set the stateListAnimator tag on your layout,
pointing to whatever StateListAnimator you want. And now I’m going to hand it
over to Alan to take about some of the sneaky new
stuff we’re planning. ALAN VIVERETTE: All right. Thanks, Chris. [APPLAUSE] All right. So Chet was kind enough
to tease that we’re telling you about the future
things in Support Library this morning. So let’s start out with a
little interactive part. First, a show of hands,
how many developers here are using the Support Library? Good. That’s probably why you’re here. All right. Show of hands, keep your hand
up if you’re supporting API 14 and above in your
application, or lower. 14 and above? OK. Hands up again– we’re getting
exercise– if you support API 9 and above in your application? OK, fewer people. API 4 and above in
your application? Wow, not a single–
one guy, one girl. That’s fantastic. That’s dedication to your craft. I respect that. You’re not going to like
where this is going. [LAUGHTER] We are dropping support
for APIs below 9. This has been a long time
coming, so less than– [APPLAUSE] It’s only API 9. Don’t get too excited. So less than a
tenth of a percent of devices that have
access to Play store are running APIs less than 9. So dropping support means
one, we have fewer methods. So we’re taking
a couple of steps back from your
ProGuard decks limit. Yeah. So about 130 methods right
now just removed from v4. We’re still in the process
of backing things out. This is also going to
improve our release cycle. So we’re able to now focus
on the same platforms that you actually care about. As it turns out,
supporting API 4 takes a lot more
effort than supporting API 9 or 14, which is
why most people here aren’t supporting API 4. So we’re going to be
able to iterate faster. We’re going to be able to focus
our fixes and our workarounds for platform bugs, and
our testing on the APIs that you actually care about. So hopefully, that’ll make
your life a little bit better. Second, as I mentioned
earlier, Support v4 contains backwards
compatibility shims. So this is so you don’t have to
wrap everything with a version check and then figure out some
reasonable fallback behavior. And Support v4 started
out only containing this. And then we added
some other things. So we added fragments in API 11. We figured it would be good to
have a backwards compatible way to get people on board
with fragments supporting older devices. And then we added some
helpers for things like accessibility
and drag and drop. Then we added some more
stuff, and some more stuff. And Support v4 alone has
become a very large library. So we’re going to
be breaking that up into more focused modules. And the important thing
here is that we’re going to support–
we’re going to hold your hand through this process. So we’re not changing
any of the package names. I should also mention for
the minimum version change, we’re not changing any
of the package names. So Support v4 is
still Support v4. support.v4.media is
still support.v4.media. We’re going to be moving
them into different modules, and we will have a meta module
that includes everything under the old name. So all the libraries
that you use that depend on
the package naming structure, and the module
names themselves will be fine. We’re not going to
end up in a situation where you need a special
version of a library dependency. Let’s see. So hopefully, this is going
to be completely source code compatible and binary
compatible with your existing applications and library jars. And hopefully this is going to
make your life as a developer a little bit easier. So thanks, everybody for coming. [APPLAUSE] We have some other talks that
you may be interested in– What The Fragment today at 5:00,
Data Binding, and RecyclerView. Thanks again, everyone. We’ll see you around. [MUSIC PLAYING]

Tags: , , , , , , , , , , , , , ,

11 thoughts on “What’s new in the support library – Google I/O 2016”

  1. Gareth Hall says:

    Sweet updates!

  2. Ed George says:

    Great job Support Lib team, some really great additions. The custom in-app web view is genius

  3. Maple Media says:

    I like that they are breaking up the library. I wish the design-library didn't depend on appcompat.

  4. Mark Schumacher says:

    The svg spec might be overkill, but its widely adopted and accepted. Importing svgs into Android studio using that wizard is a long and monotonous task that is tasked to android devs. We need a better tool.

    Now instead of copying a collection of svgs to my projects, I have to load them in one by one.

  5. Peter Li says:

    I am here to watch the whole video. Great job the support library team! Love the custom in-app web view.

  6. Dmitri Oesa says:

    Pretty good and steady improvements. I've been using VectorDrawableCompat for a while, really helps.

  7. Liran Barsisa says:

    About the VectorDrawable support mentioned on 18:22 , notice that it can crash on some cases, like when using in selectors. I've reported about this here:
    https://code.google.com/p/android/issues/detail?id=210745

  8. Fung LAM says:

    support-v4 is still support-v4 or it is support-v9 with v4-s classname?

  9. Y2Kvids says:

    Chris Banes, the guy who appears with half-pants on Google I/O . 😂😂😂

  10. Ismail Iqbal says:

    Gonna start using Animated Vector Drawables from now (No idea of supporting APNGs I guess );

  11. Xin-Yue Zhao says:

    However the design team can understand SVG only.

Leave a Reply

Your email address will not be published. Required fields are marked *