Thank you. Yay. Good to see you all here, and thank you for inviting me to speak at JoyCon Berlin. So as the introducer have said, my name is Hoy Lam. I'm the lead developer advocate for Google on the Android Wear project. And you can follow me on Twitter at HoyTap.

And also, if you want to hashtag anything, then you can hashtag Android Wear, and also hashtag, of course, JoyConDE, or JoyCon Berlin. So the first questions I get quite a lot is, how is Android Wear going? And I'm very pleased to say that during the holiday season

last year, we were seeing over 70% growth in activation for Android Wear devices. And that's even before we have launched Android Wear 2.0. And as this ecosystem grows, we're seeing increasing momentum. So before Google IO this year, we had 23 different watches.

And we basically doubled it to 46 during this year. And here's just some examples. So on this side, we have gas, which is a very fashionable kind of watch. In the middle, we have Movado, a Swiss watchmaker that

have a very iconic, minimalist design. And on this side, we have the second generation Michael Kors watch, which is now fully circular. So there's no flat tire whatsoever. So that's some of the watches that we are launching this year. From Europe, we have the TechGoya.

And this is the new version, the TechGoya Modula 45. And Tech is very happy with the first version that they're now doing the second version. In the middle, you have the Louis Vuitton. And I'm lucky enough to be wearing one today. So if there are time at the end and you want to see it in person,

then please come up to me. Last but not least, we also have Mont Blanc and the Mont Blanc Summit. Again, it's the first watch that they're doing that is running on Android Wear. So as you can see, we're really building momentum in terms of OEM offering, new watches, and new brands. So what are we going to cover today?

I'm going to cover three things. So the first thing I'm going to cover is something that actually has been around since API 23. But it may not be immediately obvious. And also, some of the things that I was using, again, wasn't immediately obvious when I first switched over to API 23.

So I want to share some of the tips with you. The second is the new Wear UI library that we have launched at Google IO. I'm not going to repeat the content that we had at Google IO. But instead, I'm going to shift over to maybe give you a little bit more context of what we're doing, and then some of the pitfalls

that I myself fall into when I try to switch from the old wearable library to the new Wear UI library. And last but not least, I'll give you a preview of what I'm going to talk about at Google Developer Day, Crackle, tomorrow.

So I have a couple minute lightning talk at Crackle. But because I have a little bit more time here, I could extend the content a little bit so you'll hear a little bit more. And that's no excuse to skip over the session, because my other speakers, it is going to be a lightning talk session. So the only part that we repeated

is my section, which is very fun for the first five minutes. So if you skip the first five minutes, you can hear all new content about Android TV, the Excel player that we have, and also the Pro Audio stuff. So it's really worth color watching. But today, I'm going to give you a preview.

So let's kick off with API 23. As many of you have seen, Android Wear is all about giving the user a choice and basically say, you can wear what you want. It's an object that you are wearing.

So it really needs to fit your own personal style. And unsurprisingly, a lot of our users are going overwhelmingly towards a circular design. And they find it comfortable to wear. They find it actually fits much better to their fashion sense. So it is really important that developers take care

of this new screen form factor. Of course, if you do nothing with your Android app, this is what it will look like. So if you look at the red square, essentially, that's the area that Android will try to lay out all the components that you have.

It will treat it like a square. And so if you have things that are top line or bottom line, they might be cropped on the side there. And the simplest thing to do since the beginning of Android Wear is to put what we call a box inside layout in it.

And then what it does is it group all the components to the inside square of the circle. And this works perfectly if you have a very, very simple UI. If you have a message and a yes or no button, that's fine. And fortunately, not all our apps are like that. Our apps are much more functional.

Our apps are much more complex than what is being shown here. So what happens if you have something a little bit more complex? Since API 23, we have introduced two new identifiers, round and not round. And they work just like all the density qualifier

that you have before. So if you are using dash HDPI, it works in exactly the same way. And for anyone that have used Android Wear from the very first version, the 1.0, we have had something called a watch view stop, which is a component whereby

you can specify a round layout or a square layout depending on basically the form factor of the watch. And so when I switch over to API 23, the natural thing to do is to do this and say, hey, I have two layout files. Let's go ahead and basically specify them

as round and not round, two layout files, done. And as I iterate on my project, I then realize, wait a minute, maintaining two layout file is a pain. Because if you look at the screen design between the circular and the square, they basically have the same components.

