If carrying out massive beacon deployments in stadiums like the Quicken Loans arena and events like SXSW has taught us one thing, it would be that change happens. Change can come in a variety of different ways, and it can be brought on by anything – from weather to the amount of people expected in a room. It can subsequently lead to more change, like changing the placement of beacons or the places that will trigger communications or experiences. Change is inevitable.
Being part of an Agile Software Development team, we expect change and for us, it is nothing out of the ordinary. However, when dealing with production applications last minute changes can be the difference between a working application in the hands of millions of users or an application doomed to be uninstalled. One feature we baked into the Gimbal SDK to make it more flexible was centralized configuration for key parts of the application.
What exactly can you configure on the server?
If you only had time to set up one server-side configuration, your biggest ‘bang for the buck’ would be to rely on server-side Customization of Place Detection for Beacons. Having the Customization of Place Detection for beacons on the server side means you can tune the RSSI values that trigger arrival and departure of places on the server. But why is this important?
The reason is that a bulk of the time spent on beacon deployments goes to creating the best possible user experience, and this usually translates to getting the app in question to trigger at the appropriate distances.Fine tuning the distance ranges is important because you want to avoid sending out a “Welcome to Bob’s Clothing Depot” message when someone is actually in the ice cream shop next door.
Often enough instances like this arise in apps that are hard-coded to trigger at specific RSSI values in test scenarios. However, because of how Bluetooth works there are many factors that can change what values will be appropriate when the app launches (e.g. a new display is a set-up in front of the beacons which now affects beacon signal strength).
Setting these values in Gimbal Manager, instead of within the application itself, is important for two reasons. The first is that developers spend less time testing in the physical location of the deployment and when the deploying code, the specific location of the beacon is not as important because it can be tuned again later.
The second reason is that Gimbal Manager lets you turn on and off whole parts of the SDK such as geofencing, beacon monitoring and communication delivery from the server. Which makes it so that if you need to update your application in the app store before you can physically deploy your beacons, you can safely develop everything internally and enable beacon monitoring in the app whenever deployment is done.
Why have Client-side configuration?
After all the talk of avoiding client-side configuration and the push to do it all on the server, why do we allow you to turn on and off features from the SDK? From the beginning, we at Gimbal, have always felt that the SDK should have an opt-in experience to prevent the platform from turning into a contextually aware spambot. With this in mind, if you were to opt-in you should also be able to opt-out. We think this is the perfect place for client- side configuration. Even though the server tells the application to enable geofencing, beacon monitoring, and communications, you can also build user-specific options to disable them from the client.