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.
INITIAL SEQUENCE
In the first timing diagram, we start with the user (as all user-centric apps do), who starts an instance of the app, and assigns it the Peripheral role.
Doing this, causes the device running the app to start advertising our “8-Ball Answer” Service via BLE.
The user then starts an instance of the app on a different device, and assigns that instance the Central role, which causes that device to start scanning for advertisements of our “8-Ball Answer” Service.
The Central device finds the advertisement, connects to the Peripheral, and reports the Peripheral back to the user. It should also gather information from the Peripheral, continuing to communicate, if necessary, and keeps the information cached.
ASKING A QUESTION
We assume that the Initial Sequence has caused the SDK to cache information about the Peripherals, so we can avoid having to go out over Bluetooth, and read more info.
When the user asks a Peripheral a question, they choose a Peripheral from the list of discovered Peripherals, and the “Ask Question” screen appears, focused on the selected Peripheral.
The user asks the question, and hits “SEND” (or equivalent, thereof).
The App Asks the SDK to update the “Ask” Characteristic of the “8-Ball Answer” Service with the question.
The SDK then asks Core Bluetooth to update the value in its own cached Service, which will result in the update to the Peripheral being sent via Bluetooth.
The Peripheral receives the update, and initiates a callback to the SDK, which parses the data, and performs a callback to the app.
The app presents the “Question Asked” screen to the user.
ANSWERING THE QUESTION
Once the Peripheral has received the question and notified the user, it waits for the user’s answer.
The user chooses an answer (it might be random), and hits “SEND.”
The App sends the text to the SDK, indicating that it be sent to the Central.
The SDK updates the Core Bluetooth Service Characteristic, which notifies Core Bluetooth that the Service update notification should go out.
The Central device gets the update through Bluetooth, and Core Bluetooth updates the SDK, with the new Service value.
The SDK then notifies the app that the answer has come in, and the app displays the answer to the user.
It’s pretty basic. Fairly straightforward and linear. Not too much chaos (always a factor, when designing device interface code).
We could make it even simpler, by automating the Peripheral (as opposed to having the user select an answer), but this is a teaching exercise, and it’s better if we see everything behind the curtain.
Now that we know what the action will be, let’s think about the exposed SDK API.