This entry is part 1 of 1 in the series Classic Core Bluetooth
We’ve actually already done most of the work for this item, but let’s see if there’s anything more we can do (at this point).
Remember that one of our current restrictions is to have no changes in the apps, themselves, so anything that we do has to be in the
SDK-src directory. At this point, the
Apps-src directory is still at the same version it was when we started (Tag itcb-09).
Everything that we’ve done, to this point, has been in the SDK.
This was a relatively short exercise, compared to the first series, and we made all of the changes inside the
Before we dive in, let’s take a bit of time to review how Core Bluetooth handles communications between Centrals and Peripherals.
One thing that we can do, is make sure that the Peripheral actually gets our question. Right now, we simply rely on the fact that we sent it to confirm its receipt.
We would like to wait until the Peripheral actually tells us that it received the question before we assume that it has been sent.
THIS AIN’T GONNA HAPPEN
The goal of this exercise is to have the Peripheral (the “Magic 8-Ball” device) respond immediately, and completely randomly, to questions asked by the Central; without presenting a list of questions to the user of the Peripheral Mode app.
This series will pick up where the last series left off. It should be a fairly quick series.
If we do a recap of our conclusion, we were left with the following list of “TODOs”:
- The error handling is primitive, at best.
We didn’t really do much to capture errors. We have the ability in the apps to catch and display them, but we didn’t take advantage of this in the SDK.
This was mostly because I wanted to keep the lesson as simple and to-the-point as possible. If it were a “shipping” SDK, error handling would have been one of my first priorities.
- The Central “locks up” Peripherals.
Because we connect, then hold the connection, a Peripheral is dedicated to a Central. It might be nice to allow a Peripheral to be used by multiple Centrals.
- We could put the entire Peripheral functionality inside the SDK.
We could remove the ability to select a response, thus pretty much obviating the need for user intervention. It could be entirely possible to simply do the response automatically in the SDK, and report the results to the Peripheral user.
- It would be nice to know whether or not the question made it to the Peripheral.
At the moment, we have the
.writeWithoutResponseproperty set on the question, so we aren’t sure that the question made it to the Peripheral. We can ask the Peripheral to let us know if the question made it.
- This barely scratches the surface of Bluetooth Programming.
Agreed. The purpose of this series (so far) has been to introduce Core Bluetooth. I expect to be exploring Bluetooth programming much further, and will use this SDK as the vehicle for that.
- The iOS app doesn’t clean up after itself very well.
The Mac app closes all resource connections when it quits, but the iOS app can “hold the connection open.” That’s really something that would require work on the apps, as well as the SDK.
- We’re Not Sure Who’s Asking the Question.
It would be nice to have a label on the Peripheral screen that showed who was asking the question.
- The App is Pathetic
Yeah…It’s just enough to show that the SDK works. We can do better.
- We could explore Bluetooth “Classic” (BR/EDR) with this project.
We’re using BLE for this, and it’s really the perfect type of task for BLE, but this would also be something that could be done with Bluetooth “Classic.”
We now have a complete, operational SDK and application.
This codebase is compiled into four targets; native Swift-based frameworks that are focused on one (or more) of the above platforms. Currently, the functionality is as barely simple as possible. It just scratches the surface of Core Bluetooth, but does demonstrate a complete system, from a Peripheral, advertising Services, to a Central, scanning for Services, and connecting to Peripherals, in order to use those Services to communicate with the Peripheral.
At this point, the Peripheral is getting the question. Time to answer it.