Youtube subtitles download by mo.dbxdb.com
OLIN LAN: Hello, everybody.
I'm Oli Lan, an engineer on the Android Wear team.
TONY FERREIRA: And I'm Tony Ferreira,
a designer on Android Wear.
OLIN LAN: It's great to be here.
We're really excited to tell you about the new stuff coming
to watch faces on Android Wear.
The watch face is at the heart of the Android Wear interface.
Of course, it tells the time.
And with the thousands of watch faces on Google Play,
it's a great way for users to express their style.
We added interactivity last year,
and the watch face came to life like never before.
But the watch face can do more.
As an always-on screen that's just a glance away,
it's a great place to get the information you care about.
And that's why we're introducing the Complications
API for Android Wear.
TONY FERREIRA: But first of all, what are Complications?
That term comes from traditional watchmaking.
And it means, well, pretty much anything
that's not telling the time.
Complications on mechanical watches
show things like the date, your alarm, or phase of the moon.
So the small dials you see on this watch,
they are complications.
On smartwatches there are new possibilities,
like the weather, stock prices, or events from your calendar.
OLIN LAN: Many watch faces on Android Wear
already include complications, like Bits from usTwo or Legacy
from Zuhanden.
But as it stands, each watch face
has to go and get the data itself.
That could mean your watch face has
to find its own source of weather data,
or finance data, or anything else you want to show.
And if the user wants to see something you haven't included,
they're out of luck.
Or maybe you're not a watch face developer,
but your app has data that would be great on the watch face,
like fitness stats or finance info.
As it stands, there's no way to do this other
than building your own watch face
or making deals with individual watch face developers.
The Complications API for Android Wear
changes all of this.
Apps using the API will be data providers or watch faces.
If you build a watch face using the Complications API,
then you get access to a whole ecosystem of data providers.
Here are just some of the partners already working
on using the API.
And if you build a data provider,
you can get your data on a whole range of watch faces.
Now on Google Play, there's a huge range
of styles of watch faces.
So there's no way that just one style,
one visual style of complication would fit on every watch face.
Because of that, with the Complications API,
the watch face gets to decide how to render the data.
It gets to choose the visual style, the colors, the fonts,
etc.
The data provided just provides raw fields
like strings, text, images, and numbers.
Before we get into the details of the API though,
Tony is going to go through some things
to think about when designing for complications.
TONY FERREIRA: Thanks, Oli.
So some of you may have already checked out the Material design
spec for wearables.
And there you'll find a ton of useful things
to help developers and designers design for Android Wear.
I'd like to highlight some of the things, some
of those design principles that you'll find in there
and how they apply to complications.
So the first design principle is glanceable,
making things clear and understandable.
For complications, small, easy to read snippets of information
work best.
It's very important that the information on the watch face
is organized with a clear hierarchy, large enough
to read easily, and high enough in contrast.
Users shouldn't need to squint to read the UI.
The second design principle is time saving,
getting the information you want quickly without any roadblocks.
Instead of navigating to your favorite apps
to find the information you want,
with the introduction of complications,
it's right there on the watch face.
Complications are also tapable.
So you can deep link to your favorite contact or upcoming
calendar event.
And complications are also persistent,
there whenever you need them.
The third design principle is consistent.
Complications should have a healthy relationship
with the watch face.
As Oli just said, with Complications on Android Wear,
the watch face decides how the complications are rendered.
So they feel part of the same family.
Consider aligning the style of the complications
with the watch face.
Oli is now going to talk you through the complication types.
OLIN LAN: Thanks, Tony.
So complications are all about data, supplied by provider apps
and displayed on watch faces.
This could include numerical data like your battery level,
text like the title of your next meeting,
or images like an icon or a profile pic.
Not every type of data will fit on every watch face.
There might only be space for a small icon
or a short bit of text.
Or you might want to use numerical data without having
to show text or images.
So watch faces need to say what they can display.
And data providers need to say what they can supply.
To help with this, we've defined a number of complication types.
Complication types determine what kinds of data
are included.
There's usually one field that's the key piece of information.
And we've named the types after that field.
So here you see examples of the short text type.
These are all short text complications.
But as you can see there are optional elements.
There may be an icon or a second string.
But the most important value is contained in the short text
field.
If you're a data provider, you can
choose which of the optional fields to include.
But a short text complication must always
include the short text field.
If you're building a watch face and you support short text,
you need to consider all of these variations.
Here are some other examples.
You might not need any text to convey the information.
Then maybe the icon type is enough.
Or, if you have numerical data within bounds
like a percentage, then the range value type
could be for you.
We also have a few other types.
You'll notice that we have bot icon and small image.
The difference is that images for the icon field
should be tintable by the watch face.
They should be single color with a transparent background.
This allows the watch face to fit it better to its style.
So if you are building a watch face where full color
images won't match the style, then you
can support the icon type.
But you might not want to support the small image type,
where images may be full color.
00:07:41,740 So when you're thinking about the different complication
types, if you are building a provider,
think about the different forms your data can take.
And if you're building complications
into a watch face, think about how many of the types
you want to support.
00:07:58,259 Now back to Tony to talk about some more guidelines for what
face developers.
TONY FERREIRA: OK, so I want to talk a little bit
about the things you should consider
when designing complications.
However, bear in mind there isn't a one size
fits all solution to this.
We have a diverse collection of watch faces on the platform.
And we think it's important that complications
are flexible enough to mirror that diversity.
So please use these guidelines as a starting point.
But if you feel your watch face would benefit
from deviating from these guidelines, then by all means
please do so.
Complication should never conflict with the surrounding
objects on the watch face.
For more traditional watch face layouts, as shown here,
these red areas, in general, shouldn't have complications.
As it will be a conflict with other parts of the watch face.
Give your complications a bit of space,
so they have room to breathe as well.
And if possible, staying true to the alignment of the watch face
will also help you achieve better balance.
So if you have a center aligned clock,
it might make sense to center align the complications
as well.
00:09:08,190 Complications can be rendered however you wish.
Though you might want to give your data
a little more protection and house them in a container.
So we found these form factors work well
with the various data types.
We have circle, square, pill, and rectangle.
And bear in mind, the size and form of these containers
decide what data types can and can't be rendered.
And containers are optional.
Sometimes they help.
Sometimes they don't.
But the important thing to remember, as a watch face
developer, is you have the freedom to choose.
00:09:51,960 Building a strong relationship with the watch face
is also very important.
You don't want your complications
to seem like an afterthought.
So here are some things to consider.
Use color to tint the data.
This will help create better harmony with the watch face.
Decide whether your complications need containers
or not.
You can see in this example, in the middle,
we've removed the containers just
to help the complications better integrate into the watch face.
00:10:22,059 And play around with scale.
This will help you achieve better visual hierarchy.
But most importantly, on top of all that,
just have fun with them.
And don't be scared to get creative.
00:10:36,710 You can have multiple complications on a watch face.
This is awesome for those of us who
want to surface lots of data.
Here you can see we've removed the containers
to create more space.
And we can easily fit eight complications
on a single watch face.
If multiple complications is a direction you wish to go down,
just try to make sure that things don't get too cluttered
and the UI remains glanceable.
00:11:04,009 The Complications API can also be used as a creative tool.
With the ranged value data type, you
can abstract that data whichever way you like.
So in the example, we've shown here,
we display your step count goal.
Throughout the day, as you get closer
to reaching your step count goal,
the graphic in the background also updates.
Presenting the data like this, in
an unconventional and abstract way,
opens the door for more fun and engaging watch faces.
00:11:33,899 And just to finish, here are a few examples
of implemented complications designed
by our creative partners usTwo.
In the first example here, you can
see they've kept things simple and find a straightforward way
of adding complications to a preexisting watch face,
removing containers and tinting the data.
00:11:56,169 The second example is a little more bespoke.
They've used their creative license
and played around with things like the layout and the form
factors.
This helps better align the complications
with the watch face aesthetic.
00:12:11,370 In the last example, we have had some fun with the range value
data type, creating a really cool generative abstract
design.
In this example, you can imagine your daily step count
or battery level being represented.
I'll now hand you over to Oli, who
is going to talk you through the details of the API.
OLIN LAN: Thanks, Tony.
OK, so let's take a look at how this all fits together.
Android Wear manages the flow of data between data providers
and watch faces.
When data is needed for a complication,
Android Wear will send an update request
to the data provider asking for a specific type of data.
The provider builds a complication data object
of that type with the required fields
and sends it back to Wear.
Android Wear then forwards that onto the watch face,
which can then include it when it renders.
Android Wear also provides the UI
that allows users to choose providers
for each complication.
And we'll talk about that in a bit.
But now let's take a look at what you
need to do to add complications to a watch face.
00:13:25,649 So first of all, you need to decide
how many complications to include
and what types to support in each one.
So, for this example, let's say you
want to include a small round complication on the right.
Now in that space we could support short text.
We could also support icon.
And there's also enough space there to show a ranged value.
Now in that space we could, if we wanted,
support small image as well.
But let's say for this example that we don't want to.
Now let's say we also want to include
a complication at the bottom.
This one could support the same types as the first one.
But there's also enough space to make this one wider.
So it could support the long text type.
Note that we consider this to be the same complication.
Even though it's a different shape, depending on the type.
So to summarizes, these are the types supported
by each of those complications.
One more thing, you need to give each complication
a numerical ID so that you can refer to it with the system.
That's chosen by the watch face.
We call it the watch face complication ID,
and it can be any integer.
OK, so next you need a way for the user
to choose providers for each complication.
00:14:54,590 As I mentioned earlier, Android Wear
provides the UI to choose a provider
for a particular complication.
But the rest of the UI is up to you.
So what we're showing here on the slide
is a basic list that could be part of the watch faces config
activity.
It's the watch face's own settings.
So this screen is not provided by the system.
So when the user taps on item in this list,
the watch face needs to launch that system provider chooser.
Let's look at some code.
So, in order to do that, you use this support library method
to get hold of an intent.
That's createProviderChooserIntent.
00:15:36,880 You pass in the watch face component name.
That's the package and class name of your watch face.
That's just how you refer to your watch face to the system.
And you also pass in the watch face complication
ID for the complication that is being configured.
So that's the number we chose earlier.
You then pass in the types supported by that complication.
In this list, the order doesn't matter.
You list them in order of preference,
with the most preferred coming first.
In this example, we've put ranged value at the top.
That's because that type conveys the most
information to the user.
So that's often a good choice.
And that's a good way to think about this.
OK.
So then when you have the intent,
you call startActivityforResult to show
the system provide chooser.
So, when the user taps on an item in this list,
the system provider choose is shown.
Now when the user chooses a provider in this UI,
it gets setup automatically.
You don't need to do anything else.
OK, so to show the data, what you need to do
is tell the system that your watch
face is ready to receive it.
So let's move into the watch face service
itself, specifically the engine.
So what you need to do is call setActiveComplications,
and pass in the watch face complication
IDs for the complications that are ready.
Here we're showing in onCreate of the engine.
That's usually a good place to do it.
But you can call this method from elsewhere.
For example, if the active complications change.
00:17:22,700 Once you've done that, you will start to receive data in calls
to the on complication data update method.
00:17:31,680 The data will come with the watch face complication ID
that it relates to.
Now, you'll only receive data when it changes.
So you'll have to hold onto the complication data object.
And any images, such as icons, should be loaded asynchronously
and be sure to catch them.
Now once you've got the data, it's up to you
how to incorporate it into your watch face.
But before rendering it, you need
to check if the data is still active.
Some complication data is only valid until a certain time.
So for example, it might be for a next event complication.
And then the piece of data will only be relevant
up until the end of that event.
You check it using this method, the
is active method on the complication data.
So you just pass in the current time
when you're drawing a frame to see if you still
need to draw that data.
There's one other thing you should do,
which is to check to see if complications are tapped on.
You do this using the interactive watch face's APIs
that we announced last year.
So that is by implementing onTap command.
If a complication is tapped on, then you
need to check the complication data to see if it specifies
a tap action pending intent.
If there is one, you need to fire that intent when
the computation is tapped on.
This allows deep linking from the complication
straight into a relevant activity.
00:19:03,509 OK, so that's how to add complications
to your watch face.
One important tip that goes for watch phase development
in general, but particularly for complications,
is minimize the work you do in every draw call,
especially if you're drawing more than once a second.
Avoid object creation in On Draw wherever possible.
As that can lead to a lot of garbage collection and, hence,
poor performance.
OK, so now let's take a look at how to build a complication
data provider.
00:19:38,599 A data provider is a service.
And to create one, you need to extend complication provider
service from the support library.
00:19:51,154 This class has one abstract method that you must implement.
That is On Complication Updates.
This method is called whenever the system wants data from you.
So it will be called when a complication using
your provider is activated.
By which I mean, when the watch face calls
Set Active Complications.
And it will also be called when your provider is
chosen for a complication that's already active.
It can also be called with a certain frequency,
such as every hour, if that's what you want.
And it's also possible to trigger updates
if you need a push style.
For example, if you have a messaging app,
and you want to update a complication when a message
arrives, you could do this.
If you want more information on that then check out
the provider update request class in the previous support
library.
OK, so let's take a look at an example of how you
might implement this method.
So you'll see that one of the parameters is the type.
That's the complication type that's required.
And the first thing we're going to do is check that.
Now in this example, we're only going to support short text.
In a real world example you would probably
support more than one type.
00:21:11,750 So first thing now is we start building a complication data
object of that type, type short text.
And now we're setting the short text
field, which is the required field for this type.
And we do it assessing it to a simple string, "hello."
You'll notice that it's wrapped here is a complication text
object.
All of the set methods for text in complication data
take one of these complication text objects.
It can just be a wrapper for simple string or char sequence.
It can also be used for other things.
And we'll talk about that a bit later.
00:21:51,390 OK, so we're also going to specify an icon.
That's an optional field for short text.
All of the image set methods for complication data
use the icon class from the Android framework.
That allows it to be either a wrapper
for a resource from your application,
a drawable resource.
Or it could also be a bitmap.
However, as I mentioned earlier, the icon field images
should always be tintable.
They should be single color with a transparent background.
And we strongly recommend you use vector drawables for this.
That's because the watch face could draw the icon
at different sizes.
And using a vector will allow it to resize cleanly.
00:22:37,589 OK, so that completes the complication data
object for this example.
All you need to do next is send that data to the system.
And you do that using the complication manager
object, which is passed in as a parameter
to on complication update.
00:22:56,460 OK, there are two other methods that you can optionally
implement.
They are, onComplicationActivated
onComplicationDeactivate.
00:23:10,880 Complications are activated when the watch face calls Set Active
Complications.
And they are deactivated either by another call
to Set Active Complications with different IDs
or when the user changes watch face.
00:23:25,759 Now, as a service, your provider has
to be declared in the manifest.
And that's also where you use metadata to declare things
like what types you can support and what update period
you would like, if any.
Here, with the supported types, the order does not matter.
And that's because, as I mentioned earlier,
the watch face gets to decide the order of preference
for any particular complication.
Now for the update period, be aware that the update period
is not guaranteed.
We do apply a minimum.
The system applies a minimum.
So you should think in terms of minutes
or longer, not seconds, particularly in ambient mode
or when the device isn't being worn,
update requests might come less frequently.
Try to make the update period as long as is reasonably possible.
Getting updates too often could impact battery life.
If your provider doesn't need regular updates at all,
then you can just set this to zero.
And then you won't get any calls beyond the initial one.
00:24:30,940 Now one example where you might think
you want to update every minute is
where you are displaying something related
to the time on the watch face.
So here you can see two complications where
the text changes every minute.
We've got a world clock and the time to my next event.
But it would be wasteful to wake up the provider every minute.
And there's no guarantee that the update request
would come in at the point where the minute changes.
Even the date complication shouldn't need to update.
Even though it would only be once a day,
there's no guarantee the update will
come at the stroke of midnight.
So it would be showing incorrect data at certain times of day.
So instead, the API allows you to use time dependent text.
For text that represents the current time,
we have time format text.
And for text that represents the time to or from a given time,
use the time difference text.
Let's take a look at an example.
00:25:36,250 So let's say that we're building a complication showing
the time to my next meeting.
And we're using the short text type.
So I'm building the complication data of type short text.
We saw earlier that set short text takes
a complication text object.
And that's so that here we can pass in a different kind
of complication text object.
So we're going to use Time Difference
Builder to create one.
So passing into the builder, we need
to set the reference period.
That is the time that the text relates to.
So in this case it's the time of my next event.
Let's say that's from 4:00 PM until 5:00 PM.
In that case, start time here Is.
4:00 PM.
End time here is 5:00 PM.
Now we add a style.
So this just determines how the text is formatted,
is displayed.
In this case we're using short joule unit.
That means, for example, if the time
difference was five hours and 15 minutes, it would show 5H 15M.
00:26:43,809 That completes the time difference text.
So we call Build.
There's one more thing.
As I mentioned earlier, complication data
can cease to be valid after a certain time.
And that is the case here.
And it's particularly important here
because the time difference text is the time to the event,
but it's also the time since the event.
So if it were 10 minutes after my event,
then the complication might show 10M, which is not what we want.
So we have to set an end time so that it shows nothing
after the event.
OK, so that completes the complication data.
So we just call Build.
Let's see what that would look like on the watch face.
So, the event is at 4:00 PM.
One hour and 45 minutes before, we would see this.
At 3:45 PM, we would see this.
So although it's the short joule unit
style, when it's only minutes, we only show the minutes.
We never show seconds in this style.
00:27:50,750 During the event, we would show this.
So the time difference text actually shows the text now.
These strings, all of these strings
are localized according to the locale of the device.
After the event we see nothing.
Because we set the end time.
So for more details of the types and styles of time
dependent text, check out the complication text class
in the wearable support preview.
00:28:21,450 OK, so that's the Complications API for both data providers
and for watch faces.
We're really excited to see how you all make use of it.
00:28:29,896 TONY FERREIRA: Thanks.
So if you like what you've heard here today,
and you'd like to try it out, you can.
Just go to g.co/wearpreview.
You can find out about how to get the Preview SDK, device
images, and more information about the APIs we're launching.
The dev preview also includes this watch face.
It's called elements.
And it supports a variety of complication types.
So you can test any data providers you build.
The preview does include a few providers, like battery level,
world clock, and date.
You can use these to test the complications on your watch
face.
Here is a list of the Android Wear sessions
that were on today at I/O. And don't worry
if you've missed any of them, because they're
all be on YouTube soon.
00:29:23,490 OLIN LAN: So if you'd like to have a go at creating a watch
face with complications or building a data provider,
do check out the code labs.
You can do them here at I/O. Or you can go
to g.co/codelabs/io16/wear.
We'd also love to hear any feedback you have on the API.
So if you find any bugs, or if you have any suggestions
or questions, please go to g.co/wearpreviewbug.
And finally, if you'd like to discuss the Complications API
or anything else about Android Wear with other developers,
go on to Android Wear developers G+ Community
at g.co/androidweardev.
OK, thank you very much.
[APPLAUSE]
[MUSIC PLAYING]
Subtitles End: mo.dbxdb.com