You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of 5.0 release we want to simplify the library by changing it’s architecture. This will allow us to remove any code duplication that is part of the current release of the library
Change design
Current hierarchy for every CoreBluetooth object looks as follows:
Main object that user of the library is interacting with ie. Peripheral
Protocol that exposes delegate method callbacks & methods that perform Bluetooth related operations (scan, connection) ie. RxPeripheralType.
Concrete implementation of the protocol that is using CoreBluetooth objects: RxCBPeripheral. These are injected to the main objects and allow for the normal use of the library
Fakes that are implementing the protocols ie. FakePeripheral. We’re injecting them into main objects for the purpose of unit tests.
We would like to get rid of the last 3 layers when implementing the cleanup. After the currently described issue will be implemented tests will not be a part of the library and will come back a bit later. We believe that the new approach to testing the library will be much easier and allow to make changes and API additions faster. It should also make tests way more concise than today.
As a result of this task:
All protocols, concrete implementations and fakes should be removed
Tests related to the Bluetooth stack hierarchy should be removed
Then, all main, user facing objects will directly use it’s CB counterparts and call the methods on them. To receive delegate callbacks, BluetoothManager and Peripheral will contain delegate wrappers object. First one will conform to the CBCentralManagerDelegate protocol and the second one to the CBPeripheralDelegate protocol. Both will expose delegate callbacks via observables to the main objects.
How it affects the current users
External API of the BluetoothManager, Peripheral, Service, Characteristic, Descriptor and any of the dependent objects will not be changed. Therefore it is not considered a breaking change.
The text was updated successfully, but these errors were encountered:
* Removed test files
* Removed architecture overload for service, characteristic and descriptor
* Removed references to BluetoothManager related overhead objects
* Final fixes
* Fixed identifier variable on UUID
* Removed comments related to RxCB layer
* Fixed the unnecessary comments and fixed variables namings
* Review fixes
As part of 5.0 release we want to simplify the library by changing it’s architecture. This will allow us to remove any code duplication that is part of the current release of the library
Change design
Current hierarchy for every
CoreBluetooth
object looks as follows:Peripheral
RxPeripheralType
.CoreBluetooth
objects:RxCBPeripheral
. These are injected to the main objects and allow for the normal use of the libraryFakePeripheral
. We’re injecting them into main objects for the purpose of unit tests.We would like to get rid of the last 3 layers when implementing the cleanup. After the currently described issue will be implemented tests will not be a part of the library and will come back a bit later. We believe that the new approach to testing the library will be much easier and allow to make changes and API additions faster. It should also make tests way more concise than today.
As a result of this task:
Bluetooth
stack hierarchy should be removedThen, all main, user facing objects will directly use it’s
CB
counterparts and call the methods on them. To receive delegate callbacks,BluetoothManager
andPeripheral
will contain delegate wrappers object. First one will conform to theCBCentralManagerDelegate
protocol and the second one to theCBPeripheralDelegate
protocol. Both will expose delegate callbacks via observables to the main objects.How it affects the current users
External API of the
BluetoothManager
,Peripheral
,Service
,Characteristic
,Descriptor
and any of the dependent objects will not be changed. Therefore it is not considered a breaking change.The text was updated successfully, but these errors were encountered: