. 

Bluetooth is becoming a popular way to communicate between devices and apps running on smartphones and tablets. Beacons are a specific Bluetooth device type that allows users to communicate with them using apps on their phones where the devices are placed in a fixed location such as within a building, a store, a mall, etc. Titanium enables you to build cross platform native mobile apps using JavaScript. This article is intended to be informative and instructional and leave you with a better understanding of what is possible with Bluetooth & Beacon based mobile apps for iOS and Android using Titanium.

The series currently consists of three blog posts:

• Part 1 – Understanding Bluetooth for Android, iOS, & Titanium
• Part 2 – Building Bluetooth LE & Beacon Mobile Apps In Titanium 
• Part 3 – Building Bluetooth Classic Mobile Apps In Titanium

Often we hear questions or statements about intended BT mobile app project requirements that are based on misunderstandings of Bluetooth. We hope the following will help to clarify some nuances of Bluetooth and how each is supported on iOS & Android, as well what is available for Titanium mobile app developers. There are other resources available online that will go into more depth, here we focus on key technical info for an app developer or project lead that may aid in project planning for a Bluetooth mobile app.

Bluetooth Protocols

Bluetooth is a specification and the version numbers represent the version of the specification, not the type of protocol. “Our application needs to use Bluetooth 4.0” – while commonly used, this statement is not specific enough to clarify which technology is needed. Bluetooth 4.0 is the specification version that includes 3 distinct protocols:

• Classic – the original protocol and the one referred to when people say “Bluetooth 2.x” or “Bluetooth 3.x” even though it is not limited to a single version of the specification. This is the protocol referred in discussions around devices that support BR/EDR (basic rate/enhanced data rate), which is a description of the radio frequency modes.
• Low Energy (LE or BLE) – the protocol often referred to when people say “Bluetooth 4.0” even though its only one of the 3 protocols available in BT 4.0. BT LE, or BLE, is becoming the more common protocol for inter-app communications and is typically what new peripheral devices will use when the data sizes to be sent are small in nature.
• High Speed – No support on iOS or Android is available for this protocol at this time. Although its been rumored that some Android devices have support for high speed, its not part of the Android SDK.

You must know which protocol you need before you can continue with your project. They are not compatible between each other. There are two scenarios you will be developing apps for; App-to-App or App-to-Device (terms invented here for the purpose of this article only).

• App-to-App – apps on a smartphone or tablet that connect to another app on a similar device; one app instance takes the central/client role while the other takes the peripheral/server role. Each platform has its limitations as to what is possible here so your choice of which protocol to use may be driven by these limitations.
• App-to-Device – apps that connect to a purpose-built non-smartphone type device such as a health monitor, beacon or printer as the peripheral. The peripheral device will drive the protocol choice here. Devices can provide both protocols through a dual-mode BT chip, however most devices use only one or the other.

Summary table of protocol options when developing BT apps for Android and iOS

* Although in theory it should be possible to build a BLE Android-to-iOS app where iOS is the peripheral, as of the writing of this article, there is currently a significant bug in Android’s BLE implementation that makes communicating with an iOS device as the peripheral fail.

Examples of app specific considerations and reasons to choose one protocol over the other:

• File or image exchange / printing app: The Classic protocol is more suitable for sending files or otherwise large chunks of data than LE. The max packet size for BLE is 20 bytes so in order to send a lot of data your app needs to be able to rapidly send sequential packets. Although this is theoretically possible, it’s pushing the limits of the design intention of the protocol.
• Apps running in the background: As BLE’s name suggests, low energy translates to lower battery usage than Classic. This is a big advantage when developing apps where you intend to communicate frequently and/or in the background to a peripheral.
• Apps for both iOS & Android: If your intention is to build apps that can have a life on both iOS and Android then BLE is generally your better choice. See the table above for the restrictions that make this clearer.
• Apps intended for the App-to-App scenario: If there is no specific use hardware involved for your app’s purpose and its intended for scenarios such as two smartphones and/or tablets, then BLE is the only choice available for iOS while BT Classic is the only choice for Android, until Android offers the ability for the “peripheral” role in its implementation of BLE.

Bluetooth Profiles

A profile is an attempt to provide a standardized way to specify general behaviors and the way data is exchanged between Bluetooth devices. If implemented properly, a profile offers device manufacturers a well-defined API for app developers. Don’t be surprised to find some devices that claim to follow a published profile when there are obvious or subtle differences that you will have to uncover through trial and error.

There are numerous profiles. Some profiles define other profiles they are dependent on.

ATT (attribute protocol) or GATT (generic attribute profile) refer to the 2 core specifications for all BLE profiles and do not necessarily describe a specific profile. ATT refers to the building block client-server, attribute based type communication and GATT adds the concept of UUID identified services, characteristics and descriptors. All top-level supported BLE profiles are GATT based profiles.

When building apps that communicate with peripheral devices, you will determine which profile to use, if any, from the device’s documentation or by asking the manufacturer.

Beacons         

Beacons are simply BLE devices designed and intended to be in an environment where smartphones or tablets will be that have apps running on them where the apps can detect and communicate with the beacon to derive some location based information. The term iBeacons is Apple’s brand name for beacons and identifies beacons that follow a specific data configuration.

