This is a series, in which I explore using the Apple Core Bluetooth Framework to interact with Bluetooth devices.
When I write SDKs, they tend to take the form of “object models.” That is, they provide a set of instances to the user, simulating/emulating the lower-level system (in the past, these have been class instances, which are objects, but these days, Swift can provide a number of choices. I’ll still call them “objects,” but they could be structs or enums).
I have taken the liberty of creating a Swift file that will define the SDK.
I have removed the [extensive] comments, in order to simplify the visual impact. The original file will contain the comments.
Here is the tag for this step. We can consider this our “starting point.” At this point, all four apps are complete, and use a “dummy” mocked version of the SDK (no actual Bluetooth going on). We also have the first full draft of the SDK ready.
At this point, we have four test harness/demo apps prepared and ready to go. They currently operate using a very simple “mock” functionality that I took the liberty of adding to the SDK.
We also have the “skeleton” of the SDK ready. The SDK can be instantiated into two sets of functionality: Central (Bluetooth Central behavior), and Peripheral (Acting as a Bluetooth Peripheral).
The Central will “ask questions” of the Peripherals, which will act as “Magic 8-Balls.” In the Mac, iOS and TVOS variants of the apps, the user will be able to enter a question manually. In the Watch variant, due to the difficulty of entering arbitrary text, we will choose a random question from a pool of 20 questions.
Each Peripheral will have a pool of 20 answers. These will reflect the original answers from the Mattel Magic 8-Ball.
We will now start to add the actual Core Bluetooth code to our SDK; replacing the mock code that we have in there.
This will result in a short “dark age.” We won’t be able to do much more than syntax-check until there’s enough code in place –on both ends of the connection– to enable an actual running example.
All the work that we’ve done until now has been to reduce the duration of the “dark age,” and make sure that it can be tested as soon as possible.
Testing is life. My philosophy is that I test at every possible opportunity, and periods of coding without being able to run and step through the code really bother me.
An important part of setting up a Bluetooth system, is registering unique GATT IDs for our Service and Characteristics.
“GATT” is an acronym for “Generic ATTribute profile.” It is defined here. There are a number of “predetermined” types of services, and we can add to them.
In order to actually instantiate Core Bluetooth managers, we need to make sure that our apps are ready for it.
There’s an important info.plist key that needs to be set, and, for the Mac, we also need to check a box.
We are now ready to start actually implementing the Bluetooth code.
Apple’s Core Bluetooth SDK uses the concept of “Managers” to implement Bluetooth capabilities for Central and Peripheral devices.
If we will be running the device as a Bluetooth Central, then we will instantiate CBCentralManager. If we will be running as a Peripheral, then we instantiate CBPeripheralManager. An instance of one these will be associated with each of the SDK instances that we create, and we will be managing these “under the radar.” The user of the SDK will not have any idea these are being used.
Now that we have the Central and Peripheral devices finding each other, we need to start “filling in the blanks.”
That begins in the Peripheral, where we will create an instance of the Core Bluetooth Service, and populate it with the two Characteristics we chose.
One thing that we’ll learn about Core Bluetooth (which can also apply to other types of asynchronous communication), is that nothing is really direct or straightforward.
That means that we can’t just ask a CBCentralManager instance for its CBPeripherals. We need to ask the manager to discover the Peripherals, and, possibly, build up its own list; which we can then query.
The same goes for Services. We can’t just ask a CBPeripheral object for its CBService instances. We have to ask it to discover its Services.
After that, each Service needs to discover its Characteristics. That said, just to add insult to injury, we don’t ask the Service to discover its Characteristics; we ask the Peripheral to do so, on behalf of the Service.
Once the Characteristics have been discovered, then we can finally aggregate the Peripheral device.
We did just enough on the Peripheral side to give the Central something to find.
The Central, however, has its work cut out for it…
In this entry, we will walk through the code that we needed to add to the SDK/Central Mode to discover and register devices.