A look at the issues and trends in deploying beacon-based solutions.
Save 25% on registration for Solid with code SLD25. Solid, O’Reilly’s conference on hardware and the Internet of Things, covers topics like beacons — and everything else you need to know in order to build intelligent, connected devices.
In this post, the third of our series, I’ll look at some of the issues in using and deploying beacon-based solutions, some of the trends in both hardware and software offerings, and share some resources where you can find more detail on everything I’ve covered so far.
First off, let’s take a look at some of the topics that can cause issues, or trip us up when starting to consider a new iBeacon-based solution. In no particular order, these include:
Notifications, Notifications, Notifications
I have many conversations with potential clients that go something like this (in condensed form):
Client: “We want to do a beacon project”
Me: “Great, what are you thinking of?”
Client: “We want to trigger messages to people as they come past or in to our place on their phones”
Me: “OK, is this iOS only?”
Client: “No – of course not – in fact, most of our users are on Android”
Me: “Ah – ok… well…”
(long conversation follows)
With the initial hype and excitement around iBeacon, it’s understandable that there’s some confusion around what’s possible, and what’s not, across all the mobile handsets available today. For now, I’ll focus on just iOS and Android, though we could usefully expand to include Windows and Blackberry. Read more…
How proximity approaches compare and a look at the flourishing proximity startup ecosystem.
Editor’s note: This is the second post in a series looking at beacon technology and the burgeoning beacon ecosystem.
In the first of this series, I covered some of the basics behind proximity, Bluetooth Low Energy, and iBeacon, and walked through some use cases where proximity and iBeacon have started showing up in retail, travel, and other applications.
While iBeacon has arguably galvanised the notion of using proximity in applications and services, it’s not the only game in town.
In this post, I’ll cover one of the alternatives to Apple’s iBeacon, Physical Web from Google, and then I’ll zoom out to look at the flurry of activity in startups in the evolving “Beacosystem.”
First, a small recap on what helped iBeacon gain so much traction, so quickly and helped shape the landscape for a proximity ecosystem to emerge.
Creating an ecosystem
Apple’s iBeacon is a layer, or a “convention,” that builds on the Bluetooth Low Energy (BLE) Standard. Apple has spurred an ecosystem around iBeacon by doing several things, which all feed into each other:
- Baked support for iBeacon into its mobile operating system (iOS) so that APIs are readily available for developers.
- Included support for background notifications at the OS level, so that push notifications can be triggered in certain situations, but without killing your phone’s battery.
- Provided a certification program to enable hardware manufacturers to create iBeacon-compatible hardware. This allows third-party manufacturers to provide iBeacon-compatible hardware of all shapes, sizes, and form factors, At last count, there were more than 50 suppliers of iBeacon hardware.
- Enabled every iOS device to be an iBeacon. This has many potential uses, from iPad-based POS systems welcoming you to a store, to the Hailo App letting you know that you can pay by Hailo.
- Ate its own dog food, by using iBeacon with their Apple Store App in all their US based Apple Stores.