Web Bluetooth (100 Days of Google Dev)

Web Bluetooth (100 Days of Google Dev)


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]

7 Comments

  1. I’m assuming, requestDevice(filters: hr_service) should have been requestDevice({filters: hr_service})…

  2. Too bad that Chrome BT LE Api is limited to Chrome OS only 🙁 Please bring BT LE to normal Chrome!

Leave a Reply

Your email address will not be published.


*