HOI LAM: So, with the
Google Beacon Platform,
a lot of people actually
compare it with GPS.
And I thought it could
be quite useful to take
a step back and just see
where we have come from.
So one of the first hand-held
unit of GPS came in the market
in 1989.
And at that moment in
time, all it could do
is latitude and longitude.
And because of
security concerns,
the satellite signal has
actually been degraded,
and as a result, it
wasn't even that accurate.
And that was all it could do.
However if you fast
forwarded to today, then
maps and navigation
is just table stakes.
If you think about
the other things
you can do with
location or location
linked contacts,
that you can think
about things like Check-in,
for example, very easy.
Leaving a tip for
fellow travelers,
or maybe even dating.
There are some
dating apps out there
that will let you see people
that are close to you.
So if we think about
that, then Beacon
could be one of those
things that, at a moment,
perhaps the kind of things
that we are thinking about
is only a very limited
set of use case.
But as time progresses, then
what we're hoping to see
is, with more contacts,
then you could actually
see more innovative use cases
that we have not thought of.
And that's why I'm really super
excited about the Google Beacon
Platform.
So some of the use cases for
today that we can think of.
Instead of saying that
you're at a museum,
you can tell the user
that they are standing
in front of this
piece of artwork
or what is in the room itself.
If you're thinking about
getting the old-fashioned taxi,
instead of booking
through the app
and actually linking
it to the user,
imagine that you can wave any
of the cabs on the street,
and because of the beacon
that is on the cab itself,
you can actually pay via
an app to the taxi driver
without going through the
booking process itself.
Imagine if you can go into
a restaurant and someone
may sit you down or you
might just find a free table,
and immediately you're
able to browse the menu.
And then order not
just saying hey ticket
number five, but actually
say, deliver to this table.
So those are some of the
things that you could imagine
with increased contacts.
So I'm going to talk about the
three components that made up
the Google Beacon Platform.
The first one is the hardware
Eddystone frame format.
Second is the
Proximity Beacon API,
which allow you to add
attachments and essentially
add more contacts through
the beacon itself.
Last but not least, after you
add those attachments and then
associate it with
those beacons, then you
can use the nearby
API to retrieve
those in apps that's built on
both Android as well as iOS.
So we'll just go through
each one of those in turn.
And, fingers crossed
that the [INAUDIBLE]
demo and live coding will
work as well as we go through.
First component is the
Eddystone beacon format.
This is a open format
that we'll publish.
And it is used for the
Bluetooth low-energy beacons.
And as of today, we
have 18 manufacturers
that are manufacturing
to those standards
that we have certified.
And apart from being
open, what else
is different about Eddystone
compared to the Auto Beacon
platform that you
might have seen.
The second one is cross platform
So once those Eddystone beacon
have been deployed,
we provide a library
just for Android and iOS.
There's absolutely nothing
to stop you to extend that
to other platforms because
we have published those frame
formats.
So any device that support
Bluetooth low-energy
can potentially be a
client of Eddystone.
Last but not least,
it's extensible.
So if we think about the
traditional Bluetooth beacon
format, then the table stake
is basically an identifier.
So the beacon itself
will emit an ID,
and that's all it
does continuously.
It doesn't take into account
which mobile phone is
next to it and
record it, it's just
a one-way communication of IDs.
But taking that idea,
we have actually
extended to different
types of frame formats.
The next one we have
the Eddystone-URL,
also known as the Physical Web.
So what we have done is, we
allow you to encode a URL
and put it on the beacon, and
acts as a discovery service
for your website or web app.
And you can hear more
about the Physical Web
in the next session
with Scott Jenson, who's
our lead on the Physical Web.
So if you're interested
in that, I strongly
advise you to attend his talk.
Next, Eddystone-TLM.
So this is the
telemetry frame, which
reports the health of the beacon
in terms of the temperature
or how much battery is left.
And if you are
deploying anything
more than a handful
of beacons, you really
don't want to go and check
on all your beacons every day
and say, are you still there?
Are you going to die?
And this is massively helpful.
And when I talked to developers,
I was actually quite surprised
at how forward-thinking they are
in terms of not just thinking
about development
and ideas, but also
on the maintenance
of the beacons.
And this is massively helpful
to them, and I have to say,
I did not expect that item of
interest on a telemetry frame,
but that's something that
is truly helpful when you're
deploying in the real world.
And those are just the ones
that we've published so far.
The idea here is that more frame
types will become available
as time goes by.
So if you have other ideas that
could potentially utilize this,
then please do talk to us, and
then we can see what we can do.
So that's the Eddystone format.
That's the beacon hardware.
So next is the
software part, and some
of the other interesting
features about the Google
Beacon Platform.
So next I'm going to talk
about the Proximity Beacon API.
So with the
Proximity Beacon API,
you can register your beacon
with the Google Services.
So that means it will increase
the visibility of your business
on Google Service, but
also any application that's
developed on top of it.
So what this
screenshot is showing
is the Place Picker
API for developers.
And developers could
just implement this
and allow the user to
choose the places that's
around them to select.
So for example, if you are
making a MeetMe kind of app,
then you can say,
hey can you meet me
at such-and-such a location?
This could be helpful to you.
And if you deploy
beacon and register them
using a Google
Proximity Beacon API,
then that will help enhance
this and any app that
is built on top of it.
Next, as I've
alluded before, you
can add attachments to beacons.
So these could be any kind
of arbitrary payload up
to one kilobyte in size.
So we could envision a lot of
JSON objects being uploaded
to describe that location
and give the user more
contacts and the developer
more contacts on what's
going on around them.
Last but not least, maintenance.
So after we've emitted
those telemetry frame,
it would be really ideal
if you could actually
have a list of beacons
and see how they're doing.
So that's part of
the service as well.
So apart from reporting
on the telemetry frames,
you can also use the cloud-based
APIs to update that data that's
associated with your beacon.
So let's say, if your menu
changed for your restaurant,
you don't need to go
through every single beacon
around your restaurant
to change the menu.
You could just log in, look
at attachments, change them,
and they would be done.
And that's just one restaurant.
You can imagine that if you have
a chain of restaurant or chain
of stores where things
change constantly,
then that is massively
helpful that you
don't need to go around
every single beacon
to change the information
that you're attaching to them.
So how do you do this?
First step is to get
a Google account.
And that could be as simple as
registering for a Gmail account
and then use that.
Next, is to enable the Proximity
Beacon API in your API console.
And then you would create an API
key for either Android or iOS
and OAuth 2.0 client
ID under that link.
And we would strongly advise
that you do all of those steps
before you actually
started coding and running.
We have previously seen
developer running into issues
when they coded the app, and
then accidentally run it,
and as a result it was
running against the wrong ID.
And then after they
registered they
had some problem with caching
and refreshing the ID.
So we strongly advise that you
do all those things up front
and then go to the last step,
and actually the easiest way
that I find personally is to
go to get help [INAUDIBLE]
with a sample project,
compile those and then run it.
So let's see if the demo
gods are working in my favor.
So let's switch to
the [INAUDIBLE].
It's demo time!
So a couple slides
back, a lot of you
would have caught me
saying, hey you got
18 manufacturers of beacons.
And actually, it's a lot more
than that, because today I'm
going to unveil to you one
of the most expensive beacon
that you can buy on the market,
also known as a [? Lexus ?]
6 or [? Lexus ?] 9.
AUDIENCE: Amazon?
HOI LAM: So on here, what
I have got, if we can maybe
do the white balance a
little bit, at the moment
it's quite washed out.
So what you can do is, you can
actually search, or Google,
the Eddystone repo where one
of the tools that we provide
developers is an
application that
runs on Android, which allow
you to mimic a beacon for using
a phone.
And this is really helpful
in the development process,
because you can then change
the ID really quite easily.
So when you register and you
inevitably have maybe bugs.
And when that happens you
could go back and change the ID
relatively easily.
So that's one of the tools
that is super helpful.
And then, what I'm going to show
you is, once you have compiled
the application that I mentioned
in the last slide, which
is the fourth step, at the end
when you compile that Proximity
Beacon API sample, this
is the kind of application
that you would see.
So you need to log in,
and then after that you
can scan for different beacons.
So as you can see, I've
already provisioned this beacon
because I don't know
how many beacons
that will be in the room,
and as a result if I'm
doing a live demo this
could be quite tricky.
Actually, that's a good lesson
for live deployment as well.
So when you're deploying
in a live environment,
make sure that you provision
things like a Faraday bag
or a Faraday cage
for your deployment
queue so that they can isolate
the one beacon that they're
deploying compared to thousands
that may be in their van.
So that's something
that's quite helpful.
So when I click
through, then you
can see some of the information
that I can actually provision.
So things like whether the
beacon itself is active,
or the coordinates,
and the Place
ID that this beacon
is set against.
So right now, it's set
against the strand Theatre,
which is where we are.
At the bottom you can put in as
many attachments as you want.
The type and the data
is totally up to you up
to one kilobyte in size.
So that's the little demo
for the Proximity Beacon API.
I encourage you to check it out.
So next I'm going to talk
about the interesting stuff.
So once you have got your
hardware beacon, stuck them up,
you have provisioned
them and registered them
with the Proximity Beacon API.
Then the really
interesting thing
happens, which is
all to use cases
that you guys are
thinking about.
So with that, what
you can do is use
the nearby API which support
both Android and iOS.
So today, if the demo
god will allow me,
I will try to do some
live coding using Nearby.
So, can we switch
back to the computer?
Thank you.
OK, cool.
So a lot of these will
be fairly standard,
if you have used any of the
Google Place services APIs.
So the first thing is to get
a Google API client and et
cetera, et cetera.
Where we start is when things
get interesting and different
for beacons.
So the first thing
is to just talk
about when the Google beacon,
sorry, when the Google API
client actually connects,
then that's the step when
we go into it and
say, hey, can I
subscribe to some interesting
beacon messages please.
And just to explain how the app
works, I will just show you.
It is a very simple
app, where at the top
I have the beacon
attachment text,
so whatever beacon it
sees, then you run.
And at the bottom for debug
and for demo purposes,
I will also show
the status of where
we are in terms
of the deployment
of the program itself.
So there's the program and
then coming back seamlessly.
So the plan is once we have seen
the various attachment, what
we'd do is we would
just put them up.
And so here is just
a little bit of code
to get an array of
attachments and then
just show them on screen.
So here is where I need
to pray to the demo god
that I can actually
remember what to do.
So the first thing
I will do is, I
will create a MessageListener.
Actually I do have that.
MessageListener.
So the first thing
that you see is,
I need to overwrite it
whenever I see a beacon,
then I should
really do something.
So the first thing
I'm going to do
is to edit to if
I do see a beacon,
is to add the beacon
content to my array.
Add, new.String,
getContent, wait.
OK, so once I put
it into array then
I just need to
refresh the content.
Another thing I'm
going to do is,
I'm going to overwrite
on loss as well.
So once a beacon
become out of range,
then I want to get a message
so that I could remove it
from the list.
BeaconContents.remove,
new.String, message.getContent.
Refresh.
Simple.
So some of you might have
noticed that I actually put
the message that content
into a new string
before I set it on to the
array, the reason for that
is the content will
actually come back
in a byte array and the easy
way to convert that is just
to use a new string to do that.
So tick, explained that.
Next, subscribe options.
So the Nearby Messages API
is more than just beacons.
So the idea here is that
you could potentially
have two mobile devices talking
to each other and one send
message and one
subscribe to the message.
And as a result, there are
various strategy of discovery
that you can use.
But given that we
are BLE beacon, then
our only strategy is BLE.
And because it's BLE, the
timeout time is very long.
I think we don't
actually time out
if you keep on subscribing
to the messages.
So this is necessary
for that to happen.
So I'm going to create
a subscribe option.
And I could use the
builder to do that.
OK, so I need to set the
strategy to strategy BLE only,
thank you.
Loving auto-complete.
And then setCallback,
SubscribeCallback, expire.
And here I'm going to
do BeaconContents.clear
and refresh.
So some of you might question,
hey you know why is a, whoops.
.build, forgot to build.
And yes, some of
you might wonder
why do we have a unexpire
option, given that BLE
is supposed to be always on.
One of the reasons for
that, at least for beacon,
is that a user could
potentially switch off
the functionality either
overall or just for your app.
And as a result, what you
previously expected to work,
it might not.
So you should really have a
look at this kind of scenario
and make sure that it works.
So then now we are
finally at the point
where we can subscribe.
So Nearby.Messages.Subscribe.
And put into Google API
client the MessageListener
we have just initiated and
the option that we have, then
we need to add a callback,
a results callback, and OK.
So once we get the
status back, we
do need to check whether
it is successful.
Success, then we would say
mStatusText, setText, "Success!
Woohoo!"
Else, else, that has failed.
Unhappy face.
We need to actually handle
the unsuccessful event.
Putting in the status, even.
So the reason why we need to
do that is, the first time when
the user is running
your application,
we would then go through
a permission dialogue
to just make sure that, hey,
user, are you OK with this app
essentially scanning
for beacons and running?
So as a result, the first
time when the user actually
run this program, it will always
go through the error statement
here because the
connection will fail,
because the user have not
given you their permission.
So what we'll do is Handle
Unsuccessful Nearby Result,
we will then ask for that.
So if the
status.getStatusCode is
equal to
NearbyMessageStatusCode.App NOT
OPTED IN, then we'll ask.
mResolveError.
And this bit is also important.
So I have also got a cost
variable called mResolvingError
because you don't really
want to [INAUDIBLE] the user
continuously if they say no.
So as a result you would
need some kind of mechanism
to check whether you've asked
them before and they say no.
And what I'm going
to do here is,
the first thing I'm going to
do is say now it will be true.
So by default it's false.
And then after that I will go
status.StartResolutionForResults
and I will need to feed in the
activity, which is this one
and also do request code.
So the request code could
be anything that you want
and what you can
do is, you might
have multiple points where you
need to ask for permission.
When the API comes
back to you need
to know which one
has the resolve.
So one might be
asking for payment,
and another one may be
asking for beacon permission.
So you want to keep track of
which one you are resolving.
And as you can see it
requires a try/catch block.
So if there's any
kind of error when
he's trying to get that
kind of permission,
then he will come in here.
So if the user is saying no,
then we basically should say
mStatusTextView.setText("User
denied").
Great, [INAUDIBLE] permission.
And once the
permission comes back,
it would then come back into
this method on activity result,
and what we should
do is to just check
whether the results code is OK.
And this is just for
clean-ness, it's not strictly
necessary for this
particular demo
because I've only got
one thing to resolve.
But it would be helpful if your
app have multiple requests,
to keep track of which one.
So once we have got
that, then we should
subscribe to messages again.
Great end coding, but
I do have an error.
So let's resolve that.
OK, great.
So let's come back
to end of coding,
but I still have
not run my code yet
so things can still
go very wrong.
And then the next thing
I want to highlight
is when you should stop
subscribing as well.
So let's say the model that
you have is, as the user,
move around a store then your
app kind of changes contacts
or it gives you
more information.
When the user exit the app or
switch to another app, when
the user's no longer paying
attention, then perhaps
you should switch it off.
And what this will do then is
to help with battery life, first
of all.
And also is just good clean
code to just say, hey,
I'm now done let's
unsubscribe and disconnect.
So I just want to highlight
that number eight step.
So I'm going to unlock my phone
and reset my permissions so
that I'm denying this
app access from nearby.
All right, so fingers crossed,
can we switch back to the app?
OK cool.
Will this work?
Control-R. Please deploy.
I think my phones disconnected.
OK so this is a dialogue
that we're talking about.
Can we adjust the
white balance again,
so that we can see the message?
OK, so this is what happened
when the dialogue first
comes in, so that's why the
handle error is important.
And if I now click Allow
then we say subscribing.
Hello, Ubiquity which is the
attachment that we had before.
So I'm going to go
really test my luck here,
and actually switch
the beacon off.
So this is now off.
So hopefully the on
loss will kick in
within the next minute or so.
I've tried it several times.
It kind of varies a little bit,
and basically will remove it.
Yay!
OK, this is the reverse
how we're working.
Excellent.
So you can see I could do this
with my shaky hands onstage
using Nearby, so hopefully
you can check it out as well.
And let's switch back to
the laptop, thank you.
So that concludes
the demo portion.
But instead of going back to
the slides, I thought hey,
I would just do it in code.
So we have just run through
the three components
of the Eddystone beacon,
which are the hardware and all
the wonderful frame
formats that you
can put on those little guys.
The next is the
Proximity Beacon API
where I can add attachments,
add coordinates to my beacons
and give it more contacts.
And then last and final
is kind of my shaky coding
around Nearby API, so that's
when it gets really interesting
when you put the beacon
functionality into millions
of users, potentially.
So that's the overview.
In terms of some of
the other things that
is happening at Ubiquity, so as
I mentioned in my talk before,
Scott Jenson, who's the
lead on Physical Web,
is going to be here.
So he's going to
talk to you in more
details about the Physical
Web, and also ask him anything.
And if that's not sufficient for
you, then there is actually a
ask me anything session at 4:30.
And we have the product managers
from both the Proximity Beacon
API as well as the
Physical Web around,
so you can ask them anything
about the Google Beacon
Platform.
In terms of
documentation I put it up
top because I know
that you probably
won't read it a
lot of the times,
but when you get
into trouble, yes,
please do have a look at them.
And in terms of the code that
I've shown, unfortunately
this is cut off a little bit.
So with the Eddystone
format, what we have done
is we have actually bundled
in a bunch of tools.
And the thing that was
running on my [? Lexus ?] 6
is this helpful to turn
your phone into a beacon.
The health warning here
is that please, please,
do not turn your users' phones
into beacons, even though you
could, unless you have
very good reasons.
And also you need to
be very good citizens
and tell your users
that you're doing it.
So this is mainly to
benefit developers
in terms of putting
this [INAUDIBLE].
The next is the
Proximity Beacon API,
so the app that you have
seen that was running, adding
attachments, and showing
your map, et cetera,
can be found at this location.
And although I demonstrated,
just the Android version,
we also have an iOS version
that you can download and use
as well.
Last but not least, I am online
and I'm relatively social,
so please ping me on Google+
or Twitter if you have any
thoughts or questions.
So how much time do
we have, by the way?
MALE SPEAKER: 15 minutes.
HOI LAM: 15 minutes.
OK.
I'll take some questions.
I would encourage you to
focus mainly on the things
that I've demoed, and
then what we can do
is we can have a broader
platform Q&A at 4:30
with the two product managers.
Shall we start now?
AUDIENCE: I was
wondering, is there any
way to authenticate or know
that there is a trust issue?
[INAUDIBLE] what if someone
checked on my [INAUDIBLE]
by having an
untrusted [INAUDIBLE].
And then they send a [INAUDIBLE]
which is [INAUDIBLE].
HOI LAM: OK, so the
question over there
is, how do you ensure the
security of your beacon,
how do you prevent other people
from essentially changing
some of the attachments?
Let's say you're in a
museum and then you put in,
this piece of work is great and
someone say, well actually it's
kind of the least preferable
kind of work from that artist.
And you really don't want that.
So with Proximity
Beacon API and Nearby,
that issue would not exist.
The reason for that is with
the Google Developer API key
that you get, the
beacon will only,
and those attachments will only
become available to your app,
and only you can change
those attachments.
And if you wind the
clock back a little bit,
when I was demonstrating the
registration application where
there was a lot of question
marks in terms of provisioning
beacons, et cetera, or
registering beacons at the top
you can just about
see my email address.
So the people that updating
the attachments actually
need to be signed-in users.
So that's an additional
level of security.
Not just anyone who
get hold of your app,
when you are deploying,
but they actually
need to be signed
in users as well.
AUDIENCE: So that's all
transparent to the end
user in terms of [INAUDIBLE]
ID we want to use and stuff
like that.
Or can say someone will come
up with an app to figure out
[INAUDIBLE].
HOI LAM: So that
sort of question
there is whether
the attacker can
figure out your
unique identifier
and perform some kind of attack.
So the only attack
that they can do
is to mimic a beacon elsewhere.
They can't change the
attachment that you
put against your own app,
because they would then
need the sign-in keys
of your application.
But, for example,
they could detect
what the unique
identifier of your beacon
is and using a [? Lexus ?]
6, maybe, type in exactly
the same ID and place
it somewhere else.
So that is something that
they can potentially do.
AUDIENCE: Are the beacon's
URL and attachment
a single broadcast packet?
HOI LAM: Yes, so Eddystone
URL or Physical Web
is essentially
broadcasting a encoded URL.
And that will be used directly.
AUDIENCE: Is there a way to ask
the application developers that
to authenticate
this beacon ID must
be in this geolocation
coordinates?
Because someone could
just pull that beacon
and put it somewhere else and
do some malicious stuff with it.
HOI LAM: The thing
that we would suggest
there is, if your use case is
very security-conscious then
perhaps it's not a
good solution for that
because people could mimic it.
But at the same time, we do have
multiple layers of protection
in the Physical Web.
So we have things like
spam filters, et cetera.
And I would say Scott Jenson
is going to talk about it,
and also he's a
much better person
to explain the various
layers of protection
that a user is going to have.
AUDIENCE: So right
now we can only
register Bluetooth beacons?
Will it be possible to
register an NFC UUID
and have that trigger?
HOI LAM: OK so the question
there is, at the moment
if you look at all the
APIs, they could potentially
use with other
technologies not just
Bluetooth [INAUDIBLE] beacons.
And the specific question
there is whether you
can use NFC, us being a beacon.
So at the moment that
functionality is not supported,
but that's a great suggestion.
AUDIENCE: Does Google do
anything with the information
that it gets through
the API itself?
I mean, do they use it for
Now cards that sort of thing?
HOI LAM: So the question is
what the various Google projects
and use beacons and
enhanced experience.
So it is correct that we have
some Google Now cards that
are built against beacon.
So we have a well-publicized
trial in Portland
whereby we stream live
public transport information
to the various
stations and bus stops.
So that's one example
of how beacons
could enhance user experience.
Yes?
AUDIENCE: I've used the
[INAUDIBLE] beacons using
their [INAUDIBLE]
beacons API, and I
have to use their cloud
service to manage my apps.
[INAUDIBLE] the
beacons in my apps.
I know that [INAUDIBLE] is
one of your OEM partners,
but I don't think they
currently support Eddystone yet.
In the future, maybe--
any time frame on that?
There are still [INAUDIBLE].
HOI LAM: So I can't comment
on particular manufacturer
and their time frame of
deploying more products.
But quite often what we
see is, the manufacturers
might publish an update to the
firmware that runs on a beacon,
and in the firmware update
they add in some support.
So if you do
already have beacons
from one of our
partners, then I strongly
encourage you to
maybe check and see
whether they support a
firmware update for Eddystone.
Cool-- I think it's a wrap.
Excellent, so there's
two more sessions.
One on Physical Web,
and also the beacon
AMA, so I do strongly encourage
you to come back and attend
those sessions.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]
