 Hey, everyone. So I'm Matt Scales, as Matt said. And I'm here to talk about the Platinum Elements. The Platinum Elements are our way to help to make using the latest and greatest web platform features easy with Polymer. So the web is getting a lot of really cool features recently. And this is great for users. It's great for developers. And it's also great for businesses that want to be able to do exciting new things without tethering themselves to a closed platform. But it's also getting complicated. There's a lot to learn now. And realistically, you can't learn all this stuff anymore. Now these new features are actually so powerful because they're very deep. So what can we do about this? Well, luckily, there's an element set for that. So what we've done is we've created the Platinum Elements set. And the idea here is that these elements wrap these complex APIs and provide the most obvious use cases, simplified outs, that you can just drop them in. So the Platinum Elements, most of the features that we're wrapping here are only implemented in a few browsers, pretty much just Chrome, actually. But the Platinum Elements themselves, if you drop them into your page, they will just gracefully degrade if you use them in a browser that doesn't support them. All of these features are enhancements. The traditional web has always happened in a tab. And these features are allowing you to break out of the tab and do things outside of that environment. So we're going to talk about offline, push messaging, and device access. So first up, offline. So when I say offline, really what I mean here is removing your dependency on the network. So in order for your app to work offline, you need to have all the resources for your app on the device. And this is a huge performance boost, even if you actually have a good connection. There are lots of people who have no connection for various parts of the day. I commute through London on the underground train, and I don't get any connection there. There are also lots of people with just bad connections. So there's another part of my commute I go through the countryside on a train, and I have pretty bad 2G for big portions of my commute. And I live in a first world country in a huge city. So this problem only gets worse when you go to remote places or emerging markets. And as I say, this actually will improve the speed, even on a good connection. You don't have to go to the network at all for a lot of these things. Now, a lot of people, they're not quite sure how this will work for their app. Surely it's on the web because it needs the network, and that's a good point. So offline takes different forms for different applications. So here we have a simple, this is actually a Google Doodle. It's a crossword. This can be entirely offline. There's no online component here at all. You put all the resources in the local cache, load them all up. Everything will just work. So this is a very good case. Something like Gmail, obviously that's network-based, right? But there are things you can use. There's the app shell, all of the user interface, the new message box here. And obviously you can cache messages that have already been downloaded so that the user can still read them even while offline. The same applies here to something like a chat app or something like that. And then worst case scenario, your app really, really just needs to be online to do anything. You at least can control that offline experience. You can put your own branding, your own message. So by default, in Chrome, you get the little offline dinosaur. And if you click it, you get a game. You could put your own game, something to do with whatever it is that your business is about. What does this have to do with Polymer? Well, there's an element for that. Specifically, PlatinumSW or the set of PlatinumSW elements. The SW here stands for Service Worker, as Matt said. It's a new feature implemented in Chrome, but it is coming to other platforms. Mozilla have their implementation, I believe, pretty complete. And it's in nightlies. And they're just waiting to make sure it's absolutely stable. And other browsers have shown great interest in implementing this. So how does this work? Normally, you have a page, and it requests resources, and it just goes to the network to fetch them. With Service Worker, you add this intermediary, this script that you've written. And any time the page requests a resource, this could be the initial page navigation. It could be images, scripts, CSS, or XHR, or fetch. The Service Worker gets to say what to do. And it can go to the network, and go to the server, and fetch that if it wants to. But there's also a cache API built in with Service Workers. And that stores request and response pairs. So you can seed that cache with the requests for your resources, and then the response that you need to give for all of those resources, and just return those instead and never go to the network. And now, thanks to PlatinumSW, you can get the benefits of using Service Worker, just by adding a couple of elements to your page. So PlatinumSW register. Here just says, I'd like a Service Worker in my app. That's not really going to do a great deal in its own. But we configure it by adding some elements inside. Oh, I don't know what happened to the formatting error. So PlatinumSW fetch allows you to say, how to handle certain kinds of resources. So you see here that we've got this path. So anytime a resource is fetched that matches this path, or this path pattern, we're going to handle it in a particular way. And you can set these up for as many different parts of your site as you like. PlatinumSW cache, which is going to point out this bit here first, the pre-cache. This says to the app, as soon as you load this, I want you to put all of these things into the cache straight away. These are the critical parts of my application. So as soon as I load, put them into the cache so that they are there for the very next time that the page is loaded. So here I've just got, as an example, index.html and the CSS file. But you'd put in JavaScript and images and whatever you needed to show probably your home page and maybe the shell of your app. And I kind of skipped over this four. So there's a handler in the fetch. And there's a default cache strategy in the cache element. They're both set here to network first. But in there, you put in what you want to happen for these resources. And the one in the default cache strategy is what should happen when the current resource being loaded doesn't match any of your fetches. So what's all that about? So there are a bunch of different cache strategies built in. Network only is the simplest one to explain because basically the service worker doesn't do anything. It just lets it go straight through to the server. Network first will, so for that resource, we try and fetch it from the server. And if that doesn't work for some reason, then we'll look in the cache instead. This is better than not doing offline at all. But it's slightly problematic because that network connection, if it's just a bad connection, it could take two minutes for that to time out, which would be terrible performance. So better performance, cache first. If we have that resource in the cache, load it straight from the don't even consult the network. That one's always going to be much faster for stuff that you've got in the cache. If it does go to the network, then when that's fetched, it sticks it in the cache for next time. So you can use this for what we call read through caching. And then my favorite one is called fastest. It's basically you go to the cache, you go to the network, whichever one comes back first, use that. Usually, for anything that's in the cache, this will be whatever is in the cache. Not always, apparently. But when that network request, because the network request always happens, and it always updates the cache when it comes back, it means that you're only one refresh behind. So you're still slightly sale, perhaps. And the even better one, I guess, is your own thing. You choose the behave that you need for your application. So we had one that was network if fast enough. So it would try the network, and then there would be a set timeout, just after 500 milliseconds, said, no, you're too slow. Go to the cache instead. So you try and get the thing from the network. So with these building blocks, we can build all sorts of different applications, or ways of dealing with offline in your application. So simple read through caching, you could set it up so that you don't have any fetch handlers. You have a default cache strategy of network first or cache first, whichever you like. And that will just, every time a resource comes through, it will have to go to the network first, but then it will stick it in the cache, and then next time, you can get it from the cache. So it will build up the cache as the user goes around, but you don't do any pre-caching. You can obviously pre-cache all your resources, as I said before, so that most of your app works offline straight away. Some resources, you'll have a huge header image or something like that. Maybe you don't want to store large resources, videos and things like that in the cache. So you say, those ones are network only. And you can implement fallback media instead. So that by creating your own handler, you could say, for these resources, if the network is available, get it from the network. Otherwise, we're not going to bother caching these things. Just send back a thumbnail saying, you're offline. You can't see this. Click to try loading it again, something like that. And you can also have user-defined caching. So if you're browsing blogs, blog articles, for example, then maybe they'll have a little button that says cache this to read later. OK, so next up, we have messaging, push notifications in particular. So these are notifications that appear on your device because something happened on a remote server, some trigger completely outside the application. So here we have an example of this. This demo was created by Monica, who's actually speaking later. So here, these are for people who want to receive notifications about cats. And who wouldn't? So you toggle the button on, say, I would like to receive notifications. You get a little permission dialogue in Chrome, which is actually important. We don't allow applications to show notifications unless you have that permission. And that's why we have this UI element so that the user clicks it, and then they get permission notification, permission dialogue, because then there's context for that decision. The user knows why they're having to click that button to say they want notifications. Later on, someone comes along and clicks the Send Cats button. And then later, notification arrives. And this could happen while Chrome is completely closed. And it could happen a long time after. And you get the notification, you click it, and in this case, you get a picture of a cat, which is perfect. Now, how did we achieve this magic? There's an element for that, obviously. Platinum push messaging. As well as sending cats, you could use it for more serious things, breaking news, chat messages, new email, that sort of thing, anything you get a notification for on your phone already. Platinum push messaging allows you to do the configuration of all this right in your application. The server side here is more complicated. And I'm going to just gloss over it and pretend it isn't there. But for anyone who's implemented push messaging on Android, the set up for dealing with Chrome is exactly the same as using Google Cloud Messaging on Android. Any bit of client configuration at the moment. And we hope this will go away in the future. But right now, you need a web app manifest file. And in there, you need to have at least this GCM sender ID, which you get from the Google Developers Console. Again, kind of going to gloss over that here. So here's the actual element. So here, we've just defined statically what those notifications are going to look like. So we've got a title, a body, an image show, and a URL to go to when we click. You can actually set all sorts of other things on this notification, like even the pattern of vibration that the device should use when the notification is shown, which is pretty cool. But it's a bit boring to have the same message every time. So instead, we have this configuration option, this message URL. This URL will be fetched when it's about to send a popup notification. And that will instead have a bit of JSON that describes what the notification should look like. It has all the same options. And this allows you to dynamically make those notifications based on whatever data your server has at the time. Here, I've got a simple URL. It's just .json. But obviously, you could put in query parameters or something like that that are specific to the current user so that you can get message details that way. There is actually, in the future, you'll be able to just have the element with no configuration because you'll be able to send a body with the push notification. That isn't actually implemented yet. And then as I say, you don't want to actually start subscribing for push notifications without asking the user. So there are a couple of things to do there. I've written this code snippet in ES6 style, as you can see. So we get a reference to the element. And then we hook up the toggle button to a little function that just says, if you've just enabled it, run the enable method. And if you've disabled it, run the disable method. And then finally, when the subscription information changes, we get an event. And we can send that subscription information up to the server, which will then know how to send messages to you. So the final thing in our whistle stop tour features is device access. This one's a bit more experimental. It's actually not even only in Chrome. It's only on Chrome OS at the moment. And it's behind a flag in Canary. But this one's a bit more interesting. So I wanted to give you a sneak preview. So web Bluetooth is the API behind this. And it allows you to connect to nearby Bluetooth low energy devices, also sometimes called Bluetooth Smart. And while this is only an experimental API, thanks to my colleague Francois in Paris, there's an element for that already, the platinum Bluetooth element. This is, again, pretty simple. You create a device element, platinum Bluetooth device element. You give it a services filter. It just says, I want to connect to some device that is advertising these services. So here, we're just looking for something that advertises heart rate. And then inside that, we configure it and say, we'd like to know a particular characteristic of those devices. So we say, the service is the heart rate service, characteristic body sensor location, which I believe is where on your body you're wearing the sensor. And then we hook up the value of that characteristic just using normal attribute binding. So we can just take that data and put it somewhere else in our app, in this case, in a span. Now, these names for the services and the characteristic heart rate body sensor location, they look pretty nice. Unfortunately, not every device has the services and the characteristics with nice names. So you may have a UUID, a long string of hexadecimal digits. But you can probably find those in the documentation for whatever device you're connecting to. And then, similar to the notifications, you don't want to actually pop up the dialogue that says, hey, I'd like you to choose a device to connect to unless the user is trying to do that. So you get a reference to the device element and then you call requests, so that you'd like to actually talk to it. And then when you want to read, because Bluetooth low energy is usually for passive devices, the values aren't streamed to you. So you have to call read to make that property update. But you could do that in a set timeout or something like, oh, when a button is clicked. Bluetooth low energy does have the concept of notifications, which will mean that you can get an event when the values change. That isn't actually implemented yet in the Bluetooth API. So it's not implemented in the element either. Not all BLE devices are passive, though. There was a cool demo produced by a Googler with the Bluetooth API, and I just wanted to show you a little bit. So what he did is he got this grumpy cat toy, and he attached some helium balloons to it so that it would fly. And then he put a little Bluetooth chip inside, a little Bluetooth module, and stuck a rotor in its backside. And then with this little control panel, he then just made it fly around his apartment. Ooh. I apologize for the quality. It's not as smooth up there as I hoped, but let's just appreciate that for a moment. So that was a whistle stop tour of new features coming thanks to Polymer. Thank you very much. You can learn more about the platinum elements at this link here, and there is actually a web Bluetooth codelab available in the codelab area. And I believe we have some Chromebooks up there if you want to try it out. So thank you very much.