Welcome to visit my blog muhlenXi, this article from my blog, welcome to reprint, reprint please indicate the source: muhlenxi.com/2017/05/05/… .

Guide language:

In this section, it mainly focuses on the best practices of interaction with Remote Peripheral and the matters that should be paid attention to in the actual development process.

The CoreBluetooth framework makes the work on the Central side transparent and easy to understand. In other words, your APP controls and is responsible for most aspects of Central, such as searching for devices, making connections, and interacting with Remote Peripheral data. This chapter will provide guidelines and best practices in a responsible manner, especially when developing apps for iOS devices.

Pay attention to Radio usage and power consumption

When developing an APP to interact with BLE devices, keep in mind that BLE communication sends Radio signals into the air through your device. Other forms of wireless communication may also require the use of the device’s Radio, such as Wi-Fi, traditional Bluetooth and other apps using BLE. So reduce the use of Radio.

When developing apps for iOS devices, it is important to use Radio at least a few times, as the use of Radio can adversely affect the battery life of iOS devices. The following specifications will help you use Radio better. In return, your APP will work well and your device’s battery will last longer.

Search peripherals only when needed

When you call scanForPeripheralsWithServices CBCentralManager class: the options: Method to search for Remote Peripheral data being broadcast, your device’s Radio listens on the device being broadcast until you stop searching.

Unless you need to search for more devices, you should stop searching when you find the device you want to connect to. As mentioned in previous articles, stop searching for devices using the stopScan method of the CBCentralManager class.

When necessary to specify the CBCentralManagerScanOptionAllowDuplicatesKey options

Remote Peripheral devices may send multiple broadcast packets per second to the Central monitoring, when you call scanForPeripheralsWithServices: options: Method, the default behavior of this method is to combine one Peripheral discovery event into one discovery event. In other words, Central Manager each would call when she found a new Peripheral centralManager: didDiscoverPeripheral: advertisementData: RSSI: Proxy method that is not called no matter how many broadcast packets are received. This proxy method is also called when the discovered Peripheral broadcast data changes.

If you want to change the default behavior, called scanForPeripheralsWithServices: options: Methods you can specify scan option for CBCentralManagerScanOptionAllowDuplicatesKey, so whenever the Central receive packets from the Peripheral will create a discovery event. Disabling the default behavior can be useful in some situations, such as Proximity based on Peripheral Proximity. Proximity can be judged by the value of the Peripheral received signal strength indicator (RSSI). In other words, specifying the scanning option may adversely affect the power supply endurance and the operation of the APP. Therefore, the scan option of this method is specified only when necessary.

Get Peripheral data wisely

When you develop the APP, a Peripheral device may contain a large number of services and Characteristic for a specific use situation, which is more than what you need. Searching Peripheral all Service and Characteristic will adversely affect the power life and APP performance. So. You should only search your APP for services and Characteristic.

For example, suppose you connect a Peripheral with a number of available services, but your APP only needs to use two of them. All you need to do is search for the two services, passing in the Service UUID array (represented by the CBUUID object) when calling the discoverServices: method of the CBPeripheral class. As follows:

[peripheral discoverServices:@[firstServiceUUID, secondServiceUUID]];
Copy the code

When you search for these two need Service, you can use a similar way to search you need Characteristic, in the same way, in the call CBPeripheral class discoverCharacteristics: forService: The Characteristic UUID object (CBUUID object) that you want.

Subscribe values that change Characteristic

From the previous articles, we know that there are two ways to get a Characteristic value:

  • You can explicitly call the value every time you need itreadValueForCharacteristic:Method to read the values of Characteristic.
  • You can callsetNotifyValue:forCharacteristic:Method to subscribe to the values of the Characteristic so that they will receive notifications from the Peripheral when the values change.

Subscribing is a best practice for Characteristic values that change frequently. Check Subscribing to a Characteristic’s Value.

Disconnect from the device when you have the data you need

Disconnecting from the device when it is no longer needed can help you reduce the use of Radio. You should disconnect from the Peripheral device when:

  • The values of all your subscriptions are no longer notifiedisNotifyingAttribute to determine whether the values of Characteristic are notified.
  • You get all the data from the Peripheral device.

In the scenario above, cancel subscription and disconnected with Peripheral, you can call setNotifyValue: forCharacteristic: way to unsubscribe a Characteristic value, set up the first parameter to NO. You can call CBCentralManager class cancelPeripheralConnection: way to disconnect and Peripheral equipment. Like this:

[myCentralManager cancelPeripheralConnection:peripheral];
Copy the code

Tip: cancelPeripheralConnection: method is from (non-blocking), some CBPeripheral command is still waiting for Peripheral, disconnected when you try to may not be complete. Cancelling a local connection does not guarantee an immediate disconnection of the device’s physical connection, since other apps may still be connecting Peripheral connections. From the point of view of the APP that Peripheral is broken, the Central Manager will call centralManager: didDisconnectPeripheral: error: proxy method for correction.

Reconnect Peripheral

Using the CoreBluetooth framework, you have three ways to reconnect Peripheral:

  • By calling the retrievePeripheralsWithIdentifiers: method to restore a list of known Peripheral – Peripheral is you find or connected in the past. If the Peripheral you’re looking for is in the list, try to connect it. This reconnection is described in the Recovering known Peripheral List section.

  • By calling the retrieveConnectedPeripheralsWithServices: Method to restore the Peripheral list that the system is currently connected to, or if the Peripheral list you are looking for is in the list, create a local connection with it. This reconnection is described in the Recovering a Currently connected Peripheral list section.

  • By calling the scanForPeripheralsWithServices: options: Peripheral scanning and searching, if find it, the connection. This approach is described in iOS BLE Development Notes [2].

So depending on how you’re using it, every time you reperipheral, you might not want to scan and search the same Peripheral, you might want to reperipheral in some other way first. As shown in the figure, a possible reconnection workflow might be to try these approaches in the order mentioned above.

Tip: The number of reconnections you decide to try depends on how your APP is being used. For example, you may decide not to use the first method, or you may use the first and second methods in parallel.

Restores a known Peripheral list

When you first discover a Peripheral, the system creates an identifier (a UUID represented by the NSUUID object) to identify the Peripheral, and you can use NSUserDefaults to hold this identifier. You can try to call after CBCentralManager retrievePeripheralsWithIdentifiers class: Method to restore and reconnect this Peripheral, one of the ways described below is to use this method to reconnect the previous Peripheral.

When the APP starts up, call retrievePeripheralsWithIdentifiers: method, pass in a containing Peripheral identifier of the array to find and reconnection previous Peripheral, like this:

knownPeripherals =
        [myCentralManager retrievePeripheralsWithIdentifiers:savedIdentifiers];
Copy the code

The Central Manager tries to match the identifier you provided on the previously discovered Peripheral, and returns an array containing CBPeripheral objects. If there are no matching Peripheral objects, the array will be empty. You should try one of the other two. If the array is not empty, let the user choose which one to reconnect in the interface.

When the user selects after Peripheral, call CBCentralManager class connectPeripheral: options: method to connect the Peripheral. If after Peripheral devices are connected, the Central Manager will call centralManager: didConnectPeripheral: proxy approach, Peripheral reconnection successful at this time.

Tip: The Peripheral may not connect for a number of reasons. For example, the device is not near the Central. In addition, some BLE devices use periodic random device addresses. Therefore, even if the device is nearby, the address of the device may have changed since the last time the system found a Peripheral, in which case the CBPeripheral object you are trying to connect does not match the actual Peripheral. If you can’t reconnect the Peripheral, because its device address has changed, and you’ll have to call scanForPeripheralsWithServices: options: method to search the connection.

For detailed information on device random addresses, please refer to the Bluetooth 4.0 specification, Volume 3, Part C, Section 10.8 and Bluetooth Accessory Design Guidelines for Apple Products.

Restores the currently connected Peripheral list

Another way to reconnect a Peripheral is to check that the Peripheral you’re connecting is always connected by the system (for example, by another APP), You can call the CBCentralManager retrieveConnectedPeripheralsWithServices class: Method, which returns an array of CBPeripheral objects containing Peripheral objects that the current system has attached.

Because the system may currently connect more than one Peripheral, you can pass in an array of CBUUID objects to restore the Peripheral you specified for the Service. If there is no Peripheral you specified for the connected Peripheral, The array will be empty and you should try one of the other two ways. If the array is not empty, the interface lets the user choose which one to reconnect.

Assuming that the user to select the desired Peripheral, by calling the CBCentralManager class connectPeripheral: options: localization method to connect. Even if the system is always connected to the device, you have to localize the connection and then interact with it. When local connection is established, the Central Manager will call centralManager: didConnectPeripheral: agent method, equipment reconnection successful at this time.

reference

1, Best Practices for Interacting with a Remote Peripheral Device

conclusion

Leave a comment below to share your thoughts…