I have the heading, I have the list view, I have the different components. I don't change color the elements between round and square. So why should I have two layout files? Because they will just look exactly the same. What I then realize is actually the thing that is changing between the two layout are the paddings.

So all I needed to do is to actually have one single layout file, but have two different dimension files for round and not round. And I find it much easier to maintain between the two versions. So when you're adding a new component to the screen,

you just add it to one layout file, and it'll just be there. And all you need to take care of are the padding, especially at the top and the bottom. So that's at least my tip of using the new identifier, round and not round, is through the dimension file. Next, the chin.

So fortunately and unfortunately, some of the watches does have a chin at the bottom, which is the black area that's being shown here. And a lot of them for good reason. So a lot of the watches might have light sensor so that it dynamically adjusts the brightness of the screen, depending on how much ambient light there is.

It's a battery saving option. And also, it helps the user see the screen much better. So it's there for a reason. But when it's there, it's a little bit of a pain. So if you do nothing, then this kind of things will happen.

So you might have a button down at the bottom, but then half of it will be covered up. And that's the best case. Some button might even disappear altogether. So what do you do? The first thing is, within the Android system, and this doesn't just apply to Android Wear, but to all Android devices, there is this attribute called fit system windows equals to true.

And it's basically something that we have built into the operating system to take care of the status bar and the bottom home buttons, et cetera. So you could actually use this attribute. But unfortunately, for the eagle eye among you, you will see that it gets rid of all the paddings

of the button. And it is for actually a good technical reason that we're doing that. And Ian Lake, one of my colleagues, have actually wrote a whole blog post about this for the Android OS. So if you are really interested in the deep technical

back story about why it gets rid of padding, then please have a look at his blog post. But for the moment, we need to solve this problem. So what's the simplest way to do this? And it turned out, when I tap on Nick Butcher's shoulder, that he said, oh, why don't you try inside drawable?

And I go, what? Inside drawable? I've never heard of it before. And it turned out to be extremely simple. All you need to do is create an XML file. And I'll run you through quickly all five lines of it, including the top line, which is just inset. So one thing that you need to do

is to specify the drawable that you have within that. So in this case, it's just the heart shape that I have. And then next, just put in the inset. And what it does is it pads it out. And so now you have a lovely drawable

that's properly padded and takes care of the chin. So that's all great. We coded it. It works. So what's next? One of the things that the developer asked me is, hey, with all these variety of Android devices, should I go out and buy all of them in order to test it?

So it really depends, because if you like your watches and you want an excuse to go out and buy all your watches, then fine. Go out, talk to your boss, and say, hey, boss, I really need six different watches. I need to use the corporate account in order

to do that, to test it properly. Fine. You go ahead and do that. But if you're a little bit strapped for cash, if you're just testing out a startup idea, et cetera, we have actually put up all the different screen combinations that we have as emulator images in Android Studio.

So all the different configurations that is in the market, it is in this. In fact, I think about a year ago, we even put up images of watches that was to come. And we go, oh my god, have we just leaked some information?

And luckily, it turned out to be fine. But yeah, this is the one place to basically have a look and see all the different screen configurations that we have in Android Wear. So next, the Wear UI library. This is something that we have launched at Google IO as a beta

and now it is actually a finalized version, so you can use it in production. And what happened previously is we iterate very quickly and we built it up relatively fast under a closed source library called Wearable.

And it includes other components in Android Wear. But as the platform matures, we actually graduated it to become a component of the main Android support library. And you might ask us, why are you doing this? Why are you putting time into moving, essentially,

a class to another? First thing is not as simple as that, because we actually also took the time to review how the developer community have used those classes and see basically how those classes are interacting all together.

And also, by moving to the main support library, there are a couple of advantages. So the first one is you can expect much more frequent update. So previously, the library update was tied to OS updates, so they're much more infrequent, maybe once a year, maybe once every six months. But now, because support library rolls out

once every four weeks, once every six weeks, then we can be much more responsive to your feedback, especially around bug fixes. So that's the first thing. The second thing is the naming consistency. When we were a separate project, we basically named things whatever we like. And that turned out to be a bad thing

when you're really skilled in using the Android support library. So by bringing it together, we increased the naming consistency. But there's a little bit of a catch, because if you have used Android Wear 1.0 and any previous version of the support library,

