Mobile devices are almost all about connectivity. When you take a photo, it’s not unusual, that you want to share it in some way – for example on social media platform. Most of the time, to perform such activities connected with sharing, you need to have a connection with internet. However, sometimes it might be hard to find a WiFi hotspot and LTE or any other similar technology might not be an option.
Of course, it doesn’t mean that there’s no other way to share your data with others. One of the alternatives is to use a short-range connection standards, such as Bluetooth or WiFi Direct.
Probably more popular and wide used of these two is Bluetooth. Android supports this protocol up from API level 5, which means that it covers almost all of the currently used devices with this OS – assuming, that they have proper hardware to maintain such connection. However, implementing Bluetooth related features in the application is rather complicated.
First of all, you need to add „android.permission.BLUETOOTH” to your AndroidManifest. It doesn’t of course mean that you can use Bluetooth yet – you still have to check whether the device on which your application is running is supporting this protocol and whether the adapter is operational. Then you need to scan for available devices and try to establish connection. Android framework allows applications to act as a server or as a client. Typically, if you want to connect in a peer-to-peer mode with other users of your app you’ll use server approach and a client one in case of connecting with remote devices such as headset. Whatever way you pick, you’ll eventually end up with instance of BluetoothSocket, which allows to communicate on low level using Input/OutputStream. It’s worth to take a note, that any data flow is blocking and should take place in dedicated thread.
Despite Bluetooth universality, it uses a lot of battery and it’s rather expensive, so BLE (Bluetooth Low Energy) standard was designed to reduce the power consumption and cost of adapters. This revised protocol is used mainly for exchanging small parts of information in short timespans with other mobile devices or peripherals such as heart rate monitors and beacons. Although BLE isn’t backward compatible, most chips on modern mobile devices with Android supports both of the protocols. The BLE api on Android is available up from 18 api level.
However, there are some problems regarding Bluetooth. On some devices BT chip might interfere with WiFi, which may result in lack of Internet connection in case of scanning for devices or when trying to send any data. There’s also an issue with iOS devices, which typically don’t see BLE devices which don’t conform to iBeacon standard. There are also some problems with software implementation of BLE stack – sometimes there’s a need to restart whole adapter because of adress overflow.
But world definately doesn’t end on Bluetooth. Another, albeit far less common, protocol is WiFi Direct. Basically, it’s designed to use small amounts of battery and to allow sending data at fast rate on theoretical distance up to 200m. On Android this standard is implemented as WiFi P2P framework, available up from api level 14. Usage is very similar to Bluetooth – first you need to declare android.permission.ACCESS_WIFI_STATE, android.permission.CHANGE_WIFI_STATE, android.permission.CHANGE_NETWORK_STATE, android.permission.INTERNET and android.permission.ACCESS_NETWORK_STATE in your AndroidManifest, then you must check availability and operationality of WiFI Direct chip. When everything is prepared, you can register a broadcast receiver with WiFi P2P specific filters to get information about adapter state. Eventually, you can scan for and connect to peers in order to exchange information. As with Bluetooth, all data flow is blocking and goes on low level through Input/OutputStream.
However, the trick with WiFi P2P is that it works practically exclusively on Android devices. Another problem is that WiFi Direct isn’t as popular as Bluetooth and it uses more battery than BLE. With that in mind, it might take some time before it’ll become a common choice for peer to peer communication in the field of mobile devices.
The problems with iOS, and potentially any other OS, are partially addressed by Google Nearby API. It combines Bluetooth, BLE, WiFi Direct and nearly ultrasonic sound emitted from speaker to establish connection. Then mobile application, using unified API, can discover, connect, and transfer data to other devices. The API comes in two flavors – one dedicated to sending messages and other used for data transfer. The main drawback of Google solution is that it needs to connect to external server using internet, which renders it useless in situation when internet connection isn’t available.
As it usually turns out, there are different approaches to the problem of short-range mobile communication, all with their own pros and cons. While BLE seems to be a good choice for peripheral devices, WiFi Direct looks more appealing in the field of sending lots of data over long range.
Get to know more about Bluetooth Low Energy technology in this great case study by one of our Senior iOS Developers.
