CoreBluetooth:如何为许多特性(30 - 40)设计代码? [英] CoreBluetooth: How to design code for many characteristics (30 - 40)?

问题描述

我搜索了一下，发现这是一个可能重复的问题:

I searched around a bit and just found this as a possible duplicate question:

同一设备的多个 CBPeripheral

我的问题是:

我有多种服务，它们总共具有大约 30-40 个特征(是的，我需要所有这些......).作为处理 CoreBluetooth 的起点，我总是使用 Apple 示例代码 (CoreBluetooth 温度传感器).

I have multiple services which all together have about 30-40 characteristics (Yes, I need all of them...). As starting point for dealing with CoreBluetooth I always used the Apple Sample Code (CoreBluetooth Temperature Sensor).

发现和服务/特征处理分为两类，这仅适用于少数特征.但是在一个类中处理如此大量的特性并不是我所理解的优秀的软件设计".

Discovery and Service/Characteristic handling is divided into two classes and this works fine for just a few characteristics. But handling this huge amount of characteristics in one class is not what I understand under "good software-design".

人们想到的第一个想法是为每个服务创建一个类.但不幸的是，一个 CBPeripheral 只能同时拥有一个 CBPeripheralDelegate.这意味着我不能把它分成几类.

The first idea that come into ones mind is to create one class for every service. But unfortunately a CBPeripheral just can have one CBPeripheralDelegate at the same time. This means I can't divide it up into several classes.

(我们不必开始讨论 BLE 是否是获取如此大量数据的正确技术 - 事实并非如此.但有些制造商使用 BLE，因此他们不必为MFi 程序...)

我还阅读了最终提供的 CoreBluetooth编程指南，但它只描述了基本的工作流程——与正确的设计无关.

I also read the finally provided CoreBluetooth Programming Guide but it just describes basic workflows - nothing about the right design.

我正在寻找一种不错的设计方法.您可能有任何建议、提示或示例代码链接?非常感谢！

I'm looking for a nice design approach. You may have any suggestions, hints or links to sample code? Many thanks in advance!

推荐答案

将逻辑分解成几个自包含的类总是好的设计.您绝对应该尝试根据服务或其他类别对代码进行分组.即使外围设备只有一个委托，您也可以轻松实现调度程序模式，您可以在其中注册各种服务实现和选择键(实际上是服务对象)并将调用调度到指定的服务处理程序.如果服务类实现了 CPPeripheralDelegate 协议，那么这种设计将允许您在需要时单独测试/重用每个服务，而对代码进行最少的更改.

Breaking out logic into several self contained classes is always good design. You should definitely try to group your code according to services or other categories. Even though the peripheral has only a single delegate, you can easily implement the dispatcher pattern where you register the various service implementations and selection keys (practically the service objects) and dispatch the call to the designated service handler. If the service classes implement the CPPeripheralDelegate protocol, then this design will allow you to test/reuse each service separately if you need to with minimal changes in the code.

在伪 obj-c 代码中，调度程序外设委托如下所示:

In pseudo obj-c code the dispatcher peripheral delegate would look like as follows:

// The ivar/property serving as the registry
NSMutableDictionary *registeredHandlers = [[NSMutableDictionary alloc] init];

- (void)peripheral:(CBPeripheral *)peripheral didDiscoverServices:(NSError *)error {
  // for each service create an instance of its handler class and
  // add them to the registered handlers
  for (CBService *service : peripheral.services) {
    if (!registeredHandlers[service]) { // don't reinitialize if not needed
      ExtendedCBPeripheralDelegate *serviceHandler = [self instantiateHandlerForService:service];
      [registeredHandlers setObject:serviceHandler forKey:service];
      [serviceHandler discoverCharacteristics]; // make this functionality self contained for the service
    }
  }
}

在与服务或特征相关的回调中，应该实现调度.一个例子:

In service or characteristic related callbacks the dispatching should be implemented. An example:

- (void)peripheral:(CBPeripheral *)peripheral didDiscoverCharacteristicsForService:(CBService *)service error:(NSError *)error {
  ExtendedCBPeripheralDelegate *serviceHandler = registeredHandlers[service];
  [serviceHandler peripheral:peripheral didDiscoverCharacteristicsForService:service error:error];
}

- (void)peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic error:(NSError *)error {
  ExtendedCBPeripheralDelegate *serviceHandler = registeredHandlers[characteristic.service];
  [serviceHandler peripheral:peripheral didWriteValueForCharacteristic:characteristic error:error];
}

如果中央管理器断电，那么最好的解决方案是丢弃整个外围委托.不要理会重新初始化，而是计划处置.当然，如果需要，您可以通知服务处理程序即将销毁.

If the central manager is powered off, then the best solution is to drop the whole peripheral delegate. Don't bother with reinitialization, rather plan for disposal. Of course, if needed, you can notify the service handlers of the imminent destruction.

这篇关于CoreBluetooth:如何为许多特性(30 - 40)设计代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！