Improving an SDK With Core Bluetooth

This entry is part 1 of 7 in the series Improving an SDK With Core Bluetooth

This series will pick up where the last series left off. It should be fairly quick, relatively.

If we do a recap of our conclusion, we were left with the following list of “TODOs”:

  1. 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.
  2. 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.
  3. 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.
  4. It would be nice to know whether or not the question made it to the Peripheral.
    At the moment, we have the .writeWithoutResponse property 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.
  5. 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.
  6. 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.
  7. 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.
  8. The App is Pathetic
    Yeah…It’s just enough to show that the SDK works. We can do better.
  9. 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.”

Read more

Writing an SDK With Core Bluetooth – 20 – Conclusion

This entry is part 24 of 24 in the series Writing an SDK With Core Bluetooth

We now have a complete, operational SDK and application.

Here is Our Ending Repo Tag.

This application demonstrates Bluetooth on all the current Apple platforms, from one codebase: Mac OS X, iPhone/iPod, iPad, Watch, and TV.

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.

Read more

Writing an SDK With Core Bluetooth – 17 – Asking Questions

This entry is part 21 of 24 in the series Writing an SDK With Core Bluetooth

We are now ready to have the Central Mode ask a question to one of its Magic 8-Balls.

After we are done with this step, we will be able to run an instance of the app as a Central (on a Mac, iPhone/iPad/iPod, Watch or TV), and an instance of the app as a Peripheral (on a Mac or iPhone/iPad/iPod).

The Central will discover the Peripheral, and display its name in the list. The user will then be able to select the Peripheral, and “ask it a question.”

The Peripheral device will almost immediately display the question.

Read more

Writing an SDK With Core Bluetooth – 15 – The Center

This entry is part 19 of 24 in the series Writing an SDK With Core Bluetooth

THIS IS NOT STRAIGHTFORWARD –NOT EVEN A LITTLE

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…

Read more

Writing an SDK With Core Bluetooth – 13 – Managers

This entry is part 17 of 24 in the series Writing an SDK With Core Bluetooth

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.

Read more