then some of the methods will change. But they tend to be a one-to-one kind of mapping. Last but not least, it is now open source. So people have been asking me, hey, can I have a look at your code? What have you done to my view? And because we are now part of the Android support library, there is a whole open source process around it.

So you should now be able to check it out from GitHub and see what we have done. And all you need to do in order to use it is by just setting this line into Gradle. And from the keynote, I've just checked.

It is now 26.0.2, if you wanted the very, very, very latest version. Sorry about that, a typo. Next. So what have we done with all the classes? There are three things that we have done with the classes.

The first is to migrate. So a lot of the classes we just took from the old package and moved it to a new package. Change some of the naming in order to make it consistent. And those naming are mainly around the method names and attribute names. So an example of this will be the box inside layout.

That thing that I showed you earlier where it groups all your components to the center of the square. That's one of the classes that we have migrated. The second one is merge. So in the previous version of the Android Wear library, we have WearableRecyclerView and WearableListView.

And developers are going, hey, which one should I use?

They still exist in the old library. But for new development, we're not recommending

those classes for use. And in terms of package name, it moved from WearableView to Wear.Widget. So does the namespace change? And if you want to check out how the different views kind of all map together, if you could search at the top

using the Wear UI library, and then there's a section that describe in a big table basically all the different classes and what they have become. And if you have any questions, just DM me on Twitter and I will try our best to answer those. So that's clearly an overview of what we have done.

And what I want to do is to dive a little bit deeper into some of the things that I find at least when I was using some of the classes that is within the UI library. So the first thing is, although I said, hey, the box inside layout is really simple,

when I change it to the new library, this is what my view looked like. And I go, oh my god, what is wrong? And there was no error from Android Studio whatsoever. And I go, oh, come on, this is supposed to work. So I should raise a buck against my team. And then I go, oh, yeah, by the way, this have changed.

So if I go back, this previous attribute is called layout box. And now it's changed the box to the edges. Woo-hoo. And I go, wait, how come Android Studio didn't warn me? And they say, oh, that's kind of like a bug slash feature

of Android Studio that if you have XML configuration file and the attribute changes its name, it actually does not highlight it to you. So if you have views that you build up programmatically, any changes to the method names will be picked up automatically. But if you have layout attributes in Android Studio,

that in itself is not picked up automatically. The program will compile, but it will not run correctly. So if that does happen to you, then I will recommend that you just go and check the reference and see which one is wrong. In the meantime, I have raised a buck against Android Studio

and just say, hey, can you guys please have a look at this problem because it's quite easy to fall into if you have a layout XML file and certain attribute changes its name. So hopefully, we'll have a proper fix at some stage. So this is what it looks like afterwards.

One line change. Next, so in Android Wear, a lot of things are around. And so how do you do something like this where you have a recycler view and then you want a gray circular view around a drawable?

So in Android Wear, in the previous version in gray, we have a circular image view and we have a circular button. But what we find is developers actually wanted something that is a little bit more flexible. So we have changed those to run the drawable from circle image view at the top. And what that enables you to do is not just

to create circles, but also to create rounded square or rounded rectangle as well, so you can specify a radius. And then the second one, instead of building our own circular button, we just go, wait a minute. If you kind of squint hard enough, it's just a floating action button. It's a FAB. So why don't we use that?

And so that's what we're doing. So we're just reusing the design library component there and instead of kind of doing our own thing. So if we have a look at it around a drawable, it looks really sensible. So if you want to do something really simple like this, have something in the middle of your screen that's circular,

you can just specify the radius. And you could put the radius in DP and then just multiply it by a number and that will give you the pixel. Very, very simple. But what if you want to do something like this, where you have a class within a class

within a class? So you might have your activity and then you have your recycler view and then you have your view holder. And in the radius, you can't actually get access to the resources. So when you're doing that, you can hard code it, not recommend it.

Or what can you do? So what a way to get around that in this instance, if you just want a circle, is by setting it to the maximum integer and the system will take care of it. So if you set the radius to a ridiculously large number,

we will basically work it out and become a circle. And this is the kind of thing that, the kind of feedback that we really want to hear from you where you go, hey, in certain instances where I'm using your class, I'm having difficulty in doing certain things. Can you tell me how to do this? And some of this might have an answer already.

So like this, we have an answer and we'll probably need to update our documentation to just tell the developer that, hey, set your radius to maximum and we will take care of it for you. Or maybe there are certain use cases that we're not taking care of in real usage that we should be taking a look at.

