IOS CoreBluetooth: saving and restoring state

Question

Hope some input will be introduced here.

In my current iOS project, I am using CoreBluetooth with fast. The application has the ability to communicate using CoreBluetooth in the background, which basically works, sort of. The peripheral device requires an active connection to the iOS device to work as expected. Whenever a connection breaks, the peripheral device stops its current action. This also happens when the application closes due to memory pressure. In this case, the peripheral device should not stop working, so the problem. To solve this problem, I followed the basic bluetooth programming guide for apples to implement a state save and restore mode, which basically says:

• Initialize CentralManager using the recovery identifier. Delegate = himself.
• Implement the delegate method willRestoreState. NSLog something
• Run checkOptions for the special key. NSLog is something.

I force iOS to close the application when it is in the background using this common project: BackgroundKill . Of course, the application no longer works in debug mode, so I added some NSLog instructions at important points to look for in the device’s console. The good news: the connection is no longer canceled when the application is terminated, iOS now acts as expected to support the connection, so the peripheral device will not stop working. Hit! There is no communication between central and peripheral during this time, with the exception of the battery service to which the application is subscribed. The only reason for an active connection is to prevent the peripheral device from working.

When you restart the application manually, none of the specified NSLogs appears. The willRestoreState delegator is never called, and startOptions is zero. I tried to use the "DISPATCH_QUEUE_CONCURRENT" queue instead of nil when creating an instance of CentralManager. No effect.

How should I use a saved connection when I restart the application? Why did the willRestoreState delegate never call? Am I missing something? Is it mandatory to receive data during the background / forced shutdown of the system in order to use state saving and recovery?

Thanks for the help.:)

Answer 1

Finally I did some tests and got the results. It turns out that the application runs into the background if necessary, which means when the peripheral device sends data to the saved connection. iOS launches the application through didFinishLaunchingWithOptions in this case, so you have ~ 10 seconds to check the launch options and do something. Thus, my problem was related to the fact that there was no data sent over the connection, it seems that now we need to change the firmware of our peripheral device to figure it out.

The willRestoreState delegate is willRestoreState when the application is manually reloaded. Currently, iOS provides not only the recently used central, but also a list of connected peripherals and even recently signed services. Therefore, I just needed to restore my objects and again get a fully signed description from the desired service of the connected peripheral device.