Here at Amsys, we are big fans of iBeacons. iBeacons can enhance your iOS apps to make them location-aware. We have a few blog articles explaining how they work; you can read them here and here.
Google has just announced their alternative to iBeacons, called Eddystone, which while very similar to iBeacons adds a few different capabilities.
Just like iBeacon, Eddystone is a Bluetooth 4.0 communication protocol from Google. While iBeacon is officially only supported on their iOS platform, Eddystone officially supports both Android and iOS. For Android, support is baked into their SDK, for iOS, Google offer an SDK, which you can make use of within your app.
Many Beacon vendors are already offering firmware updates so that their devices support iBeacon or Eddystone. For instance, Estimote has just released a firmware update.
The packet transmitted from an Eddystone devices differs from how iBeacons works. In fact, where an iBeacon device broadcasts a simple, unique identifier made up of a UUID, major and minor number, Eddystone devices support different broadcasts.
Eddystone-UID
The first broadcast type is similar to the identifier broadcasted by iBeacons.
Whereas the iBeacon identifier is composed of three parts: UUID, major number and minor number and is 20 bytes long, Eddystone-UID is 16 bytes long and split into two parts:
- The first is the Namespace, which is 10 bytes long. This is similar in purpose to the iBeacon’s UUID.
- The second is the Instance, which is 6 bytes long. This is similar in purpose to the iBeacon’s major and minor numbers
Eddystone-URL
The second broadcast type is something different. Eddystone-URL packet contains a single field to hold a URL to a web resource. Whereas with iBeacon or Eddystone-UID there’s a need for an app to take the beacon’s identifier and translate that into certain actions. With Eddystone-URL, the data is encoded directly in the beacon’s advertising packet. This means that the user can access content—usually in the form of a website — without having the appropriate app installed.
The URL could be a regular web page providing relevant information—e.g., a beacon next to a movie poster could broadcast a link to a YouTube trailer. It also could be a dynamic web application, with contextual parameters embedded in the URL, for instance, to check into a restaurant
The first example of this is with the latest version of Chrome for iOS. Chrome scans for Eddystone devices broadcasting Eddystone-URL packets. If it finds one, then a notification pops up.
A major concern is privacy and user experience.
We all hate spam and secret data collection, and Google has looked at these issues with Eddystone. First of all, titles and descriptions of websites will be fetched from metadata, allowing them to be displayed before a user clicks. Also, information about users won’t be saved until they click a link, so the beacon owner will not know anyone was nearby until they visit the website.
Side note: The name “Eddystone” comes from the Eddystone Lighthouse in the UK. The motif is that beacons guide users and apps in the real world – the same way lighthouses guide ship captains in the night.
So an interesting offering from Google.