Bluetooth is an amazing technology
that allows us to wirelessly communicate with devices.
Bluetooth has been around for a long time.
But since the introduction of Bluetooth low energy,
we've seen a massive rise in the number of Bluetooth devices
around us, everything from headphones
to heart rate monitors.
BLE is cheap and consumes very little power,
which makes it great for mobile devices.
Soon, everything from parking meters to vending machines
will have a BLE chip inside.
But there is one common problem.
To interact with any of these devices,
users need to install a native app-- an app for the San
Francisco parking meter, an app for the Palo Alto parking
meter, an app for the Mountain View parking meter.
Each app adds massive amounts of friction
for users that just want to interact
with the device in front of them.
Soon, the number of apps in our cellphones
will become unmanageable.
More importantly, why should you download an app for things
that you're going to use once or twice?
Wouldn't it be great if all of these
just worked directly from a web page?
My name is Giovanni, and I'm an engineer on the Chrome team.
And I'm here today to talk to you about Bluetooth on the web
and how the Web Bluetooth API that we're implementing
in Chrome, combined with the Physical Web,
will change the way you interact with the devices around you.
Let's take a step back for a moment
and talk about the Physical Web.
The Physical Web is an early stage experimental project
that allows users to discover devices around them.
Using BLE, objects can work as a URL
that the Physical Web picks up and presents to the user.
For example, a movie poster can broadcast a link to the movie
trailer, or a parking meter can broadcast a link to a website
where you can pay for parking.
In a way, the Physical Web concept
is similar to that of QR codes, but the Physical Web
offers some key advantages.
First, the Physical Web will eventually
be part of your smartphone, so there is no need for users
to download an app.
Furthermore, the Physical Web is more convenient.
Users shouldn't need to climb on a ladder to snap a QR
code on their small detector.
With the Physical Web, you can similarly
discover devices and objects around you.
But the question remains, how do you connect with them?
This is where Web Bluetooth comes in.
Web Bluetooth will allow users to seamlessly connect
to the devices around them without the need
to start an app and will enable developers to build
cross-platform web apps.
For example, users would be able to walk up
to any parking meter in any city and then use the Physical Web
to navigate to the corresponding web app.
Once a user pays for parking, the websites
can then notify the parking meter directly, using BLE.
The same concept can be applied to many devices
where power consumption is an issue and internet
connectivity is not viable.
We are currently working on the API
to make all this available to developers.
But before we show you how the current proposed API works,
let's review some BLE concepts.
A characteristic contains a value and descriptors
that describe that value.
You can think of a characteristic
as a type analogous to a class.
Services, a service is just a collection of characteristics.
For example, a heart rate monitor
has a heart rate service.
The heart rate service contains a characteristic,
called heart rate measurement, which
calls a value of the user's heart rate.
A website could then connect to the device
to read and write to characteristics
or subscribe notifications from characteristics.
It's pretty simple.
The developer will request access to a device filter
by service.
In this case, heart rate.
The system will then ask the user
to confirm that they want the web
app to pair with the device.
Once the user has granted access,
the developer will then be able to get direct access
to the service on the device, which means that now you
can get access to the services characteristics, which
in this case, will let you read the heart rate from the device.
And it's a very similar process for writing data
to a Bluetooth device.
You get access to the device, to the service
and the characteristic, and then you called writeValue.
It's really that simple.
And a slight more enhanced use case
is the ability to be notified when data on a characteristic
changes.
For example, the heart rate measurement characteristic
allows you to subscribe to notifications.
Now, every time the heart rate changes, the website updates
the value shown to the user.
Now that you've seen what the API looks like,
you probably want to get your hands on it.
While we work on finishing up the API
and integrating it into Chrome, we
have built a Chrome apps polyfill
that you can use to try out the API.
You can embed the polyfill in a Chrome app
and use it in a Chromebook to scan for devices,
connect to them, read and write characteristics,
and subscribe to notifications in the same way
you would using the Web Bluetooth API.
Don't have a BLE peripheral available?
Fret not.
We have built an Android app that
lets you simulate a BLE peripheral with services
and characteristics that you can read, write, or get
notifications from.
By using both, we are sure you will be able to try out
the Web Bluetooth API.
Today, we have given you a quick glimpse into what
we are enabling on the web.
You can find out more about how to play with it at this URL.
We look forward to getting your feedback on the API
specification in the W3C group and learning about your use
cases.
Thanks, for watching.
And remember, stay connected.
[MUSIC PLAYING]