APP DESIGN
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.
As stated in the prerequisites, the apps will be provided complete, so we won’t be needing to understand things like views, windows, UI elements, etc. Our work will concentrate in a few source files that will be “faceless.” -More on that, later.
HOW IT WORKS
Anyone “of a certain age” will remember The Mattel Magic 8-Ball.
This was a “divination” toy that had a 20-sided polyhedron (an “Icosahedron,” if we want to be pedantic) inside a liquid-filled globe, shaped to mimic a large pool ball #8.
The way the toy works, is that we ask it a “yes/no” question, shake the ball, then turn it upside-down.
On the bottom, is a round window, and one of the sides of the dice will float up, to display any of 20 answers.
THE AVAILABLE ANSWERS
- It is certain.
- It is decidedly so.
- Without a doubt.
- Yes – definitely.
- You may rely on it.
- As I see it, yes.
- Most likely.
- Outlook good.
- Yes.
- Signs point to yes.
- Reply hazy, try again.
- Ask again later.
- Better not tell you now.
- Cannot predict now.
- Concentrate and ask again.
- Don’t count on it.
- My reply is no.
- My sources say no.
- Outlook not so good.
- Very doubtful.
HOW WE’LL DO IT
What we will do, is have the Bluetooth “Central” be the “asker,” and the “Peripherals” be the “8-Balls.”
The connection between them will be BLE. We will write one app that can be run as either a Central or a Peripheral (for Macs and iOS, but only as a Central for Watch and TV).
They will share a common Unique UUID, that we will generate, and that will describe a Service that will provide a bidirectional pair of Characteristics. One will be an “ask,” and the other will be an “answer.”
There will only be one Central, and multiple Peripherals. Each peripheral will advertise its Service. The Central will not advertise.
When the app goes into Central mode, it will start scanning automatically, and will “hold” connections to the Peripherals.
Connections will take over the Peripheral on behalf of the Central, and will remain until one of the apps is quit.
Asking A Question
The Central will allow us to type in a question (every platform except the Watch), or select a random question (Watch).
This will be sent to a selected Peripheral (the Central will be able to list and connect to multiple Peripherals).
The Peripheral will display the question, and allow its operator to:
- Manually choose (and send) from one of 20 answers, or
- Allow the app to randomly pick and send an answer (one of the 20).
Since the Watch display is so small, we won’t get into having the user be able to write a question, and will, instead, have a number of pre-written questions, one of which, will be randomly selected and sent (NOTE: The Watch can only act as a “Central.”).
When the Central receives the answer from the Peripheral, it will display it to the user.
Under the Hood
The Peripherals will advertise an “8-Ball Answer” Service, with a “Question” Characteristic, and an “Answer” Characteristic. That means that we’ll only need to deal with a single Service, which will be “sourced” from the Peripheral, and will be bidirectional. The Central will get the “8-Ball Answer” Service from the Peripheral, and set its “Question” Characteristic, which will notify the Peripheral that its “8-Ball Answer” Service has a new “Question” Characteristic value.
The Peripheral will then set the “Answer” Characteristic of the “8-Ball Answer” Service, and notify the Central that the answer is ready. The Central will then re-read the Service, and provide the “Answer” Characteristic value to the user.
Now that we know what we will do, let’s set up some wireframes.