OBJ-C操作方法：App在同一设备中使用BLE连接和iBeacon [英] OBJ-C how-to: App using BLE connection and iBeacon in same device
问题描述
我有一个用例，我的objective-c应用程序需要在终止之后立即使用iBeacon，以便从终止状态唤醒应用程序，连接到BLE并向设备发送命令。我有一个更大的长期运行发布在这里如果需要，你可以查看我的代码。
问题
<到目前为止，问题发生在我运行应用程序，搜索以前配对的设备和/或扫描外围设备，找到我的BLE设备并连接时。连接后，用户将BLE连接配对，以便它们可以通过BLE连接发送加密的特征数据。如果没有配对（在设备的命名约定中也称为auth / bond），用户根本无法将数据发送到设备。它永远不会在那里。只要您配对就可以发送命令......
当我终止应用程序时，在 applicationWillTerminate 中方法，我运行此代码...
- （void）applicationWillTerminate：（UIApplication *）application {
NSLog（@***申请将终止。）;
NSUserDefaults * userDefaults = [NSUserDefaults standardUserDefaults];
NSNumber * mode = [userDefaults objectForKey：@deviceConnectedMode];
if（[mode intValue] == CONNECTED_MODE_INDICATOR）{
[self.bluetoothManager sendCodeToBTDevice：@magiccommand1
characteristic：self.bluetoothManager.wipeCharacteristic];
//我在测试中打开和关闭此命令，看看我是否可以在设备断开连接而不是在应用程序中更好地工作...
//命令magiccommand2擦除设备内部的auth / bond
// [self.bluetoothManager sendCodeToBTDevice：@magiccommand2
//特性：self.bluetoothManager.disconnectCharacteristic];
//我试图停止连接BT
的位置[self.bluetoothManager disconnectDevice];
[self.beaconManager startMonitoring];
NSLog（@***应用程序从连接模式终止！）;
}其他{
NSLog（@*** DriveCare终止，没有违规！）;
}
}
我想要实现的目标
magiccommand1 和 magiccommand2 命令只是设备正在通过串口侦听的傻测试字符串（现在，后来是128位令牌）。一旦他们收到命令，他们会通过尝试擦除设备上的身份验证/绑定以及断开设备中的BLE来做出反应。
所以我唯一的方式就是得到应用程序从终止状态唤醒是与iBeacon。所以我不得不在这里做一堆看似肮脏的东西，只是为了将这个圆形钉子放在一个方孔中。在应用程序的生命周期中，它连接并配对，当我终止时，我希望它完全从BLE作为连接设备被删除。我希望iBeacon将唤醒应用程序，连接回BLE，关闭iBeacon监控，然后从终止状态向BLE设备发送命令。这种打开/关闭或连接/断开iBeacon到BLE和返回很可能导致用户必须重新配对，我不想这样做。
更多问题
当我致电 [self.centralManager cancelPeripheralConnection：self.thePeripheral]; iOS系统级BT管理器似乎几乎立即自动重新连接（因为配对）所以没有时间断开连接并再次拾取iBeacon。如果我在将断开命令发送到我的框之前尝试断开与我的 centralManager 实例的连接（如上面的代码注释中所示），他们显然也不会发送。如果我只使用那个 CBCentralManager disconnect方法，那么iBeacon开始被检测是不够的，因为iOS系统仍然与设备配对。最后，如果我进入我的iOS系统BT管理器并选择忘记此设备，iBeacon将再次被选中并且我的 didEnterRegion 方法将被触发！
这是iBeacon和BLE之间的大量来回，我只是希望我甚至不需要iBeacon来唤醒应用程序。我已经打开了所有info.plist后台BLE和iBeacon服务。如果我根本没有连接到BLE并且从未配对并连接我的设备，本地应用程序通知会毫无问题地滑入，让我知道iBeacon didEnterRegion 和 didExitRegion 方法被解雇没有问题。
我在这里做错了什么？
我想出了这个答案！我有点走在正确的道路上......尝试断开BT配对以试图让iBeacon委托方法解雇并不是一个好主意。它导致了许多奇怪的脏代码，紧密耦合的东西，不应该和更糟糕......可怕的意大利面条代码。
相反我的解决方案是建立一个板里面有2个蓝牙芯片。一个是专用的iBeacon芯片，另一个是永久连接/配对/ auth和bonded芯片。这样就不需要监视任何定时连接和断开事件（或者更糟......解决竞争条件）。在iOS中等待设备断开连接不是真正的断开连接，而是当iOS系统认为它已断开连接时（在电话方面）。外围系统内部发生的事情描绘了一幅截然不同的画面...
这种2芯片方法让开发方面的生活变得更加轻松，因为现在随时都可以唤醒处理某些东西的应用程序，您可以重启iBeacon设备并接收相应的事件。
旁注：使用iBeacon时 didEnterRegion 方法几乎立即触发，因为 didExitRegion 有时可能需要30秒或更长时间才能触发。因此，如果您需要立即检测信标，您应该尝试确保iBeacon正在通电而不是关闭...如果可能的话。
I have a use case where my objective-c application needs to immediately use iBeacon after it's been terminated in order to wake the application up from a terminated state, connect to BLE and send a command to the device. I have a larger longer running post found here that you can check out for my code if need be.
The Problem
The problem so far, happens when I run the application, search for previously paired devices and/or scan for peripherals, find my BLE device and connect. Once connected the user pairs the BLE connection so that they can send encrypted characteristic data over BLE connection. Without pairing (aka auth/bond in the device's naming conventions) the user cannot send the data to the device at all. It never makes it there. As soon as you pair you can send the command...
When I terminate the app, in the applicationWillTerminate method, I run through this code...
- (void)applicationWillTerminate:(UIApplication *)application {
NSLog(@"*** Application Will Terminate.");
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
NSNumber *mode = [userDefaults objectForKey:@"deviceConnectedMode"];
if([mode intValue] == CONNECTED_MODE_INDICATOR) {
[self.bluetoothManager sendCodeToBTDevice:@"magiccommand1"
characteristic:self.bluetoothManager.wipeCharacteristic];
//I have been turning this command on and off in testing to see if I can get it to work better while disconnecting in the device rather than in the app...
//The command magiccommand2 wipes the auth/bond inside of the device
// [self.bluetoothManager sendCodeToBTDevice:@"magiccommand2"
// characteristic:self.bluetoothManager.disconnectCharacteristic];
//Place where I attempt to stop being connected to BT
[self.bluetoothManager disconnectDevice];
[self.beaconManager startMonitoring];
NSLog(@"*** Application terminated from connected mode!");
} else {
NSLog(@"*** DriveCare terminated without violation!");
}
}
What I am trying to accomplish
The magiccommand1 and magiccommand2 commands are just silly test strings (for now, 128 bit tokens later) that the device is listening for over the serial port. Once they receive the commands they react by attempting to wipe the auth/bond on the device and also disconnecting from BLE in the device.
So the only way I can seem to get the app to wake up from a terminated state is with iBeacon. So I am having to do a bunch of seemingly dirty stuff here just to get this round peg in a square hole. In the app's lifecycle it connects and pairs and when I terminate I want it to completely be removed as a connected device from BLE. My hope is that iBeacon will wake up the app, connect back to BLE, shut off iBeacon monitoring and then send a command to the BLE device from a terminated state. This turning on/off or connecting/disconnecting from iBeacon to BLE and back would most likely cause the user to have to re-pair and I don't want this.
More Problems
When I call [self.centralManager cancelPeripheralConnection:self.thePeripheral]; the iOS system level BT manager seems to auto reconnect almost instantly (because of the pairing) so there is no time for the connection to be severed and iBeacon to be picked up again. If I attempt to disconnect from my centralManager instance before sending the disconnect command to my box (as seen above in code commented out) they obviously wont send either. If I just use only that CBCentralManager disconnect method it isn't enough for iBeacon to begin being detected as the iOS system is still paired with the device. Lastly, if I then go into my iOS system BT manager and choose "Forget this device", the iBeacon gets picked up again and my didEnterRegion method fires!
This is a lot of back and forth between iBeacon and BLE and I just wish I didn't even need iBeacon to wake up the app. I have all info.plist background BLE and iBeacon services turned on. If I don't connect to BLE at all and never pair once and connect my device, the local app notifications slide in without problem letting me know that the iBeacon didEnterRegion and didExitRegion methods are being fired without trouble.
What am I doing wrong here?
I figured out this answer! I was sort of on the right path... It's not a great idea to try and disconnect from BT pairing in order to try to get iBeacon delegate methods to fire. It causes a lot of weird dirty code, tightly coupled things that shouldn't be and worse... the dreaded spaghetti code.
Instead my solution was to build a board with 2 Bluetooth chips in it. One as a dedicated iBeacon chip and the other as a permanent connected/paired/auth and bonded chip. This way there does not need to be any timed connection and disconnection events to be monitored (or worse... resolved race conditions). Waiting for a device to disconnect in iOS is not a true disconnect, it is instead when the iOS system thinks it's disconnected (in the phone's side of things). The things going on inside of the peripheral system paint a very different picture...
This 2 chip approach made life so much easier on the development side because now anytime you need the application to wake up to handle something, you can power cycle the iBeacon device and receive the appropriate event.
Side note: When using iBeacon the didEnterRegion method fires almost instantly where as the didExitRegion can take 30 or more seconds sometimes to fire. Therefore if you need immediate beacon detection resolution you should try to make sure the iBeacon is being powered on and not off for this... if even possible.
这篇关于OBJ-C操作方法：App在同一设备中使用BLE连接和iBeacon的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
