Starting Android iBeacon App Development

Here are some pointers how to go about Android beacon development:

  • The Android documentation is excellent.
  • Read the posts tagged Android on this blog.
  • Avoid the libraries produced by the beacon manufacturers. They tend to add little value, are usually poorly documented and aren’t changed when there are updates to underlying Android libraries. You can achieve everything with the Android APIs. The only exception is connecting via GATT to Sensoro beacons where the Service/Characteristic information isn’t publicly available and hence you have to use their SDK.
  • The TI SensorTag library has some great examples of how to connect via GATT.
  • Nordic Semiconductor, the manufacturer of the System on a Chip (SoC) in most beacons, has useful libraries for scanning and connecting via GATT.
  • Take a look at the Bluetooth LE Wiki for links to more resources.

If you need more help we provide beacon app development services.

Should I Use the Manufacturer iBeacon SDKs?

Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android.

Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer mobile platform APIs. They also tend to be thin abstractions over the Android and iOS Bluetooth APIs.

If you rely on a beacon manufacturer that doesn’t update their SDK, it’s eventually the case that the underlying Android and/or iOS API changes such that your solution becomes non-optimal and, in the worse case, breaks.

Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. In this way you don’t end up depending on intermediate code and this has the benefit that you can more easily change beacon providers.

Alternatively, use an independent 3rd party library such as Radius Network’s iOS SDK or one of the many Android Bluetooth libraries.

However, there are some cases where you must use the manufacturer library. This is usually in cases where there the app needs to connect with the beacon (as opposed to only view advertising scans) to perform beacon specific things. The Sensoro SDK is an example where their private protocol (to prevent squatters) and sensor information can only be obtained via their SDK.

Which Beacons are the Most Compatible?

We get asked a lot which beacons are the most compatible. All beacons, whether iBeacon or Eddystone, are compatible with iOS and Android. There are a few ‘tracker’ type Bluetooth devices around that don’t transmit the right Bluetooth header and can’t be seen on iOS but we don’t sell those.

Almost all beacons are slight derivations of a few standard circuit designs and firmware provided by Texas Instruments, Dialog and Nordic who produce the System On a Chip (SoC) inside beacons. Hence, they all transmit to Bluetooth standards.

Use of standard SoC Chip and firmware libraries ensures Bluetooth compatibility

The main area that can differ is the Antenna and PCB layout that can lead to different radiation patterns. The ability to detect a beacon isn’t affected and differences manifest themselves as differing beacon signal strength (hence range) and stability.

The main areas where beacons differ is not in compatibility but in physical characteristics such as battery size and waterproofing that are to be found as categories at the left hand side of our store.

One thing people don’t realise is that problems occur with phone compatibility rather than beacon compatibility. Over time, we have discovered about 5% of our customers have problems getting the Manufacturer’s configuration to app connect to beacons on Android. To be clear, this is only when apps need to connect (to change settings) as opposed to only scan for beacons so this doesn’t tend to be a problem (for end users) once everything is set up.

To answer the question, Bluetooth standards are such that all beacons can be seen on all phones and compatibility isn’t an issue. Problems we have seen have been related to phones rather than beacons. We have never had a beacon returned to us because it’s incompatible.

Mobile Forms for Eddystone and iBeacons

We recently came across TracerPlus, a system that allows you to scan and collect Eddystone and iBeacon data into forms on iOS and Android.

A desktop application builder is used to design the forms:

The system can be used to efficiently take inventory and capture additional data from beacons for example, unique identifiers for items, battery life, temperature and URL information.

TracerPlus provides semi-custom mobile applications at a fraction of the cost of custom software.

Reactive Bluetooth Programming

Connecting programatically to a Bluetooth device involves the following stages:

  1. Scanning for peripherals’ advertising
  2. Connecting to the peripheral via GATT
  3. Discovering the peripheral’s services
  4. Discovering the peripheral’s characteristics
  5. Reading and writing to a characteristic’s value and/or monitoring characteristic value change via a Notify

