ios ble data lost after being killed in background mode - ios

I have an iPhone app that receive BLE info from a particular device. The device sends data to my app anytime it has something to report, and the transmission rate is about 2K Bytes per second.
The problem is that my app can be killed in the background mode by iOS and I can get no indication about this. If the device start to send ble data after my app is killed, my app can only get the last data packet after it is woken up by the system and lost all the data during the wake up procedure.
How can I get all the BLE data after my app is woken up and restored by the system?
PS: I have added Bluetooth-central under UIBackgroundModes in the Info.plist. In background mode didUpdateValueForCharacteristic: method is being called. Also, a CBCentralManagerOptionRestoreIdentifierKey is specified while I construct the CBCentralManager.

On iOS you can ensure that your app isn't completely killed by the system by using State Preservation and Restoration. Please have a look at the following link for more info:-
Core Bluetooth Background Processing for iOS
However, please note that you cannot use this if you force kill the app. There's more information about this in the following question:-
BLE device keep connect with iPhone when application terminate

Related

Background scanning not working without having last peripheral in iOS?

I trying to connect peripheral using UUID in the background, It's working only when i interact with advertising beacon first time at foreground then my app went background its working background and lock mode also if First time my app is away from advertising beacon i put my app at background then will come near to advertising beacon it's not working. in console, they came last peripheral not found as that error will come, my question is :
is this possible to scan or connect Bluetooth using UUID for the first time without the app opening?
i already tried that solutions also :
iOS BLE device paired while app is in background or killed or suspend
iOS: didDiscoverPeripheral not called in Background mode
didDiscoverPeripheral: not working sometimes on background
Not able to search my BLE Device which is providing service ID in scan Response iOS
Source file : https://drive.google.com/file/d/1uVR_kA3NsQUpM-LLgrGgXCeZK6PBO-A7/view?usp=sharing
Found this question a bit interesting, so went about studying CoreBluetooth.
As per the Core bluetooth programming guide
Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for device while in the background:
The CBCentralManagerScanOptionAllowDuplicatesKey scan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event.
If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral.
Now in your provided sample the background modes are correctly provided.
iOS looks for advertising packets only in background [Passive] mode and not the response packets
Searching further bought me to this link
ios- Scan and connect to BLE peripheral in background
You can check and see if this too is the case with you

continuous run app in background. iOS Swift

in my app, I am connecting my app to BLE device. and I am fetching BLE data from BLE device at every 1 second. it working fine when I do this in the foreground.but I want to do same in the background even when the app will be in the background I need to fetch data continuously from BLE device. right now its stoped automatically after 2 minutes.
Please let me know if it's feasible or not?
Thanks in advance
You need to enable Background Mode in your project settings under capabilities tab. Under background modes you will find a few modes that satisfy various purposes of running an app in background. From these you have to enable the ones that you think are suitable according to the task that your app will perform in background. I think, you should enable external accessory communication and background fetch.
Also you need to implement a background task when your app enters background. This is done in app delegate's didEnterBackground method.
Apple documentation
Apps that work with Bluetooth peripherals can ask to be woken up if the peripheral delivers an update when the app is suspended. This support is important for Bluetooth-LE accessories that deliver data at regular intervals, such as a Bluetooth heart rate belt. You enable support for using bluetooth accessories from the Background modes section of the Capabilities tab in your Xcode project. (You can also enable this support by including the UIBackgroundModes key with the bluetooth-central value in your app’s Info.plist file.) When you enable this mode, the Core Bluetooth framework keeps open any active sessions for the corresponding peripheral. In addition, new data arriving from the peripheral causes the system to wake up the app so that it can process the data. The system also wakes up the app to process accessory connection and disconnection notifications.
In iOS 6, an app can also operate in peripheral mode with Bluetooth accessories. To act as a Bluetooth accessory, you must enable support for that mode from the Background modes section of the Capabilities tab in your Xcode project. (You can also enable this support by including the UIBackgroundModes key with the bluetooth-peripheral value in your app’s Info.plist file.) Enabling this mode lets the Core Bluetooth framework wake the app up briefly in the background so that it can handle accessory-related requests. Apps woken up for these events should process them and return as quickly as possible so that the app can be suspended again.
Any app that supports the background processing of Bluetooth data must be session-based and follow a few basic guidelines:
Apps must provide an interface that allows the user to start and stop the delivery of Bluetooth events. That interface should then open or close the session as appropriate.
Upon being woken up, the app has around 10 seconds to process the data. Ideally, it should process the data as fast as possible and allow itself to be suspended again. However, if more time is needed, the app can use the beginBackgroundTaskWithExpirationHandler: method to request additional time; it should do so only when absolutely necessary, though.