A beacon may be used to identify an area, called a region, and your app can interpret the location of the phone or tablet with respect to that region to mean something useful. You can build proximity-based solutions in terms of the estimated distance from the beacon regardless of regions being defined.

Estimotes are currently a popular new manufacturer of beacons.

The basic BLE communication model for a generic beacon, iBeacon, or Estimote beacon is the same. Additional configuration capabilities are also available through the BLE connection for the Estimote beacons that go above and beyond the basic interactions.

The BT LE modules described later in this article provide examples of connecting to an iOS device as an iBeacon and an Estimote beacon.

 

More Bluetooth Fundamentals

BT Classic Roles: Server & Client

In the BT Classic realm there are two roles identified as the “server” and the “client”. One device will act as one of the roles and the other device will take the opposite role. The server role is intended for the device that has the data needed by the device acting as the client role.  As expected with a client/server relationship, a client initiates communication with a server.

BLE Roles: Peripheral & Central

BLE has the same type of client/server implementation as BT Classic, however the role names are different and slightly unintuitive in their usage if you are already used to BT Classic names. The “peripheral” role is the equivalent to the server in that it is the role that has the data and the “central” role is equivalent to the client in that it is the role that initiates the communication with the peripheral.

The typical sequence of events for BLE roles is server/peripheral advertises, client/central connects, server/peripheral notifies.

 

How BLE & BT Classic roles compare and notes about the way iOS & Android handle them

 

Data Buffers

The fundamental transport data structure between the device and app via Bluetooth (both BT Classic and BLE) is an array of bytes. In Titanium, the Titanium.Buffer object is used to facilitate this. The documentation for the Ti.Buffer indicates it is for strings and integers however in practice the object is an array of bytes so this works out well. 

BLE Services                                                       

One main way BLE differs from BT Classic is that a device advertises specific services before a connection is made. A service is a collection of one or more characteristics that define the data provided by a peripheral. Each service is identified by a unique numeric ID called a UUID. A UUID is essentially a 128-bit number, although standardized services have IDs that can be abbreviated to 16 bits. A full list of standard BLE services can be seen on the Services page of the Bluetooth Developer Portal.

BLE Characteristics

A characteristic represents a single data point that a central can access on a peripheral. Similarly to Services, each Characteristic is identified via a 128-bit UUID. A characteristic may be writable, readable, and/or it may send unsolicited notifications when its value changes.

Titanium Bluetooth Mobile App Development

Bluetooth Mobile App Actions

Although your app may use its own unique handling of the details, the main Bluetooth specific actions taken in your app will be:

• Scan for services on nearby devices (BLE & Classic)
• Connect to services the app wants to connect to (BLE & Classic)
• Register for a characteristic (BLE only)
• Monitor regions (BLE Beacons only)
• Receive input from the device (BLE & Classic)
• Send data to the device (BLE & Classic) 

Titanium Bluetooth Modules

To build an app in Titanium for iOS or Android that uses BT Classic or BLE you will need a module. There are multiple Bluetooth modules available in the Appcelerator Marketplace. Logical Labs currently has the following solutions available:

Protocol	Logical Labs Titanium Module Availability
	Android	iOS
Classic	✔ Bluetooth Android Classic Module	✔ External Accessories Module* Multipeer Module**
Low Energy (LE / BLE) & Beacons	✔ Bluetooth Android LE Module (Includes Support for Beacons)	✔ Bluetooth iOS LE Module (Includes Support for Beacons)
BLE Beacons	✔ Beacons Module*** (Android & iOS)

 

* Classic BT communication capability is available on iOS for accessory-type devices only through the External Accessories Module. It is only useful for devices that are MFI certified.

** The Multipeer Module provides the ability to communicate over BT Classic & WiFi using the same interface

*** On each iOS and Android there is a BLE module (2 separate products) and each of these includes support for beacons. There is also a different product available for purchase, the Beacons Module, which includes both the Android and iOS versions together in the same product and is specifically providing beacon support only. The Beacons Module does not provide access to the non-beacon specific BLE capabilities. The level of beacon support between the BLE module and the module is the same and will be maintained together so if you need to communicate with beacons and you already have the BLE module, you do not need the Beacons Module.

 

Logical Labs’ modules referenced above and used in tutorials are available in the Appcelerator Marketplace:

• Bluetooth Classic Android Module https://marketplace.appcelerator.com/apps/5221
• External Accessories Module (iOS) https://marketplace.appcelerator.com/apps/7759
• Bluetooth LE iOS Module https://marketplace.appcelerator.com/apps/3834
• Bluetooth LE Android Module https://marketplace.appcelerator.com/apps/6611
• Beacons Module (iOS & Android) https://marketplace.appcelerator.com/apps/7619
• Multipeer Module (iOS) https://marketplace.appcelerator.com/apps/8294

Frequently Asked Questions for our Bluetooth Modules are available on a separate page on our site.

 Documentation for our Bluetooth Modules are available on our site and packaged with each module’s zip file from the marketplace.

Series Navigation