Imagine as soon as you sit down in front of your TV at home,
your phone instantly shows you what's
on your favorite channels.
Or as you walk up to your daily bus stop,
your phone tells you that your bus is delayed 20 minutes,
but you can take the express instead.
Or perhaps you have hearing difficulties
and need specific accessibility assistance at your bank,
but instead of having to spend the first five
minutes explaining this to the employees, as usual,
they're already aware of it and ready to serve you.
As a developer, the key thing here
is having more context so that you
can provide a better user experience
and in fewer, or no steps, at all.
Hello, I'm Timothy Jordan, and this
is Developing with Beacons.
A common beacon that you'll recognize is a lighthouse.
This simple but important technology
has helped ships navigate safely through busy shipping
lanes and dangerous coastlines for hundreds of years.
Today's technology provides us with a new type of beacon
whose underlying concept is the same,
but otherwise looks a lot different.
For one thing, instead of a large tower
with a gigantic spinning light, they
look like this or this and this or even this.
And they can last for years on the same battery.
But, more importantly, when you use Google together
with your beacons, you get an open and flexible beacon
standard called Eddystone as well as APIs
that allow you to register, manage, and detect beacons.
Let's take a look at how all these components work together.
Say you've got a great idea for using beacons
to improve user's lives.
A service that helps commuters with public transit.
It's an app that detects bus stops and train stations
and provides up-to-date information concerning
their favorite routes at those stops.
You'll first need some beacons.
One for every stop and station.
Several beacon types will work, but we recommend one the
supports Eddystone, which is a new open format for beacons
that anyone can use.
It offers a common format to build upon
and a means of extending it to include new features
and use cases.
And it does all of this in the open on GitHub under the Apache
2.0 license.
Now these beacons work with both Android
and are already available from six manufacturers today.
Once you get your hands on a beacon that
supports the Eddystone standard, you'll need to provision it
and then, depending on your use case,
you'll want to register it with a cloud service
and attach data.
Provisioning is simple.
It just means specifying the basic beacon settings
such as the Eddystone frame type, the transmit power
and the broadcast rate.
Your beacon manufacturer should have instructions
about this process and they're likely to have
either an app or APIs available for this step.
Now some beacons even come pre-configured for you.
Once provisioned, your beacon can start broadcasting itself
to the world.
If you're employing a physical web beacon with the Eddystone
URL frame type, you set the URL in this provisioning step,
and you're done.
For all other frame types, you'll
want to register the beacon and perhaps attach some data.
Registering happens with the Proximity Beacon API
by providing basic information such as the beacon advertise
identifier, status, whether it stays in place, like a bus
stop, or moves around like an actual bus, a place ID,
a lat-long, and a few other fields.
This step also enables various Google integrations
like the places API and the nearby API, which
we'll talk about in a moment.
Finally, you can use the Proximity Beacon API
to add some attachment data.
This is where things really start to get powerful.
You can add attachments that will have a namespace, which
corresponds to your project ID in the developer console,
a type, which is a string that specifies what kind
of attachment this is, and is unique in the namespace,
and 1K of data.
You'll notice by the sample data,
that it's enough for some strings or even some JSON,
but you wouldn't want to start encoding JPEGs in here.
One last thing on the Proximity Beacon API,
you can also use it to manage your beacons at scale
by detecting lost beacons or low battery
and performing activation, deactivation,
and decommissioning.
Watch for these APIs to mature with your feedback
over the coming weeks and months.
OK.
Now you've got a beacon that just
sits around broadcasting its ID to anyone who will listen.
Well, truth be told, it's going to keep broadcasting its ID
whether anyone is listening or not,
and I can't decide if this is incredibly noble or perhaps
sad.
But let's just call it dedicated.
Next, we'll need to set up our app to listen for our beacons.
We could write our own service to scan for the beacons using
Bluetooth LE and then look them up with the Proximity Beacon
API, or we could let the nearby Messages API do
all the heavy lifting for us.
I'd recommend the latter.
First, you'll subscribe to Messages from the nearby API.
Included in this subscription is our Transit Project Namespace
since we're only interested in those beacons.
Nearby then keeps an eye out for these beacons.
When one is sited, it grabs the beacon's information, including
attachments, turns them into messages,
and passes them over to your app.
Now that's it.
We've now got working beacons and an app
that uses them to make the awesome happen for our users.
Beacons are all about adding context
to the world, whether at a specific place
like your favorite store or moving around
like a food truck.
With this context, you can provide an experience
for your user that requires fewer steps while being
richer and more accurate.
We have excellent videos and documentation
on all the different aspects of these platforms and format.
Check them out for more details on each and to get
started adding context to all the things.
Thank you
[MUSIC PLAYING]