 Okay, so before that, how many Star Wars fans are? Okay, not as much as I'd like, but today was actually supposed to be the Star Wars release, and I was hoping that it would be a theme presentation, but then apparently, Dilwale is quite important, so the Star Wars release in India got shifted to 25th, which was not so lucky for me, but that's how I wanted to actually tell you my presentation, but we'll start anyways, and we can watch the video for the talk on 25th. So yeah, I'm here to talk about Beacon's Eddystone and the physical web. For those of you who don't know any of these terms, Beacons are basically small Bluetooth low energy devices. Eddystone is a specific format of those, and physical web is a strategy that Google is adopting, which encompasses not just Eddystone, but some other stuff too. So we are going to talk about these things. I'll come back to the demo later, but basically Eddystone Beacons are based of Bluetooth low energy, right? So Bluetooth low energy is this new kind of Bluetooth, which runs on a small coin cell battery for months, if not yours, right? So it is very nice to have in a place where you want to just install it and forget about it. It just works. But the problem with Bluetooth is that it's offline, right, and we want everything connected. That's why Apple and Google are trying different things to encompass this in their mobile strategy somehow, so that they can still use Bluetooth, but still be connected. The design principles in Bluetooth low energy are different as compared to the old Bluetooth. If you use the old Bluetooth, you understand, you know, it's more TCP IP than anything else. This is not like that. This is tailored so that it runs on batteries. That's the main aim of the design of Bluetooth low energy. So how it all started is GPS has been great, right? So there are so many apps that are possible today because we have GPS on our phones. Most of the famous apps, right? Take Uber, for example, right? There are so many Uber for X apps, which would not work if there was no GPS. So Apple was wondering what we could do after GPS, right? Once we have something which tells us that we are in a particular building, what can we do next? We need something which tells me what chair I'm sitting on, what floor I am on, what room I am in, right? So what Apple did was Apple launched a new kind of format or let's call it a protocol in 2013, if I'm not wrong. And they called it the iBeacon. What did I do? That's not what I'm here for. Okay, well, that loads. Yeah, so Apple launched this new format called iBeacon, which was basically small Bluetooth beacons placed around in a room which transmit two values, a major and a minor, and then you have a database somewhere which keeps a track of what major and minor values are allotted to a particular room at a particular venue. All of this was great and people started different startups. Okay, so that's good. Okay, so people started different startups and started building hardware and apps around iBeacon. And Google took it quite slow. What they decided to do was, they didn't immediately start their own version, right? Yeah, so they didn't immediately start their own version. They waited for two or three years to see what everyone was doing. And then this year, they launched their own format, own format for beacons called Eddystone, right? And what they did was pure genius. Instead of transmitting a major and a minor, which are just random strings, they decided to transmit a URL, right? So imagine this. Each chair in this room has a unique URL, right? So setting here, if I'm the manager for DroidCon this MLR convention center or something like that, and if you guys have even the Chrome beta browser, I can identify which person is sitting on which seat, which is great information to have if you think about it. Think about this in the context of a restaurant, right? So if you're sitting on a table number 15, which you know, waiters and the stewards use to keep a track of what table is which, we don't actually get to that information, right? It's only something that they use. Suddenly we are part of that information, right? When I'm sitting on table number 15, I kind of see that on my app, that I'm on table number 15, and that opens up quite a new range of possibilities. For example, there is this void in between what I eat in a hotel and my virtual presence, like all my Facebook, Google and Twitter accounts, right? There is no matching because there is this vacuum in between. Suddenly because of beacons, I can now correlate those things. So what you do in the physical world, what you exactly do in the physical world becomes something that can be tracked. And that's exactly what Google is doing with the headystone beacons, right? So they launch it this year and they bring internet to Bluetooth low energy, right? Which is strange, right? Because Bluetooth has never been about internet. It's about devices that are around you and those devices are somehow connected to the internet. It's an open standard just like everything, like most of the things that Google does in contrast to Apple, which was a closed standard, which works only with iOS devices, blah, blah, blah. This is an open format and all the source code for the standard apps and everything is on GitHub. So people can just walk up, make their own app, use the same icon that Google is using, et cetera, et cetera, et cetera. And what they did was they introduced something known as UID so that it is backwards compatible with what Apple did, right? So Apple was like major and minor, which are two bytes each and random strings. Okay, we'll have something like that so that all our apps are backwards compatible with what Apple is doing. Plus we'll have something known as the URL, which everyone is so familiar with and it has been around for decades, right? And it's a standard, a URL. You can use a URL to transmit a lot of information about something. Plus it's unique and telemetry. So apart from that, you need diagnostic information. You can't actually be there to collect how many people have used that beacon or stuff like that. So you use the user as a dummy terminal to get diagnostic information about the beacons, right? So the telemetry format can be encoded in UID or URL. So like after every 10 URL packets, I'll send that one telemetry packet which will help me and Google. Know about the beacon, the physical health of the beacon, like what's the battery level, how many people has it interacted with and stuff like that. So what Google next did once it had URLs in the picture, it started introducing APIs because that's what Google does, right? It's a web company. It also does a lot of hardware but at its heart, it's a software company, right? So it needs some way to interact with it. So it started introducing APIs and started building beacon support into existing APIs. So Places API is something that has been around for a while, right? Everyone has used it at one point or time to get what places are nearby, the user and stuff like that. So they added support for beacons in the Places API. Then they added something known as the proximity beacon API which was to deal with these beacons and then they added nearby messages API which is not just based around Bluetooth but it's also based around other stuff, right? Like for example, MDNS. MDNS is something that routers use to broadcast a URL even if you're not exactly connected to the router yet. Plus there are some other APIs that have been around that are adopting the Eddystone format so that, so these are mostly people who make the hardware, right? So for example, SDMote is one. So these are the APIs who also have APIs which help me identify which beacons are mine and which are owned by someone else. Okay, so before that, let's do a small demo. This is not visible enough, is it? Is this fine? Yeah, so what I'm going to do is I have a couple of beacons here and I have an app, it's an open source app that we wrote for this particular event. I'm going to start that up and the app will require the permission of Bluetooth, right? So I'm going to say allow and this is the map for this convention center, right? I'm trying to show the different possibilities. So what I can have is beacons located at different points in the map and whenever a user walks by one of those, he gets a notification, right? For example, let's say I want to talk about the exit plan and the fire safety dress, that this is something which your building standards have to do, right? Like for example, if you walk outside on the left, there's this huge white flex kind of a thing which tells what are the things that one has to do in case there's an emergency. So in that case, I have a beacon here but imagine that it's at the exit door. If I click that, I can have something open up in my app, right? So this will not appear for someone who doesn't need it. So for example, there is an emergency on the first floor and someone on the fourth floor does not need to know that, okay, there is something going on on the first floor that I should be a part of. So for example, a fire safety dress. In that case, only I can have beacons which will show the map for people in a particular region, right? Apart from that, I can have URLs. So for example, I want to broadcast something about an artifact. So let's say it's a museum and it's Mona Lisa, right? And I want to basically give the people more information about what Mona Lisa is. So I have a beacon there and when people are walking past by, they get a notification with a URL. When I click on that URL, it opens a browser or let's say a web view in my app and then I can show more information about that particular place. Apart from that, okay, so we have, I'll probably show the demos later. Okay, so how do you get started with these kind of hardware things because this is quite different from what we usually do, right? We write apps, we check them on our emulators, we check them on hardware. There is no physical debug process. There is no physical test process. There is no physical development process that happens, right? So if you want to get started building apps with beacons, what I suggest is the first step is install the five web app which is an open source app written by Google. It's on GitHub and you can use one Bluetooth low energy enabled device to install the app and you can use another to act as a beacon, right? So basically you have something which is a phone which is broadcasting a URL and a phone which is listening to that URL. The next step that you can do is, you know, you get at least four developer friendly beacons, for example, something like the H2 mode. I'm sending, the four is important because beacons work like GPS, right? So GPS works like there are a couple of satellites. My phone pings those satellites and depending on the response time from three or more satellites, I get information about where I am on planet earth. Similarly, if there are four beacons in this room, I ping, I don't exactly ping, but they ping me and based on the RSSI values, the signal strength, I calculate where I am in the room. So for calculating that, I need three, but four is better, right? And the last step is, let's say you now have tested using these developer beacons. The next step is getting cheaper beacons which you can mass deploy and basically you can incorporate beacons into your existing app or write a new app. So I guess I'm out of time. I actually had a couple of more demos, but I guess I'll just set them up and if you guys are interested, you can just walk by here. I'll be here during the lunch and in the lounge room after that. So do any of you have questions? Okay, just yeah. There is a service called Indoor Atlas which almost works on the same concept. You don't even need this hardware at all. Ultimately, you have to actually map the physical location, okay? So Indoor Atlas as well, you just map it, you place it on the servers and actually whatever you want to achieve, you can do exactly the same without any hardware. Yeah, so I've read a couple of papers about these, but the problem with that is it's not exactly portable. So for example, consider the fact that I have mapped a room with tables in it and I changed the arrangement of the table. I have to remap it, whereas in this case, you know, the beacon moves where the table goes, something on those lines, right? Plus it's not just about mapping, it's about URLs too, right? Connecting it to the web. In this case, what happens? I have to be dependent with some service which has the map and then, I mean, it's a tied down thing, whereas if I have something which is an open protocol, which makes sense, obviously these kind of things make sense where I don't want to install hardware, which might be in a certain number of places, but you know, that's not always very convenient. I mean, there's a lot of maintenance involved in this compared to additional. All right, but over here as well, like you know, let's say you're moving, you assign one beacon to one specific, let's say one table, right? Right. So that's also an additional cost and that even somebody changes the beacon, then what happens? Somebody removes that beacon? Yeah. Yeah, those kind of things are always going to be there. I mean, it's like, my router has been taken away, right? I mean, that's always a problem. It's pretty cool, like, you know. But yeah, you can think on that services as well. So it'll probably be a mixture of both these things? Yeah, that would be awesome. Thank you. Anyone else? Yeah, yeah. Yeah, hi. Just a quick question. So have you seen or heard of any cases where people have started using beacons or Bluetooth LE for in-store assistance on a retail store front when people are moving by a particular SKU or a kiosk, then you send a beacon and get them to a particular action? Particularly retail or any public place? Particularly retail, because that's where the commercial is. Target is a huge chain of shopping malls. They're investing heavily in beacons. Walmart for sure is. Apart from that, you know, there are some museums which also have some gift store sections which are equipped beacons. For example, Guggenheim is one example. Then there's another one in New York, I forget the name, which was in the news last week who have installed beacons in their museum. Yeah, so in your opinion, how different is this experience compared to having a particular app that provides more information about a particular arrangement? Yeah, so in the app, so okay. So that's a very good question, actually. How different is this from an existing app, right? Which does not have beacons. So in this case, you don't have to manually select. You don't have to manually input a lot of fields that I want this particular thing in this particular section or something like that. It will understand where you are. It will understand what you want, for example, let's say, and it will directly guide you there. For example, if you are, yeah, again, the Mona Lisa example, right? I'm standing in front of Mona Lisa. I don't want to search for Mona Lisa. I don't want to take a picture of the QR code. I just want my phone to know that I'm already there. So that's where beacons come in. Right now, there are obviously many methods. You have NFC, you have QR codes, you have a text box, simple text box where you actually type and then you get information. But then this is, yeah. No, is there any way that you can also capture a reaction or an interaction or an engagement when somebody spots a beacon, possibly in the future? Because that would be a... So when I get an, yeah, you can actually do that. So what me and a couple of friends are actually doing, we are using standard sensors because these Bluetooth low-energy devices, they actually have a lot of GPIO pins and stuff like that, right? So for example, a PIR motion sensor, which is also tracking people and a Bluetooth low-energy beacon, which is also transmitting. So I get input as well as output and then the beacon itself can store information and it can also broadcast that information because the processor, the microcontrollers that are actually being used, they are kind of overpowered for just beacons, right? So they are going to be enabled with a lot of different hardware. Great, thank you. Yeah. Is that all? Yeah, I don't think we have time for any more questions. Yeah, I guess it's lunchtime? Yeah. Yeah. Also just a reminder, we have the app demos and flash talks at 3.30. So if you, 3.20, if you guys are interested, please fill in the form at the registration desk. These are, again, five minute talks, ideally no pitches, no product pitches, but if you wanna come and talk about something cool, you've built or as an app, or if you wanna talk about something that was said during the conference that you have a counter-argument to, things like that, you have, we can give you five minutes.