Time flies: iBeacon will soon turn two, and shortly thereafter it’ll also be the Estimote SDK’s second anniversary! And what an intense time it’s been for our SDK. We started with a thin wrapper on top of Core Location and then added beacon configuration, Estimote Cloud, Secure UUID, analytics, stickers support, Trigger engine, and infrastructure sharing … and we’re just getting started! We’ve got lots of cool and useful features in the pipeline, all designed to move beacon technology forward, making it more powerful and accessible to developers — but we also recognize that all of this comes at the expense of increasing the complexity of the tools we’re providing.
Designing a clear, intuitive API for an increasingly complex SDK is a great challenge, but it’s one we’re excited to tackle. That’s why we have taken all the lessons we have learned so far, combined them with the amazing feedback we have heard from our ever-growing community of developers, and devised a revamped API that’s not only easier to use and understand but also a solid foundation for all the upcoming extensions on our roadmap. We’ve spent hours at the whiteboard, consumed dozens of our favorite vegan energy bars, shuffled things around, renamed a few others, brainstormed and brainstormed some more, and … here it is: Estimote iOS SDK 3.0.
What’s changed, why, and what’s in it for you? Read on to find out!
Did somebody say “separation of concerns”?
When building a beacon-enabled app, there are always two distinct areas that require your engineering attention.
First comes your application’s “beacon logic.” How do you want the app to interact with beacons? A simple geofence? Differentiation based on proximity zones? Do you need it to work in the foreground or in the background? What other business logic comes to play, e.g., new versus returning customers, current special offers, the weather outside?
Naturally, all of that isn’t of much use without beacons themselves — configured properly at that. Which is where the second point kicks in: beacon management. We’ve made it much easier with the introduction of Fleet Management, but sometimes it still makes sense to build your own tools. Maybe you need the beacons automatically registered in your own backend. Or you want to dynamically (and completely programmatically) figure out the optimal settings for a beacon, e.g., based on the size of the room the beacon goes into. Or you’re distributing the beacons to your own customers and want your app to handle the configuration for them.
The two areas play an equally important role in building a successful beacon-powered app, yet they rarely intersect on the code level. An automated beacon-configurator feature that you’re building as part of your app most probably won’t use geofencing. And vice-versa, the geofence that makes notifications spring up rarely (never?) needs to connect to the beacon and update its configuration. Yet to date, we had a single ESTBeacon class that tried to be in the middle of all of this action.
ESTBeaconConnection springs to life
We moved out all the management and connection-related methods and properties into ESTBeaconConnection and ESTBeaconConnectionDelegate classes. Connecting to a beacon is still an asynchronous process, so the flow remains similar: start the connection process, wait until the beaconConnectionDidSucceed gets called (remember to implement a beaconConnection:didFailWithError: too), and … voilà! You can now read the connection-only properties of a beacon, and start writing new settings.
But wait, that’s not all.
ESTBeacon is no more (and neither is ESTBeaconRegion)
So check this out. With most of the properties and configuration methods specific to Estimote Beacons now living in the ESTBeaconConnection, we decided it only makes sense for the beacon managers to start returning plain CLBeacon classes when ranging beacons. This should make migrating from Core Location to the Estimote SDK (to benefit from things like Fleet Management, Secure UUID, Analytics or Infrastructure Sharing) much easier. If you have any methods or 3rd party libraries that operate on CLBeacon objects, they’ll continue working just fine after the migration.
And while we’re at it… We replaced ESTBeaconRegion with CLBeaconRegion too! Unlike the ESTBeacon, ESTBeaconRegion was always directly inherited from its Core Location counterpart, adding very little on top of it. Reverting to a plain CLBeaconRegion means even more interoperability with the existing, Core Location-dependent code and libraries.
There were however two things ESTBeaconRegion had that CLBeaconRegion doesn’t.
First: the inMotion flag, which you could use to narrow down the region to beacons in motion only, thanks to the Estimote Motion UUID feature. Since the whole idea really is about broadcasting a different UUID when the beacon is in motion, we now enable you to access it directly with the motionProximityUUIDForProximityUUID: class method of the ESTBeaconManager.
And then, there was the “secured” parameter in the initializers, used when you wanted to range and monitor for Secure UUID beacon regions instead of regular ones. Which brings us to…
One manager, two managers, new managers!
After we dealt with the complexity of ESTBeacon, it left us with the ESTBeaconManager that took the now-vacated throne of the “one class to do it all” kingdom. It’s a wrapper on top of the Core Location’s CLLocationManager, adding a bunch of supplementary features (like avoidUnknownStateBeacons), it fetches beacon data from the Cloud, it also does Core Bluetooth beacon discovery, and on top of that handles the complexities of scanning for Secure UUID beacon.
No, it doesn’t make coffee (sadly).
Well, we now have dedicated managers to do all that. ESTBeaconManager remains a variation on the CLLocationManager, supercharged with the same extra features the old one used to have. Secure UUID beacons? Pass the same CLBeaconRegion to the ESTSecureBeaconManager instead, and receive your callbacks in the same ESTBeaconManagerDelegate.
Core Bluetooth-based discovery lives on in the ESTUtilityManager, and returns ESTBluetoothBeacon objects through the ESTUtilityManagerDelegate.
Fetching beacon data from the Cloud is now a responsibility of the ESTCloudManager, for both beacons and nearables.
And of course, we still have the ESTNearableManager and the ESTTriggerManager.
Last but not least: if you’ve seen our Estimote WatchKit SDK, you already know we’ve introduced special “simulator” manager to let you test your nearables apps in the iOS simulator — i.e., if you’re preparing for the imminent release of the Apple Watch. Meet ESTSimulatedNearableManager, reporting back to your regular ESTNearableManagerDelegate, only with simulated beacon and nearables events. ESTSimulatedBeaconManager will be joining the club soon!
We’re also thinking about adding a high level wrapper on top of three of the new managers: the ESTBeaconManager, the ESTSecureBeaconManager and ESTSimulatedBeaconManager — a wrapper that’ll automatically re-route your ranging and monitoring requests to the proper manager, based on whether you’re running in a simulator and whether your beacons have Secure UUID enabled. Would you like to see something like this? Let us know!
Firmware 3.0
Today we’re not only releasing SDK 3.0, but also beacon firmware 3.0, which brings a new feature we call “conditional broadcasting” to Estimote Beacons. Conditional broadcasting consists of two new modes of operation that you can enable on your beacons:
- Flip to Sleep: turn the beacon upside down (i.e., with the adhesive layer facing toward the ceiling) and it will stop broadcasting. This is a really useful feature to turn the beacon “off” and simulate enter / exit region events in your app. It’s also quite helpful when working with large number of beacons in a single space.
“Flip to Sleep” is also coming to the Estimote iOS app in the next update.
- Motion only: with this mode enabled, the beacon will only advertise when it is in motion. This greatly saves battery life for those use cases that can take advantage of it! Not to be confused with Motion UUID feature, which makes the beacon advertise a different UUID when in motion — but will still advertise its regular UUID when stationary, so no battery savings there.
Notably, firmware 3.0 also brings some changes to the beacon authorization procedure, making this update backward incompatible (hence the major version bump). This means you’ll only be able to connect to and change settings of “3.0 beacons” using Estimote iOS SDK 3.0 and Estimote iOS app 2.12 (pending App Store approval now, will be available very soon). Older SDKs and apps, as well the the Android SDK and Estimote Android app will still be able to detect beacons, but won’t be able to change their settings.
That’s all, folks!
We’ve updated all of our examples and API documentation to reflect all the changes, so if you’re still not sure how to update your beacons’ firmware in the SDK 3.0 era, or how to use Motion UUID now, head over there. You can (should!) also take a look at the handy SDK 2.0 → 3.0 migration guide we’ve prepared to make the transition as smooth as possible.
We’ll be focusing all our development efforts on the SDK 3.0 from now on, with SDK 2.0 still receiving critical bug and security fixes for some time. We’ll naturally give you ample heads-up before we decide to stop supporting it at all, but we recommend upgrading to the new tools as soon as possible. Because why wait, if you can have all the cool new features right now?
That’s it for the SDK 3.0 announcement! Love it, hate it? Let us know on Twitter, our still-fresh-from-the-oven, brand-new Community Forums, or simply drop us an email at contact@estimote.com.
Piotr Krawiec, Technology Evangelist at Estimote
& the Estimote SDK team