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.
In the next series of posts, I will walk through designing and implementing a very simple SDK (Software Development Kit), using Apple’s Core Bluetooth API.
Core Bluetooth is Apple’s method for interacting with Bluetooth devices; in particular, with devices that use Bluetooth Low Energy (BLE).
In the latest versions of Apple’s operating systems, Core Bluetooth will also support “Bluetooth Classic.”
Every Apple device, including Macs, Watches, iPhones, iPads, iPods, and TVs, will support our code, if we use Core Bluetooth.
It’s possible that the new support for Bluetooth Classic in Core Bluetooth will allow us to also use “classic” Bluetooth on our devices.
In this initial series, I’ll just cover BLE, but I also want to explore BT Classic, using Core Bluetooth, in future series.
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).
One of the biggest issues that I have with many SDKs, is that they slavishly model the system they are representing. This is often not the most optimal way to present functionality to the user.
Bluetooth is a highly flexible system. It is used by millions of devices that each may have a very different dynamic from other devices, and Bluetooth needs to serve them all, so it is rather complex and flexible. Core Bluetooth does a relatively good job of simplifying the standard, but it is still fairly byzantine.
I like to start with the user; ask them what they want, and then make the SDK an interpreter between them and the interface. Hide that Bluetooth complexity, and boil it down to the basics for the user.
Now, it’s time for us to make some fundamental decisions about the SDK we’ll be designing.
For example, the app will have two distinct states: Peripheral and Central. Should these be reflected as a single API, with a set state, or should we actually provide two APIs, with the app loading the appropriate one for the state?
At this point, we should review the behavior of the apps, determine what we think will be going on between the devices (in Bluetooth), and decide the structure of our exposed API.
We should start by mapping out a transaction diagram of messages and data.
I just wanted to make it clear that the approach, and the resulting structure that we will develop, is based upon my own personal experience and viewpoint. There are definitely other ways to do this; some, a bit simpler.
But I have been writing SDKs since the 1980s, and I think that my point of view “has legs,” so to speak.
Remember that I will be providing the code to do all this. The lesson is on Bluetooth; not app development. I just wanted to make sure that we all understand the user experience for the apps.
The design that we’ll use for our app will be a “Magic 8-Ball.” This is a fairly classic app for teaching, and we’ll be able to apply it to our little Bluetooth system.
This explanation will barely scratch the surface of BLE, but it should give us enough information to understand what we are doing in the next few entries.