【问题标题】:IOS corebluetooth Background mode notificationIOS corebluetooth 后台模式通知
【发布时间】:2013-09-04 05:57:07
【问题描述】:

目前正在使用核心蓝牙处理该项目。在其中使用后台模式通信时,能够在应用程序在后台运行时收到通知,但我们只有一项服务和一项基于帧类型的数据通信特征,我们能够识别接收到的帧。

对于后台模式我使用了这个代码

[centralManager connectPeripheral:activePeripheral options:@{CBConnectPeripheralOptionNotifyOnConnectionKey: @YES,
    CBConnectPeripheralOptionNotifyOnDisconnectionKey: @YES,
    CBConnectPeripheralOptionNotifyOnNotificationKey: @YES}];

它适用于事件和会话背景。

每个通知的事件背景警报显示是否有任何方法可以隐藏每个通知显示的警报。

谢谢

【问题讨论】:

  • 我想我可以帮助你,但前提是你能更好地表达你的问题。我真的不明白你的问题是什么,你想要实现什么以及你的应用程序的当前状态是什么。尝试编辑您的问题并以更清晰的方式提供更多信息。干杯

标签: ios notifications core-bluetooth


【解决方案1】:

在事件模式中,警报是由系统生成的,只要你的应用没有被激活,它就无法对它们做任何事情。

在会话模式中,应用负责处理所有这些事件。它像在前台一样接收所有回调。如果你想尽量减少对用户的干扰,你应该用这种模式接管警报生成。

【讨论】:

  • 当设备处于会话模式时,是否有一定的时间可以保持活动状态?它如何知道在后台重新连接并开始通信?
  • 您的应用程序将收到一个回调并在每个 BLE 事件(连接、断开连接、发现、通知等)上获得大约 8 秒的时间,但它无法运行。否则它必须保持暂停状态。但是无法在所需时间唤醒应用程序。只有连接的对等方生成的 BLE 事件才能做到这一点。
  • @allprog 8 秒部分对us.. 来说非常有趣。你从哪里得到这个数字?有官方文档吗?
  • 好的,知道了from apple docs:Upon being woken up, an app has around 10 seconds to complete a task. Ideally, it should complete the task as fast as possible and allow itself to be suspended again. Apps that spend too much time executing in the background can be throttled back by the system or killed.
猜你喜欢
  • 2017-02-16
  • 1970-01-01
  • 2017-01-30
  • 2014-03-30
  • 2019-06-08
  • 1970-01-01
  • 1970-01-01
  • 2013-03-24
  • 2021-05-02
相关资源
最近更新 更多