Hello,
I have been working with the Core Bluetooth framework for a couple of years now and I am quite frustrated that you have not been able to get Sate Preservation and Restoration working well by now. I have tried reporting bugs without any response. So, as a last resort I am posting here in hope that the right people will see it.
It is a major issue in my opinion that State Preservation and Restoration is not working as proposed in the documentation. In the section “Performing Long-Term Actions in the Background” in the Core Bluetooth documentation you give an example use case like this: “imagine you are developing a home security app for an iOS device that communicates with a door lock…”. Later on you say “Now imagine that the user is away from home for a few days. If the app is terminated by the system while the user is away, the app will not be able to reconnect to the lock when the user returns home, and the user may not be able to unlock the door. For apps like these, it is critical to be able to continue using Core Bluetooth to perform long-term actions, such as monitoring active and pending connections.”.
The solution for this is said to be to opt-in for State Preservation and Restoration so that your app can get relaunched by the system if any Bluetooth related events happen to an associated peripheral while the app is terminated.
In theory this is good. It is exactly what you would want. The problem is that it only works if the event originates from the peripheral accessory itself, like a characteristic write notification or a connect/disconnect event. It does however NOT work (as you know) if the iOS device itself changes the connection states of the peripheral, such as when a Bluetooth State Change appears. This effectively means that if you have pending connections set on the CBCentralManager and the Bluetooth switches state while your app is terminated, then your app will NOT be relaunched to take care of the changes. Why is this such a critical flaw? Because, as we all know, a Bluetooth State Change will cancel all pending connections! So in this case all the app’s pending connections will be lost, and the app will NEVER be woken up to know about it. Then when “the user returns home after a few days” the iOS device will not discover the peripheral as proposed.
This thing happens if the user toggles Flight Mode, toggles Bluetooth, power cycles the iOS device, or any other undefined reasons that many cause state changes…
So to sum this up, the use case that is suggested in the Core Bluetooth documentation says that if you are away from home for a longer period of time then State Preservation will be able to relaunch the app once the user returns home. This would ONLY work if a Bluetooth State Change has never appears during this time, which is highly unlikely to be the case, if not impossible. I mean, if you leave home for a longer period of time then you are probably on a trip or something. Most people either turn off their device or put it to Flight Mode at some point when going away for a trip. Some people probably use Flight Mode for other reasons on a daily basis. You can not put the responsibility on the app user to remember to open the app every day to make sure that Bluetooth do not stop working.
Sorry for the negative post, but this HAS to be fixed! Either do it right, or remove it all together, since at this point it is, on its own, rather useless. The solution? Easy! Relaunch the app on state changes as well..
Steps to Reproduce:
1) Opt in to use state preservation and make sure that it works “properly”.
2) Initiate a pending connection to a BLE peripheral that is not within proximity (or not advertising).
3) Put the App to background mode and then simulate the App being terminated by the system.
4) Turn Bluetooth off and then back on again after a while.
5) At this time there will not be a pending connection to the peripheral (even though the app will believe so), so nothing will happen when it is brought into proximity or advertisement starts.
/Anton
