My first project with Progress was to write an iOS app that interacted with Gimbal Beacons. Gimbal Beacons are small, battery powered devices that transmit a bluetooth signal to the region around them. One might associate Bluetooth with the clunky phone accessories that required a painful pairing system to operate, but that is an older technology. This new technology, called Bluetooth Low Energy (BLE), relies on a pairingless transmission-reception system that uses far less power and is much simpler to implement. Each beacon sends out a signal with 3 pieces of information: a general ID called the UUID that is used to define a large group of beacons, and two more specific IDs called the major and minor IDs used to distinguish smaller groups of beacons. These signals are received by a BLE-capable device such as a smartphone, which can then provide location-specific information to the user based on their positioning relative to the beacons. The beacons are small and their batteries last a long time due to the simplicity of the information they are transmitting. For this project I used beacons from Gimbal (key for scale):
A common example of a use for this technology is in a department store, where the user would load up the store’s app and receive things like discount offers or product information as they navigated through the different departments. It could also be used at train stations to track the number of zones a passenger crossed and charge them according, eliminating the need to carry an additional card and swipe on/off (thought this one up while struggling to find my Clipper card on the train into work this morning).
For my first project I just wanted to build a dirt-simple app to explore the basic capabilities of iBeacon – iOS interaction to have a base to build on for future projects. I’ll walk you through the app I built and it’s key features. Here is what it looks like upon startup:
Not too exciting. The app is looking for the region defined by our Gimbal Beacons. A region is just a bunch of beacons that have the same UUID. In our department store example, all the San Francisco Macy’s beacons would have one UUID while the San Jose Macy’s beacons would have another The beauty of the app is that it doesn’t need to be running (not even in the background) to detect the beacons. Instead, it utilizes Apple’s Location Services protocol, which constantly checks if the region is nearby. If Location Services detects that the phone has entered the region, the app is then initialized and can notify the user that they have entered the region. If a user turns their phone on in the morning and drives to the store, the app will open up all on its own, greatly increasing the number of times it gets used. In addition, battery consumption is greatly decreased as the app isn’t constantly looking for beacons when it doesn’t need to be.
When the region entry notification pops up, the user can simply tap on it to open the app:
Now we finally have some content. The status bar at the top tells you where the app is in the beacon location process. Here it has already found beacons, so it simply displays the number of visible beacons. If it didn’t see beacons, it would instead say either “ranging” or “monitoring”. This is an important distinction. Monitoring is the process of looking for a beacon region and is handled by Apple’s Location Services. Thus, monitoring works when the app is in the background or not even running at all. Monitoring takes very little battery life. Ranging, by contrast, is the process of actively looking for beacons within a region. Ranging can only occur when the app is in the foreground, and it uses a lot more battery life. Our app passively monitors until it finds the beacon region, then notifies the user to open the app, where it starts actively ranging for beacons. Thus, the app is efficient as possible and doesn’t waste battery life when it doesn’t need to.
Now on to the list below. Each element in the list corresponds to a beacon, showing all three of its identifying features (major, minor, UUID). In addition, it shows the approximate distance of the phone from the beacon. This metric isn’t very accurate as it uses strength of signal to calculate distance. Since signals will degrade at varying rates depending on what material is between the beacon and the phone, the measurement never quite lines up with the actual distance, but it is useful for distinguishing rough proximity to an area.
That’s the gist of the app for now! My next project is to integrate the beacon technology with Node.js and Rollbase to enable the user to interact with location-specific data from a database. In our department store example, we could store different coupons in the database and update them weekly, which would then get pushed to the user as they entered the store. Or the train company could store zone pricing and customer payment information in the database for the app to use to accurately charge the user. Location-based interactions can simplify many experiences between user and other entities, and the beacon technology offers a great improvement in accuracy over the GPS technology currently used in phones. I’m excited to see what uses this technology will be put to in the upcoming months.
Some technical details: This app was written for iOS 7.1 and uses the CoreLocation framework to achieve the background region monitoring.