Architecture

One of the main goals of this library is to separate the responsibilities of the connection process in different classes in order to have a more maintainable and easy to read code. We think that by providing small classes with concrete responsibilities, the application's code will be easier and simpler to write. The following is a list of the most important classes and protocols in this library:

• WLXBluetoothDeviceManager: The root class of the library that provides access to all the other classes.
• WLXDeviceDiscoverer: A protocol that exposes an API to discover devices with Bluetooth 4.0 capabilities.
• WLXConnectionManager: A protocol that exposes an API to manage the connection life cycle with a Bluetooth device that was previously discovered.
• WLXServicesManager: A class that provides a way to discover services and create a manager for each discovered service.
• WLXServiceManager: A class that manages a Bluetooth service providing an API to interact with it. This is the class that allows clients to read and write values to a characteristic.

WLXBluetoothDeviceManager

The root class that provides access to all the other classes is WLXBluetoothDeviceManager. You should never create an instance of another class of this library except from WLXBluetoothDeviceManager. Any other object instance of this library should be obtained from an instance of WLXBluetoothDeviceManager.

Although is not necessary, is recommended to only have one instance of this class in the application's life cycle. There are several way to get an instance but the easies one is to call the class method deviceManager. This method will create a new instance of WLXBluetoothDeviceManager using a default dispatch_queue_t. This means that all the bluetooth related operation will be executed on dedicated serial dispatch queue. You can also create an instance of WLXBluetoothDeviceManager with your own custom dispatch queue by calling the class method deviceManagerWithQueye:. Keep in mind that the use of serial dispatch queues is recommended because they assure that the messages will be processed in the same order they arrived and one at a time. This might be important for your application's logic and is a safe default.