Exploring Eddystone and the Physical Web
Why we should not get too excited (yet)
For around three years now I’ve disappointed many a sales executive in Accenture with the news that beacon technology on Android is … kind of a mess. It’s not that they cannot be used, but rather that beacon monitoring is not centralized as it is on iOS, so it drains the battery considerably when running in the background. The lack of a standard SDK is also an issue, meaning vendor specific SDKs such as Estimote’s or Gimbal’s must be used instead (and these tend to encourage lock-in to one brand of beacons). Most of these SDKs also follow the format of Apple’s iBeacon protocol, exposing only a UUID and two integers. Finally — beacons are a fast moving space, and SDKs are coming and going at a frustrating pace.
These issues have not gone unnoticed. Samsung developed their ill-fated Placedge SDK to attempt unification, but only succeeded in fracturing the ecosystem further. Android Beacon Library has been the best attempt so far, but it still runs in the context of a single application without a shared system service.
It comes as good news, then, that Google is doing something about it: enter Eddystone.
At first glance it is a lot more exciting than iBeacon, as it is both far more fully featured and much more open (Apple requires iBeacon devices to be certified, which seems a very Apple-y — but also unnecessary — overhead).
Eddystone is a specification agreed upon by Google and several allied beacon manufacturers, Estimote amongst them. It defines three standard protocols for beacon functionality. Eddystone-UID is an iBeacon like format that allows beacons to expose a unique identifier to nearby listeners (any logic to handle and respond to this identifier has to be programmed on the application side). Eddystone-TLM defines a telemetry protocol for retrieving diagnostic information from beacons (doubtless a welcome relief to anyone hoping to manage a large deployment). Eddystone-URL, the most interesting of the three, exposes a URL for any client listeners and is one of the foundations of what Google is calling the Physical Web.
As with my last post on beacons, the opportunity here is contextual interactions without a preinstalled application. Google’s hope is that you will approach any object, be it a shelf in a store or a home automation device in your own home, and using Eddystone-URL the device will direct you to more information or a native application. For retailers the potential could be huge, as they gain the ability to push their mobile application or website on every customer with a Physical Web enabled device as they walk through the door.
The problem, as you might be thinking, is the wave of location based fraud and spam that might be unlocked by unleashing these capabilities. Even legitimate uses of the devices could rapidly become annoying. It is for this reason that the Physical Web is likely to remain opt-in for the near future (for now you need a mobile application, which you can download for iOS or Android).
A brief criticism of the Android ecosystem
If you read my blog, or have met me in person, then you might know that I am not the world’s biggest Android fan and I am in fact sucked into the Apple ecosystem perhaps a little further than is healthy. My reasons are not necessarily what you might expect, though. I dislike Android not (just) as a consumer, but as a developer.
Having previously developed a number of Android applications (at least a couple of which are still kicking around the Play Store), the developer experience is heinously un-smooth. Not only does the tool support push me into Java, one of my least favourite programming languages, but the exciting range of capabilities in the newer Android SDKs is completely worthless for the time being due to version fragmentation (nearly 10% of Android users still use Android 2.3.7 or below). The vain attempts to correct course in the form of appcompat libraries do nothing but frustrate me further as I try to wrangle a mess of dependencies and conflictingly named types into a semi-functional codebase, and appcompat doesn’t fix the absence of key operating system level services.
Due to this version lag the pace of innovation on Android is greatly reduced and it’ll be a while before we see Operating System level beacon support widespread enough to make use of.
What does it all mean?
As with Facebook’s similarly minded (although infinitely less flexible) attempt to open up microlocation, Eddystone and the Physical Web are areas to watch. Early adopters can get started very quickly and begin to build the physical web, but don’t expect a high level of customer interaction at this stage. I wholeheartedly recommend use of the Eddystone protocol for in-app experiences based on the strong vendor support and cross-platform capabilities, but iOS targeted developers should still consider iBeacon for battery intensive background operations such as region monitoring.
In general, for those who don’t have beacons yet, any of the Eddystone vendors seem like solid options. Unfortunately I have found that battery life tends to be wildly overstated, so for larger distributions custom built beacons or a type that can be hardwired into power might be better.
Footnote: For some background, ex-Accenture Technology Labber Marjan Baghaie wrote some notes about her beacon research back in 2014. If you would like to know more, feel free to reach out to me on LinkedIn (where this blog has been crossposted).