Connected peripheral in background mode (Core Bluetooth)

I'm trying to achieve the following scenario:
Open the app and connect to a BLE Peripheral. Working
Send the app to the background and keep the connection alive. Working
Turn off the BLE Peripheral and the app is notified of the disconnection. Working
Turn on the BLE Peripheral and the app is notified of the disconnection. Working
Turn off again the BLE Peripheral. Working
Wait 2 days with the app in background and turn on the BLE Peripheral, but the app does nothing. NOT Working
How can I achieve this last step? iOS kills the background apps when needed, but is there a way of getting notified when a previously-connected peripheral is discovered? I read something about CB State Restoration but I don't really know if this will solve this situation.
Core Bluetooth state preservation / restoration is exactly what you want. If your app is suspended, it will start you app if a peripheral connects / disconnects or a notification arrives. It is however broken by design in the way that your app will stop being woken up if Bluetooth is restarted for any reason. Examples are Bluetooth crashes (happens every now and then), if the user toggles Bluetooth or flight mode, or if the phone is restarted.

Push Notification App Running in Background When BLE is Connected

I worked on an Application which is Worked on BLE. i want push a notification ( App Running in Background When BLE is Connected) if any changes in Hardware. I Read Document
Even if your app supports one or both of the Core Bluetooth background execution modes, it can’t run forever. At some point, the system may need to terminate your app to free up memory for the current foreground app—causing any active or pending connections to be lost, for instance.
can i achieve my goal even my app in Background . If It is Possible Suggest me how to Achieve this . Thanks In Advance.
You may keep app in background by means of:
1.Audiosession(use this to play silent sound)
2.Location
3.VoIP
Any method can keep App in background and avoid App from being killed by system.
BLE Runs in the background, you need to specify that your app uses BLE Accessories or your app acts as a LE Accessory in the Background modes in app capabilities.
I've tried firing local notifications, while the application is in the background. BLE even works if the app is killed by the system, when the OS receives some communication from your peripheral or central, iOS wakes your app up and executes the desired function, before putting your app back to sleep.

Launching iOS BLE Central application on iPhone reboot

I am planning to develop an iOS application using CoreBluetooth framework which monitors a pedometer peripheral continuously and counts the footsteps.
I know that if backgroud execution mode is set to BLE Central, the application will continue to receive BLE events even in the background.
Apple documentation states that in case the app gets terminated due to low memory, the system can keep track of BLE events for a particular Central Manager if state preservation and restoration is adopted.
Assume I have an iOS application that operates in Central mode. The app is subscribed to receive notification from a Pedometer when ever the footstep characteristic changes.
I have adopted the following in my app.
BLE Central background mode
BLE State preservation/restoration for Central Manager
I start my app, Scan, Pair and Connect to the pedometer and the app starts receiving footsteps.
My Questions:
Now if the iPhone reboots, Will I continue to receive BLE events so that my app will be launched in the background without the user having to manually launch the application again and connect to the pedometer?
If the app is terminated by the user explicitly using the multitasking gesture, Will the app be able to receive BLE events without the user having to manually launch the application again and connect to the pedometer?
Is there a way to launch my application on iOS boot up?
Now if the iPhone reboots, Will I continue to receive BLE events so that my app will be launched in the background without the user having to manually launch the application again and connect to the pedometer?
Your app won't receive BLE events because all apps are started in the terminated state after a reboot (despite remaining in the app switcher). The user will have to manually launch your app at least once after reboot in order for it to use BLE.
If the app is terminated by the user explicitly using the multitasking gesture, Will the app be able to receive BLE events without the user having to manually launch the application again and connect to the pedometer?
Same as above, the app has entered the terminated state, so it won't be able to communicate using BLE until it is explicitly launched again.
Is there a way to launch my application on iOS boot up?
iOS doesn't provide any way to launch your application on boot.
The one exception to all of this that I can find is iBeacons. If your app registers to receive updates for a specific iBeacon, iOS will launch your app when it finds it (even after a reboot or if the user explicitly kills it from the switcher). When you get the iBeacon callback you can start all your BLE logic and it will then run in the background per usual. Of course this means you need to advertise as an iBeacon on your pedometer, which may or may not be feasible.
Bear in mind the detection of the iBeacon is pretty finicky, especially after a reboot. You have little guarantee as to how fast or even if you will be delivered the iBeacon callback to start your app. But it's something.
Source

Resources