So please do let us know if there are instances that are like that. This library is relatively new. It literally just went final, I think, back in August. So yeah, just DM me with any comments or any questions that you have with the Wear UI library.

So this is a preview of tomorrow's talk. Some of it is not strictly UI, but a lot of it is to do with a larger kind of UI pattern. So I hope that you will see some benefit. And some of the advice is not just for Android Wear,

but for any IoT project that you may be doing. So the first thing is, actually, the first point is related to Android Wear. Tell us if your Android Wear app is standalone. So since 2014, when we launched Android Wear, we have a couple of ways that you can connect the watch

to the phone. The first way that we launched with was Bluetooth. That's like the table stake. And then subsequently, we have added Wi-Fi and LTE to the mix. And with Android Wear 2.0, you no longer need a component on the phone. And you could just send HTTP requests directly

from the watch. And what we would do is, on the watch, we have a proxy. And we will work it out automatically, which route it should take. So if it is connected to the phone, and the phone have good Bluetooth connection, then we'll just use the phone. Alternatively, if the phone is not around, we'll switch on the Wi-Fi and basically

deal with it from there. So it's a really simple way for a developer to develop. And you could just use the connection logic that you have already got on your mobile phone app and just run it on the watch. And it will just work. And another benefit to this is, of course, supporting, actually, iPhone users.

So Android Wear supports both Android phone and iPhone. And for users that are on the iPhone, of course, we can't actually deploy an extra module onto the iOS app. And also, it adds complexity, because you might have different teams. And if you need to coordinate multiple teams to do one thing,

it just makes it that much more difficult. So hopefully, with this new architecture, it's much simpler for you to build for both Android and iOS. It will be essentially the same code. Last benefit, but not least, is that we have now got the Play Store on the watch. So the user can actually download your app directly

from the watch itself in Android Wear 2.0. So what do we need in order to end up on the Play Store on the watch is adding this little metadata tag. So you need to tell us that your Android Wear app.

So this will be the Android manifest of your Wear app, in your Android Wear app. You need to tell us that the app itself is standalone and equals true. Then we'll go ahead and put it onto the Play Store on the watch. The reason why we're doing this is just in case that your app has certain assumptions built in,

in terms of relying on the phone app to do certain things. That's why we are kind of building it in such a way. If you have feedback on this, then we would love to hear it. Next, standalone architecture. So another question that I get asked quite a lot

is, how should I architect my application, not just for web, but for all the different form factors? And we have all been there. And this is the normal diagram that you have seen in a lot of conferences, including ours, actually, where we go, hey, we all know model view controller. The problem has been solved.

You should just kind of put the model and put all the display logic on the device, solved. This may have been solved for 10, 15 years. Yeah, don't worry about it. It'll be fine. It will just work out.

Model view controller applies. But when you actually do that, there's some very precious things I play. And hopefully, I'll go through a couple of those with you. So today, as many of you know, the world is very much a phone-centric world.

But what we're seeing is that users have increasingly added different devices, really used the different devices for that use case. And trapped that developer quite mobile first.

And one of the things I'm doing for mobile is to take a phone number. And that's fine to a certain extent. But what happens is when you take a phone number, then it's very easy to then make the assumption that the user only have one device. And I've seen time and time again

that when we go to a developer and they're saying, hey, I'm really interested in developing a standalone Android Wear 2 app, can you tell us how can we get around this? And then when we look around, look at the system architecture, they have built certain assumptions that make it extremely hard.

One of them is basically assuming single user, single device, which means that you can only have one active security token. And if you do that, then what tend to happen, and I'm sure that you have encountered apps whereby if you log into one device, it logs you out of another one. And that's something that is really, really frustrating

as you expand to different form factor, or maybe even if your user just have two phones. And so I would argue that even if you don't do the whole shebang, the whole full automatic synchronization, you should at least assume

that a user have multiple device. And I'll categorize that into three different level of support for multi-device. So ranging from the simple to the complex, so if you're just starting out, especially on your weekend project, then I would say just assume that you can actually

log in simultaneously on multiple device. And what that means is assume that there will be a multiple active security token that your user will be using. Second, have a menu kind of refresh to sync the device. So let's say you have order a taxi on your watch,

and then when you unlock your phone or when you launch the app, then you just go to your back end and say, have this user order anything else from any other device. And basically add it into your app. So those will be also very simple to do. And then once you have achieved your Series C funding

