SMALL INTRODUCTION TO BLE TECHNOLOGY
An iBeacon is a small device working on a battery (not necessarily, but usually) which you can place somewhere and it notifies an app when your smartphone is in range.
The Core Bluetooth framework provided by Apple is an abstraction of the Bluetooth 4.0 specification and provides a set of protocols for communicating with Bluetooth Low Energy (BLE) devices. Such devices include iBeacons, heart rate monitors, modern household goods and many more. The main advantage of BLE is much lesser energy consumption than the regular Bluetooth.
Knowing that I was really exited when I heard about iBeacons for the first time. They give you so much field to show off. This small devices are working on a battery (not necessarily, but usually). They can be placed anywhere and notify your app when in range. Another phone can also work as an iBeacon.
I was so excited to read about this technology and wanted to use it in real life scenario immediately. Fortunatelly, the possibility came to me really quickly.
PROJECT PLANNING
The iBeacon project I participated in was an app for a museum. The main goal was to show additional content, recorded by a very famous historian who came to Poland from Australia to work on this project with us. The application was also ment to be a virtual guide, showing users’ location, their next steps in the museum tour, and talking about the exhibits user was admiring at the moment. Realtime. Underground. It was so awesome!
Having all this in mind, we’ve started designing the app. The guide was designed to tell users where they should go after seeing the current place, with continuous movie playing in a background and a map indicating their location. The first version of the app showed only the distance between Beacons placed on walls. Later, using only 3 Beacons placed inside a room, I was able to determine user’s location really accurately, using triangulation.
We have made many different flows of the app. Exploring many modern controls, interactions from Google apps, Facebook Paper, Apple. A lot of research. Our UI was rather simple but with smooth animations. Not too many things disturbing user’s attention. We had a couple of sessions where we were recording content for the app, drawing screens, changing current flow once again etc. For sophisticated animations we’ve used Facebook’s animation engine- pop combined with Core Animation.
EXECUTION
During the development process, I’ve decided to use 3rd party iBeacons with their SDK built on top of Core Bluetooth framework. They had set of delegate methods called when user came inside a region of particular Beacon. The whole integration took me like 2 days. then, I’ve spent a couple of days placing Beacons.
After that, the app was detecting many Beacons at a time, but still was able to distinguish which one is the closest one. Each Beacon had a range property and a refresh ratio. I’ve set the range at 75% of maximum, and the refresh ratio at 50%. I knew that the battery time of Beacons, according to manufacturer, was from 7 months to 1.5 year, so it seemed reasonably. Devices were distinguished by their major and minor IDs. So, each room had the same major ID Beacons but different minor numbers. I wrote a separate app to set minor numbers of beacon.
At this point, I had the first consideration. If I could do that, everyone can do the same – write an app which will change an ID of a detected device and broke my app. I’ve checked documentation. Found nothing about security from API side. There was a note about introducing cloud registration, but they were planning to introduce this in the near future. Well, I’ve decided to think about this later.
After 3 months, the app was ready. I’ve planned to dry run it on Saturday, when museum was closed. Everything was working like a charm. Almost. I was standing under the plane and expecting informations about Allies, but received info from the Beacons placed a floor below. OK, so the range was to big. I’ve adjusted the Beacons from underground and put them lower on the walls. It solved problem. Some small adjustments and we’ve invited a couple of friends to test this during a tour (we were developing simultaneously an Android app). I’ve noticed that sometimes a Beacon reacted with a small delay, didn’t find a cause but it was acceptable.
OVERCOMING PROBLEMS
On Wednesday, first visitors received devices with the app and started exploring museum. It was a disaster. Things from the weekend didn’t work. At all. User standing 1 meter from a Beacon didn’t see it. Or the app was thinking that he is very far from it.
At this point we’ve realized what is the major issue with using Bluetooth signal – it doesn’t pass through water. And 60-70% of adult human body is water.
So, a user standing 1 meter from device have seen 1 meter on his app. But when someone was standing between them, it changed to 10 meters. It was a serious issue for us. The museum had hundreds of tourists everyday. How could we get rid of so much water near Beacons?
Fortunately, I’ve come up with a solution quite fast. I’ve placed more Beacons in each room, decreasing their signal strength. I’ve also put them higher, increasing the angle between user-beacon and the floor. Much less water on this distance. Of course, it change our math coded inside the app, but one night in the museum and things were working with the new configuration. Those changes made significant difference in a way application was working. After 1 week of tests and adjustments, we were sure that we made a good job. Meanwhile SDK has been enhanced by new feature – configuring beacon with registering it on a cloud. Perfect timing. Now, our app was bulletproof.
CONCLUSION
It was a really good lesson for me. Don’t get too excited about technology. Check all disadvantages, possible issues of technology before using it in production. Do better planning. Never ignore issues found during testing – even if they seem to be insignificant. They will come back to you and bite.
