I am looking to figure out which delegate methods fire reliably when connecting / disconnecting in the background when terminated. Whenever the user gets close enough to my BLE device, I want it to auto connect and then fire a quick method to exchange data with the device.
I cannot seem to get any of the delegate methods to fire reliably with this use case. I have background modes for bluetooth-central turned on, I have the proper delegates in use and the whole BT module I wrote works really well when the app is active or in the task switcher. I just need to finalize with this last use case, the app being terminated.
My original plan was to use iBeacon but this ended up being a flawed approach to wake up the application from terminated because I NEED the bluetooth pairing to remain and persist. The only way to get iBeacon background/terminated events like didEnterRegion or didExitRegion to fire, is to "forget this device" (in the iOS system BT menu) after the app went through the connecting/pairing phases with the user. So this can't work because unless the user does this for me, the app will never be able to un-pair from a device (I even tried an AT+command in the box to wipe auth/bond and disconnect).
So... Now the only plan I have left is to find a way to have the centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral and didDisconnectPeripheral methods fire whenever the iOS system reconnects. So when the device turns on or the user gets close enough to be back in range.
I have finally found the answer! The reliable method is definitely iBeacon... which I thought I couldn't use because I am using a bluetooth paired connection and iBeacon isn't advertised when your device is connected. This is, "sorta" correct in the fact that you cannot detect iBeacon output from a device that is already connected to something else... what I hadn't thought of until recently is building a board with 2 Bluetooth chips in it!
What I did was use one BT chip for a dedicated iBeacon ranger to wake up the app in a more stable and reliable way and the other chip for a dedicated BT connected/paired/auth/bonded state. Now I can use my encrypted custom characteristics in the device as well as having the device wake my app back up once terminated or asleep! :)
Here is an article where I posed a similar question and answered.