for your startup and you have a lot of cash and you want to build the best, best experience, then of course you can do the whole fully automatic syncing all the device all the time via Cloud Messaging so that all the state of your app

is synchronized among all your application. But at the very, very minimum, I would argue if you are starting a new project today, please assume that the user have multiple devices. That's the very, very minimum. Before I finish off this topic, I just want to talk about one more thing, which is OAuth.

So on Android Wear, we have created a new API in order to do authentication via the phone. So what happens is when you click on a link, or sorry, when you click on a button on a watch, then we can launch a OAuth flow on your phone.

So there will be a web page, and it supports both iPhone and Android phone for the user to type in a username and password on the phone and log in. And it has been really, really popular for our app developers. But one of the things or side effects of having a Play Store on the watch

is that it could be the first time ever that the app developer have actually interacted with your app on the watch. And so previously, you might assume that, hey, the first time the user come to me will be via the phone. But now it could be from the watch as well.

So when you're launching the OAuth flow from the watch, we will also argue that you need a register button, because this could be the first time the user have actually ever encountered your app. So in your OAuth flow, please add the register button as well so the user can register as well as sign in.

So that's standalone. Last but not least, Android Wear for China. So not many people know this. We actually have Android Wear. And it is actually our second around the world. The first is, of course, the US.

So important market for it. We have a lot of users that is using it in mainland China. Not all of Google. So before you use any of the Google Play Services API, you will really need to check that they are available.

To be honest, these are good practices anyway, but just want to highlight the two ways you can do this. The first one is an all or nothing kind of way. So when you connect, and if the connection fail, you can detect whether the error code is because the particular API that you're requesting

is not available. So this works really well. If you have five APIs and they all need to work together, then please do check that using this way. Alternatively, you might have five different APIs. And if three of them work, your app will still run. Then you should do this, which

is to check for a whole bunch of APIs. And then before you use a certain API, you just check that they're available. And if it doesn't, you might want to fall back onto other kind of flow. To help you develop that, we have actually joined up the Google Play Services

that is for China and for the rest of the world. And the version that you need is 10.2.0. So if you compile your application using that, then you could run the same application, both within China and outside. Well, two important things to note

is, one, if you don't use any of the services that is on the screen, so you don't use Google Fit, if you don't use the Fused Location Provider and you don't use the web data layer, you actually don't need to include it at all. And it's just there if you need to use those services. And then the second thing is, especially around the Fused

Location Provider, if you do use location on where, then please use this. Because what it does is, behind the scene, again, just like selecting the best connection, we also select the best provider of location for you. So let's say the watch is paired to an iPhone, then we'll use the iPhone current location

to feed this particular API. If it's paired to your Android phone, we'll use that. Or if the watch is disconnected but you have a GPS chip with inside, then we'll use that as well. So we do all the logic for you, as well as doing all the battery optimization. So if you are using location, highly, highly

recommend that you use the Fused Location Provider. And in order to help you test it without having you pay for a ticket and go to China and test your app, we also have the Chinese version of the emulator available from Android Studio. So you could actually test how your app

runs against the China version of the Google Play services. And for more tips on how to build apps for China, please search for this page, Creating Android Apps for China, where we have got a whole bunch of different tips depending on what your applications need.

Just jump to that section. And with that, just to summarize, API 23 with the RAN and not RAN is incredibly powerful. Please do try it out. Second, the UI library, we have just launched. So any feedback is welcomed.

And if you find any rough edges that you just want to discuss privately, just DM me on Twitter. And last but not least, well, three things. Tell us if your app is standalone. So that could be an app, watch face, or a complication data provider. Tell us if they're standalone.

Second, really, really important is to assume that your user has multiple devices. They are not cavemen. And last but not least, we are also in China. So if you have an app that you think fits the Chinese market, then please do check it out. And with that, thank you.

Do we have time for questions? I think we have a couple of minutes for questions. So if anyone has a question, there is a microphone there. Hi. Do you know if there's going to be any support for lifecycle

in Android Wear? So the question is the support for lifecycle in Android Wear. The answer is yes. Android Wear is basically Android. So any tool that you use for Android, you can use it on Android Wear. So the only thing I would say is around,

maybe the difference is more around the Google Play services or the Firebase library that maybe not all the functions are supported there because of UI that they might need. But for things like lifecycle, it should just work.