Vive La Vida Bluetooth

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.

Read more

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.

Read more

At this point, I will take a few entries to run through the basic design and setup of our Core Bluetooth lesson.

I’ll discuss the application example that we’ll use (a “Magic 8-Ball” app), and the general design of the sample apps that I’ll provide.

Read more

FIRST DRAFT OF THE PROTOCOLS FOR THE SDK

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.

Read more

INTRODUCTION

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.”

SUPPORTED ON ALL APPLE DEVICES

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.

Read more

MODELING THE SYSTEM

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).

Read more

WHAT DOES THE USER NEED?

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.

Read more

RUBBER, MEET ROAD. ROAD, MEET RUBBER

Now, it’s time for us to make some fundamental decisions about the SDK we’ll be designing.

STATE-HEAVY VS. STATE-LITE

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?

Read more

MAPPING OUT THE INTERACTION

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.

Read more

THIS REFLECTS MY PERSONAL PHILOSOPHY

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.

Read more