[Feature]: iOS Core Bluetooth Background Processing support

[William-Geng]

FlutterBluePlus Version

1.31.17

Flutter Version

3.19.3

What OS?

iOS

OS Version

17

Bluetooth Module

nordic nRF52832

What is your feature request?

It would be nice to support iOS core bluetooth background execution mode as described here: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html.

I believe there is a PR for flutter_blue that was never merged: https://github.com/pauldemarco/flutter_blue/pull/191 and https://github.com/pauldemarco/flutter_blue/pull/210.

Logs

none

[chipweinberger]

feel free to create new PRs and test them

[MrCsabaToth]

FYI there was a https://github.com/espresso3389/flutter_blue fork of the original pauldemarco flutter_blue back in the day which dealt with foreground task issue as well, along with some emphasis on iOS and also permissions. But seems like that fork died too some times after flutter_blue, but it might be useful to see what PRs they merged and what they did for this.

I'll need some foreground support as well in my app at some point - highly requested -, however this seems to be a major undertaking in my case. More specifically at my app level this looks to be a significant architectural change. Even though there are plugins such as https://pub.dev/packages/flutter_foreground_task/ you can see it's unfortunately not a simple yaml include and a plop in of a code snippet: it's a detailed 5+ step staged procedure. I also don't see a way - once I convert my app - to have that functionality be optional. That's important because if such function would be at the FBP plugin level, it could happen not everyone would want it: because for example it needs extra manifest declarations, you'd need to select type of service, extra permission shenanigans, declaring callbacks, and the list goes on and on.

But ultimately I'd need to tackle this as well for user request. I wonder if it's even doable at FBP level, it'll be hard enough at app level. I'm curious what is your use-case and plans.

[Codel1417]

My initial testing with the app in the background, using a 15 second keep awake ping, kept my app open.

[h4nkyn]

What type of keep awake ping are you talking about? Like a characteristic value change?

[Codel1417]

What type of keep awake ping are you talking about? Like a characteristic value change?

Yeah. Having a characteristic value change wakes the app for 10-15 seconds. If you do this enough the app stays open. The device I connect to uses 2 characteristics for a read/write command setup so I just sent ping which gets a response.

[drolpi]

@chipweinberger are there any updates on this? I absolutely need this feature! Otherwise, I have to completely rebuild my app in a different language with a different framework. Can someone please implement IOS BLE State Restoration.

[chipweinberger]

@drolpi

Can someone please implement IOS BLE State Restoration.

I don't need this feature, so I wont be working on it.

If you really don't want to implement it yourself, I could implement it for you, but for a fee. email me if interested.

[MrCsabaToth]

@chipweinberger are there any updates on this? I absolutely need this feature! Otherwise, I have to completely rebuild my app in a different language with a different framework. Can someone please implement IOS BLE State Restoration.

BLE State Restoration and background services are two different things, although may not be completely unrelated: in case the the background service gets yeeted (this part of Android is not standardized https://dontkillmyapp.com/) then restoration may come into play?

[MrCsabaToth]

I think Chip did some work related to reconnection if I'm not mistaken, however BLE State Restoration sounds more formal.

[chipweinberger]

https://github.com/boskokg/flutter_blue_plus/pull/939

there was this nearly complete PR recently

[chipweinberger]

I've pushed this commit (https://github.com/chipweinberger/flutter_blue_plus/commit/12c17a6f49c3d6223f7dffaa75f845ccc01c8701) , which should enable this feature. But I have not been able to get it to work in actual testing.

1. when the app is killed, the app is not restored ❌
2. when the phone is rebooted, the app is not restored ❌

If anyone else wants to try it, please do, and report back. To use it, just call FlutterBluePlus.setOptions, like this

void main() {
  FlutterBluePlus.setOptions(restoreState: true);
  FlutterBluePlus.setLogLevel(LogLevel.verbose, color: true);
  runApp(const FlutterBlueApp());
}

You also need to update the info.plist

<key>UIBackgroundModes</key>
<array>
    <string>bluetooth-central</string>
</array>

[chipweinberger]

released version 1.32.13 with State Preservation

[Scottie-Fischer]

• when the app is killed, the app is not restored ❌
• when the phone is rebooted, the app is not restored ❌

I made some minor tweaks using your latest update and was able to get it to restore the CBCentralManager and peripherals. I did see some issues where when I restore the peripheral and save it in the connectedDevices list that it times out when trying to discover services or subscribe to characteristic using setNotifyingValue. Have not pinned down the issues, but will make a PR.

Additionally I created a restoration state that tells the app whether or not it was restored or the initial start. This may be useful for diverging behaviors, but not technically required.

[chipweinberger]

awesome!

i look forward to the PR!