wear的complication系列文字稿

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