问题
I've been playing with Corebluetooth and I've learnt that besides going through the tedious process of scanning for a peripheral every time I want to connect, I can also store the peripheral's UUID and use it with retrievePeripheralsWithIdentifiers and connectPeripheral for further reconnections.
Turns out that it only works for a certain amount of time, apparently the peripheral has its UUID updated, therefore the stored one can be considered expired.
I haven't been able to find any consistent documentation on this, so I'm not sure how long it lasts for.
Is there any way around this in order to allow later reconnections faster than scanning for peripherals all over again?
回答1:
In my opinion, directly holding onto the CBPeripheral objects in an NSArray or NSDictionary is the easiest way. Connect and disconnect as many times as you would like (without scanning each time) to a CBPeripheral once it is retained. The only thing you have to be mindful of is the CBCentralManager's state. You will receive state changes by implementing the CBCentralManagerDelegate centralManagerDidUpdateState: method. If the state changes to anything except CBCentralManagerStatePoweredOn then you need to get rid of all of your retained CBPeripheral objects and do another scan once the state turns back on.
According to the apple docs:
If the state moves below CBCentralManagerStatePoweredOff, all CBPeripheral objects obtained from this central manager become invalid and must be retrieved or discovered again.
However, I would suggest invalidating/releasing all of your CBPeripheral objects if the state moves below CBCentralManagerStatePoweredOn. It is no secret that CoreBluetooth is a little buggy and this has seemed to help me avoid "invalid CBPeripheral" warnings in the past.
If you would like to identify a specific CBPeripheral after the app is reset or the device is shut down or even a network settings reset (cache reset) then you will need to have a custom implementation that uniquely identifies another device not based on anything CoreBluetooth offers you for free.
Here is how I do it in one of my apps:
- Alloc/Init a NSUUID object the first time the app is launched and save it in NSUserDefaults as a NSString. Think of this UUID as a pseudo-MAC address for your app. This UUID will remain constant for the lifetime of the app.
- centralManager discovers a CBPeripheral, connects, and then reads the value for a specific characteristic
- CBPeripheral device responds to the request with its non-bluetooth-related UUID from step 1. I also include a whole bunch of user provided information in this step along with the UUID.
- centralManager saves this UUID (and any other information you include) using Core Data or NSUserDefaults if it hasn't already.
- Repeat steps 2-4 for all newly discovered CBPeripherals.
Now, whenever centralManager discovers a CBPeripheral it can check its local database of UUIDs and determine which device is related to this CBPeripheral without a doubt.
See Paulw11's answer for how reconnect while in the background. Note that if your app has been quit by the user (swipe the app's preview up after pressing the home button twice), any long term "connects" will be cancelled even if the app is restarted.
回答2:
It depends on the type of peripheral and the addressing scheme that it implements.
An iOS device operating as a peripheral using Core Bluetooth will change its address fairly frequently - in a matter of minutes.
For other peripheral devices, such as fitness monitors, HID devices etc, the address will never change (unless the peripheral manufacturer has also decided to introduce address randomisation) and it is "safe" to store the UUID string and attempt to scan and reconnection directly when the appropriate UUID is seen - note that you can't necessarily use the CBPeripheral, but you can store the UUID object from it.
You can also use background modes to automatically re-launch your app and connected to a peripheral. This scenario is described in the "lock" example of the Core Bluetooth programming guide. An app can issue a "connect" to a peripheral and it won't timeout.
In summary, you can't really store UUIDs for iOS based peripherals but for other peripheral types you 'probably' can.
来源：https://stackoverflow.com/questions/25130958/how-long-is-a-cbperipherals-stored-uuid-valid-for-reconnection