Ich habe ein wenig gesucht und das als mögliche doppelte Frage gefunden:
Mehrere CBPeripherals für dasselbe Gerät
Mein Problem ist:
Ich habe mehrere Dienste , die alle zusammen etwa 30-40 Merkmale haben (Ja, ich brauche alle von ihnen ...). Als Ausgangspunkt für den Umgang mit CoreBluetooth habe ich immer den Apple-Beispielcode ( CoreBluetooth Temperature Sensor ).
Erkennung und Service / Merkmal-Handling ist in zwei Klassen unterteilt, und das funktioniert gut für einige Merkmale. Aber die Handhabung dieser riesigen Menge an Eigenschaften in einer Klasse ist nicht, was ich unter "gutes Software-Design" verstehe.
Die erste Idee, die Ihnen in den Sinn kommt, ist eine Klasse für jeden Dienst zu erstellen. Aber leider kann ein CBPeripheral gleichzeitig nur ein CBPeripheralDelegate haben. Dies bedeutet, dass ich es nicht in mehrere Klassen aufteilen kann.
( Wir müssen die Diskussion nicht beginnen, wenn BLE die richtige Technologie ist, um diese Datenmenge zu erhalten - das ist es nicht. Aber es gibt Hersteller, die BLE verwenden, damit sie sich nicht damit herumärgern müssen das MFi-Programm ... )
Ich lese auch das endlich bereitgestellte CoreBluetooth Programmierhandbuch aber es beschreibt nur grundlegende Arbeitsabläufe - nichts über das richtige Design.
Ich suche nach einem schönen Designansatz. Sie haben möglicherweise Vorschläge, Hinweise oder Links zu Beispielcode? Vielen Dank im Voraus!
Das Ausbrechen von Logik in mehrere eigenständige Klassen ist immer ein gutes Design. Sie sollten unbedingt versuchen, Ihren Code nach Services oder anderen Kategorien zu gruppieren. Obwohl das Peripheriegerät nur über einen einzelnen Delegaten verfügt, können Sie das Dispatchermuster, in dem Sie die verschiedenen Dienstimplementierungen und Auswahlschlüssel (praktisch die Dienstobjekte) registrieren, problemlos implementieren und den Aufruf an den angegebenen Diensthandler weiterleiten. Wenn die Serviceklassen das Protokoll CPPeripheralDelegate implementieren, können Sie mit diesem Design jeden Dienst einzeln testen / erneut verwenden, wenn Sie nur minimale Änderungen am Code vornehmen müssen.
Im Pseudo-Obj-c-Code würde der Dispatcher-Peripherie-Delegat wie folgt aussehen:
%Vor%Bei dienst- oder merkmalbezogenen Callbacks sollte das Dispatching implementiert werden. Ein Beispiel:
%Vor%Wenn der zentrale Manager ausgeschaltet ist, ist es die beste Lösung, den gesamten peripheren Delegierten zu löschen. Kümmern Sie sich nicht um Reinitialisierung, sondern planen Sie die Entsorgung. Natürlich können Sie bei Bedarf die Service-Handler über die drohende Zerstörung benachrichtigen.
Tags und Links ios architecture core-bluetooth software-design cbperipheral