Each of these stages is asynchronous because each takes a relatively long time in computing terms. This means the code needs to call something but continue running to remain responsive to other events and later process the result of a stage via a callback from the Bluetooth library. The connection isn’t reliable because it’s wireless. Different kinds of failure, also notified via callbacks, require the code to go back one or more stages depending on the severity of the error.

All this gets very messy, confusing and difficult to understand in the resultant code. Reactive (Rx) programming attempts to solve such asynchronous complexity problems by using the Observable Pattern to broadcast and subscribe to values and other events from an Observable stream.

There are Reactive implementations such as RxSwift on iOS and RxJava on Android. There are also Bluetooth specific libraries such as RxBluetoothKit for iOS/OSX and RxAndroidBle that make asynchronous Bluetooth code in Swift/Java much easier to understand and maintain.

Reactive programming used to be very popular not just for asynchronous programming but also for general Android programming. It has fallen out use for general programming mainly due to Kotlin which is now the ‘latest thing’.

Naive developers have a tendency to want to use the ‘latest thing’ or ‘clever techniques’ while experienced developers choose the right tool for the job. A common error is to over-use and combine design patterns, such as observables, in simple scenarios, which hinders rather than simplifies understanding.

The nature and relative complexity of your project should determine whether it’s worth using Reactive code. It’s not necessary an ‘all or nothing’ decision. It’s possible to choose to use observable pattern techniques only in parts of code with extreme asynchronous complexity rather than in all the code.

Cordova Bluetooth LE Plugin Updated

Cordova, previously called PhoneGap, is a mobile cross platform development tool that uses web pages and Javascript.

Don Coleman of Chariot Solutions maintains the open source cordova-plugin-ble-central custom plugin (blue area in above diagram) that provides a Bluetooth API for scanning, connecting to service characteristics, reading and writing values and characteristic change notification. Examples are provided.

The recent updates provide support for new permissions and API changes in Android 10+. It’s great to see the plugin updated because the problem with many tools and libraries is that they rarely keep up to date with changes in the underlying iOS and Android APIs.

Which Beacons are Compatible with iOS and Android?

We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether iBeacon, Eddystone or sensor beacons can be used with iOS and Android. The compatibility is achieved through the implementation of common Bluetooth standards on these mobile platforms.

However, there are some caveats:

  • Android only supported Bluetooth LE as of Android 4.3. Older devices can’t see Bluetooth beacons. Over 95% of users are on Android 4.3 or later so most people can see beacons.
  • Apple iOS doesn’t have background OS support for Eddystone triggering. While iOS apps can scan for, see and act on Eddystone beacons, the iOS operating system won’t create a notification to start up your app when there’s an Eddystone beacon in the vicinity.

Rather than beacons being compatible with iOS/Android, we find that there are more problems with particular Android devices not seeing beacons, when in background, due to some manufacturers killing background services.

Also see Which Beacon’s Are the Most Compatible?

View iBeacons

Advanced Bluetooth on Android

Martin Woolley of the Bluetooth SIG was a recent speaker at Droidcon EMEA where he spoke about Advanced Bluetooth for Android Developers (slides).

Android Bluetooth LE Stack

Martin covered scanning, GATT, how to maximise data rates, speed vs reliability and using different PHY for enhanced range or data rates. The second part of the talk covers Bluetooth Mesh and proxy nodes.

One thing not mentioned in the slides, to be careful of, is that connection via a proxy node is relatively slow because it’s limited by the GATT connection. Proxy nodes are good for controlling (sending small amounts of data into) a Bluetooth Mesh but poor if you want to use the connected Android device as a gateway for all outgoing data.

Martin also has a blog where you can also learn about his past talks and he will be part of the new Bluetooth Developer Meetup.

Read about Beacons and the Bluetooth Mesh