AnDevCon just rolled through San Francisco, and what a fun show. We heard about KitKat from Reto Meier, developer relations tech lead at Google. While KitKat is a point release, Google packed a lot of developer goodness into it. From a Bluetooth® technology point of view, the most interesting thing is Google baked in the GATT-based HID profile support into the platform, along with Message Access Profile (MAP). While MAP should make things easier on the auto front, HID support will be great for many input devices (keyboards, mice, styluses, etc.). This should open up some doors for appcessory vendors out there.

The conference was interesting, and there was a mini Bluetooth track consisting of three sessions.

• I presented a session on appcessories, and how GAP/GATT/ATT were important to understand from a developer’s point of view
• Dave Smith presented a session entitled, “Talk to Your Toaster, Part I: Bluetooth in Your Application” which really went over the code in Android apps
• Dario Laverde presented a session on wearables and introduced the concept of this exciting new space to developers

One of the topics that can be confusing to developers new to Bluetooth is central/peripheral versus client/server, and I spent a fair amount of time in my session going over the differences.

In a nutshell:

• Central vs. Peripheral – This applies to the Bluetooth connection itself. The device, which acts as the peripheral, advertises itself. The device in the central role scans for these advertisements, and determines which devices it wants to connect to.
• Server vs. Client – This determines how the two devices talk to each other once they’ve established the connection.

Here’s the example I use. You have a Bluetooth Smart device, which is your peripheral, and a smartphone, which is your central. The Bluetooth Smart device advertises, the smartphone scans and initiates the connection. In 90% of the scenarios, the smartphone also acts as the client, consuming data from the server.

This is often a source of confusion when talking to Android devs, as they can have a central that runs as a server but cannot run the Android phone in peripheral mode. What this really means is the Android device can’t advertise, but it can still act as a server.But, in SOME cases, you may actually want the Bluetooth Smart device to be the client. Think of an instance where the Bluetooth Smart device, which is a peripheral, wants to consume data from an app on the smartphone.  In this case, it may make sense for the smartphone to act as the server (to serve up the data) and the Bluetooth Smart device to act as the client (consuming the data). Again, it all depends on the use cases, but it might be feasible.

I hope this cleared up some confusion for those of you who are new to Bluetooth development…if not, I hope you at least liked the pictures from the event!

As always, let me know what you are working on at DevFeedback@bluetooth.com. I always love to hear from you! Don’t forget to get your solution highlighted in the Developer Showcase or the App of the Month by emailing us a short description of your solution to devAOM@bluetooth.com.

(Credit: Steve Hegenderfer)