外围设备需要特殊ACK时的CoreBluetooth和状态保存与恢复

时间:2019-05-07 07:01:48

标签: ios swift core-bluetooth state-restoration

我正在使用蓝牙外围设备,在与蓝牙外围设备连接之后,它会来回发送ACK,然后它才能实际将所需的数据发送给我。

流程如下:

  1. 发现外围设备
  2. 连接到外围设备
  3. 发现服务和特征
  4. 收听有关特定特征的更新
  5. 外围设备向该特征发送特殊消息
  6. 然后,该应用将ACK发送到外围设备
  7. 外围设备向我发送应用程序所需的数据

我已经在状态保存和恢复centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any])的协议方法中实现了所需的逻辑

问题1:

当应用程序处于后台并且iOS决定接管蓝牙通信(出于资源原因)时,iOS将如何执行步骤5、6和7?

因为如果不能,那么外围设备将无法发送应用程序在步骤7中所需的数据。

问题2:

在文档中,我读到iOS可能会启动您的应用几秒钟。在这种情况下,将执行我的根ViewController的viewDidLoad方法吗?那就是我实例化CBCentralManager

的地方

我发现了许多在线资源:

Core Bluetooth Background Processing for iOS Apps

Zero to BLE on iOS – Part Three

1 个答案:

答案 0 :(得分:0)

Paulw11的以下两条评论帮助我了解发生了什么:

  

不,那不会发生。如果您有待处理的发现,待处理的“连接”或者您对某个特征有有效的通知,则iOS将重新启动您的应用程序,以便它可以处理发现,连接或通知。 iOS无法代表您执行此操作;它不知道你想做什么。 – Paulw11


  

如果要在后台执行操作,则将蓝牙对象连接到视图控制器是一个坏主意。我建议您由应用程序代表Paulw11拥有一个单例或对象


首先,我有一个错误的假设:当我的应用程序处于后台并且iOS必须终止它时,iOS会尝试代表我的应用程序处理所有蓝牙通信。现实情况是,iOS在有限的时间内以后台模式启动该应用程序,以便您可以运行恢复代码。

最后,在ViewController的viewDidLoad中包含逻辑是错误的。我创建了一个BluetoothManager类,并在我的application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool的{​​{1}}方法中实例化了它