"iBeacon series" entries
iBeacons, privacy, and security
The technology is at risk of dying off — and that would be a shame.
iBeacons and various BLE technologies have the potential to shake up many established ways of doing business by streamlining interactions. Although there are potentially many uses for iBeacons, much of the initial discussion has focused on retail. (I’ll follow up with some examples of iBeacon applications outside retail in a future post.)
As I described in my initial post in this series, all an iBeacon does is send out advertisement packets. iBeacon transmissions let a receiver perform two tasks: uniquely identify what things they are near and estimate the distance to them. With such a simple protocol, iBeacons cannot:
- Receive anything. (Many iBeacon devices will have two-way Bluetooth interfaces so they can receive configurations, but the iBeacon specification does not require reception.)
- Report on clients they have seen. Wi-Fi based proximity systems use transmissions from mobile devices to uniquely identify visitors to a space. If you take a smartphone into an area covered by a Wi-Fi proximity system, you can be uniquely identified. Because an iBeacon is only a transmitter, it does not receive Bluetooth messages from mobile devices to uniquely identify visitors.
Application programming for iBeacons
iBeacons don't communicate directly with end users — applications are required for translation and action execution.
Once you are set up with an iBeacon, no matter whether it is a dedicated device or a program running on a host device, you are ready to start writing applications. The iBeacon “protocol” is simple, as we saw in the introductory post: it defines regions in space as “where I see a specified combination of UUID, major, and minor numbers.” There is no descriptive text or mapping transmitted in the packets sent by a beacon. Translation between the beacon’s transmissions and any actions are done entirely within an application running on the receiving device, even if the application is a simple text message to say “welcome to this place.”
For developing applications on iOS, the core documentation is the developer’s guide to region monitoring. For many years, iOS has enabled applications to use the physical location of a device in applications through the CoreLocation framework, which is what users enable in the Location Services settings in the Privacy panel. iBeacon functions were added to CoreLocation in iOS 7.0. Naturally, devices must have hardware support for the underlying Bluetooth Low Energy functions, which in practice means an iPhone 4S or later iOS device. Macs sold since late 2011 also have the required Bluetooth hardware. Read more…
Horseshoes, hand grenades, and building mobile applications
The difference between location and proximity: knowing you’re in the restaurant vs knowing what table you’re sitting at.
As the old proverb goes, “close only counts in horseshoes and hand grenades.” It doesn’t quite apply when building mobile applications, however. Smaller screens and the resistance to extensive keyboard input define the input and output constraints of mobile apps, but there is something more fundamental that a mobile application can do. At its best, an application that knows where you are will augment reality to help you navigate and interact with the physical world. These applications are sometimes described as “location” applications and sometimes described as “proximity” applications. Many people are guilty of using the words interchangeably — myself included. In response to my post on iBeacon basics, Alasdair Allan called me out on Twitter:
@matthewsgast I’d debate your point that #ibeacon is about location, I really think it’s more about proximity. It’s not the same thing.
— Alasdair Allan (@aallan) March 23, 2014
His comment was spot-on. In this post, I’ll define (and be very precise about) the difference, the importance of which leads directly to the level of interest in proximity — and informs the excitement levels around technologies like iBeacons. Read more…
iBeacon basics
Proximity is the 'Hello World' of mobility.
As any programmer knows, writing the “hello, world” program is the canonical elementary exercise in any new programming language. Getting devices to interact with the world is the foundation of the Internet of Things, and enabling devices to learn about their surroundings is the “hello world” of mobility.
On a recent trip to Washington D.C., I attended the first DC iBeacon Meetup. iBeacons are exciting. Retailers are revolutionizing shopping by applying new indoor proximity technologies and developing the physical world analog of the data that a web-based retailer like Amazon can routinely collect. A few days ago, I tweeted about an analysis of the beacon market, which noted that “[beacons] are poised to transform how retailers, event organizers, transit systems, enterprises, and educational institutions communicate with people indoors” — and could even be used in home automation systems.
I got to see the ground floor of the disruption in action at the meetup in DC, which featured presentations by a few notable local companies, including Radius Networks, the developer of the CES scavenger hunt app for iOS. When I first heard of the app, I almost bought a ticket to Las Vegas to experience the app for myself, so it was something of a cool moment to hear about the technology from the developer of an application that I’d admired from afar.
After the presentations, I had a chance to talk with David Helms of Radius. Helms was drawn to work at Radius for the same reason I was compelled to attend the iBeacon meetup. As he put it, “The first step in extending the mobile computing experience beyond the confines of that slab of glass in your pocket is when it can recognize the world around it and interact with it, and proximity is the ‘Hello’ of the Internet of Things revolution.” Read more…