Building Proximity Apps with RAD Studio
Last week I had a pleasure of doing remote online presentation about building proximity-enabled mobile apps with Delphi and RAD Studio for Delphi developers gathered at the Delphi Developer Days 2016 in Poland. Here are some notes, links and demos from this presentation.
Our smartphones are hardly phones anymore. They are in fact powerful, multi-purpose sensor centres that James Bond a few decades ago could have only dreamt about. If you think about it your phone has not only speakers and microphone, but also camera, light source, ambient light sensor, accelerometer, compass, 3D orientation sensors, GPS-location, NFC, Bluetooth and more.
RAD Studio provides type definitions to work with all kinds of sensors through System.Sensors unit. In the installation of RAD Studio there is "SensorInfo" sample application that is using TSensorManager class to get readings from all available sensors on a device where our app is running. This is a very powerful feature of RAD Studio and its cross-platform support, because you can create applications using one source code that are using sensors in all programming languages supported (C++ and Delphi), on all platforms (iOS, Android, OSX and Windows) and on all device types (phone, tablet and desktop).
Building "proximity" apps - more or less - means using sensor information to determine the exact location of a mobile device running a proximity app. If you are outdoor and the accuracy up to few meters is acceptable, then we can use the GPS sensor (if our device has one). The most easy way of using GPS location in RAD Studio is using the TLocationSensor component, which provides properties and events to read current device location as the combination of geographical latitude and longitude. RAD Studio provides "LocationDemo" sample project that shows how to use TLocationSensor component.
In most cases building "proximity" mobile apps means using physical "beacon" devices to be able to determine the location of a phone or tablet with the accuracy of centimeters. Beacons are tiny radio emitters that can be uniquely identified. A few times every second a beacon is broadcasting a few bytes of identification information using the Bluetooth Low Energy protocol. The distance from a mobile device to a beacon is determined based on the strength of the signal coming from a beacon.
There are two, completely different, types of Bluetooth standard. There is Bluetooth "classic" protocol which was originally created as an alternative to traditional serial port cables and there is newer Bluetooth "Low Energy" standard, which is intended to provide considerably reduced power consumption and cost while maintaining a similar communication range.
In order for a mobile app to work with a Bluetooth Low Energy device it needs to know its Generic Attribute Profile known as "GATT" profile. Each GATT profile can contain a number of services and each service can have one or more characteristics. Depending on a use case an application can integrate with different types of Bluetooth Low Energy devices based on their unique GATT profile.
On the Bluetooth developer website there are definitions of different GATT profiles including blood pressure, cycling power, glucose, heart rate and also "proximity" profile that enables proximity monitoring between two devices.
It is possible to use with "TBluetoothLE" component to work with beacons, but RAD Studio provides dedicated "TBeacon" component that is conceptually a specialized version of "TBluetoothLE" component. It has hardcoded GATT "proximity" profile, so it is easier to use.
Currently there are three different standards for beacon identification and all of them are supported by the "TBeacon" component and the underlying types from the System.Beacon unit: iBeacon, altBeacon and Eddystone. The first beacon standard was created by Apple (iBeacon), followed by open standard altBeacon by Radius Networks and the newest is Eddystone created by Google. All three standards are supported by RAD Studio and "TBeacon" component provides "Mode" property to select which specification to use. The RAD Studio 10.1 Berlin added support for Eddystone and also new "Extended" value for the "Mode" property that allows to work with all types of beacons.
Beacons market is still relatively young, so different vendors offer beacons with different capabilities and custom extensions. Some beacons are battery powered, some are powered by USB. Some of them are programmable, some of them have their identification hardcoded. Typically each vendor would provide a custom app for calibrating and configuring their beacons.
When a beacon is in the proximity of a mobile device then the mobile operating system can notify selected applications that expressed interest in being notified about beacons with certain identifiers or identifier ranges. The Eddystone format adds a possibility of broadcasting the whole URL from a beacon, but most other standards are using just "UUID", "Major" and "Minor" numbers to uniquely identify a beacon. "UUID" is a globally unique identifier, often associated with a beacon vendor, and "Major" and "Minor" are just two integer values used for further identification.
TBeacon component has "MonitorizedRegions" property that can be used to register beacons that our application is interested in receiving signals from. Specyfying "-1" for Major and/or Minor values means "all" possible values.
If a known beacon is detected by a device then your device's operating system is sending notifications to applications that are translated into events fired by the TBeacon component. For example you could add code to the "OnBeaconEnter" event to get information about a new beacon (ABeacon: IBeacon), but also the reference to the list of all beacons currently in range (CurrentBeaconList: TBeaconList).
IBeacon interface has has a "GetProximity" function that returns TBeaconProximity enumerated value that can have one of four possible values: "immediate" which is below half a meter, "near" (between 0.5 and 1.5 meters), "far" (up to 1.5 meters) and "near" where we cannot determine the distance.
There are different use cases for using beacons in mobile apps. All of them fit into the broader picture of "Internet of Things" solutions. One of the possibilities is to use beacons as badges and attach them to physical objects we want to be able to identify. You may also want to use the whole system of beacons installed in a known physical locations in order to be able to calculate the exact position of a mobile device running proximity-enabled app using triangulation. Similarly to how sailors have been using maps, stars and beacons to determine the location of a ship on the sea, we can use Bluetooth Low Energy beacons to calculate the position in space of a mobile device.
In the micro-positioning use case the next step is to take the list of currently visible beacons, with their approximate distances and RSSI values, and to build an algorithm to calculate the position of the device. That's not a trivial piece code. Luckily there are "Beacon Fence" components that are available through RAD Studio Get It Package Manager and can be installed directly in the IDE.
Just double-click the "TBeaconMapFencing" component to display convenient beacon fencing editor where you can interactively put beacons on the map and define higher-level zones that will trigger on "OnZoneEnter" and "OnZoneExit" events for your proximity solution.
A mature proximity mobile app would also require a proper backend for user management, data access and more. "Beacon Fence" is available as part of RAD Server, which adds to RAD Studio the possibility of creating modern REST API backends in Delphi or C++ and much more:-)
Please login first in order for you to submit comments