Wearable technology is taking off and taking various forms, from watches to activity trackers to smart wigs (no, I didn’t just make that last one up!) And Bluetooth® Smart is right at the centre of the action. This is the second part of a series of articles on the Android Wear operating system and an exploration of the way developers can exploit it to deliver application experiences right to the user’s wrist (or ear or head or neck etc!). Part 1 looked at the use of standard and extended Android notifications as the basis for creating a user experience on Android Wear. In this part I’ll discuss an equivalent application which runs on the wearable device itself.

Android Wear Applications

Given how much we can do with extended notifications, you might wonder why you’d want to develop an application which actually runs on the wearable, so let’s consider that question first. By developing an Android Wear application we have much more control over the user interface and are able to create custom UI layouts in much the same way as we do for a smartphone user interface. In addition, communication between devices is bidirectional; the wearable can send messages and data to the smartphone and vice versa. An Android Wear application can work completely on its own and independently of a smartphone application, but you should keep in mind the comment I made in Part 1 about the relative power of smartphones vs. wearables and the advantage of utilising the more powerful smartphone for resource-hungry operations. Continuously scanning for beacons is relatively resource-intensive so I decided my smartphone application would take on that responsibility. On detecting a beacon it would transmit information about the associated museum exhibit to the Android Wear application on the smartwatch so that details could be displayed to the user.

Android Wear APIs

The key Android Wear APIs are provided by the Google Play Services library and include the following, all of which I used in my wearable museum guide application:


This API automatically synchronizes data items across all nodes (the Android Wear term for connected devices) in the Android Wear network, which in the case of my museum guide application means my smartphone and my smartwatch. You create Data Item objects, usually via a class called Put Data Request and specify a unique path with which to identify the type of data on nodes which receive it through the synchronization process. A call to Wearable.DataApi.putDataItem is all it takes to hand the data to the API for synchronization. Nodes implement the Data Listener interface in order to receive synchronized data via the on Data Changed method.


The Message Api allows you to send byte array payloads from one node to another. It’s often used as a kind of Remote Procedure Call (RPC) mechanism. The Capability API is used to find a node which will understand and be able to process a message of a given type. A call to Wearable.MessageApi.sendMessage sends the message across the Bluetooth connection where the receiving node, having implemented the Message Listener interface, will get a call to its on Message Received method.


Applications can register capabilities—the ability to handle certain types of messages—in a resource file called wear.xml. Capabilities are identified by a string value which you, the developer, invent and reference via the Capability API. Here’s the wear.xml file for my museum guide smartphone application by way of an example.

Figure 1 – Declaring Capabilities in Wear

This API, as you’d expect, provides access to and information about connected nodes in the Wear Network. You’ll see examples of all of these APIs in use further on in this article.

The Android Wear Museum Guide UI

I wanted a multi-page, interactive UI similar to the one I created using extended notifications in Part 1. The Grid View Pager class formed an ideal basis. With a museum exhibit nearby, I wanted there to be three pages in total: an application title page, an exhibit name page with a Like feedback button and a final exhibit information page. Screen shots from the finished application look like this:

Figure 2 – Screen Shots from the Finished Application

I also decided that if the smartphone application indicates that there are no beacons nearby, then the wearable application should show the title page only and navigation to the exhibit information pages should not be possible. If a beacon is detected by the smartphone application, it should send a photo and key details to the wearable application and the exhibit information pages should become available, with the first of them being shown to the user immediately.

Sending Exhibit Information to the Wearable

I used the Data Layer API to transfer images and information about museum exhibits from the smartphone to the wearable device. On the sending side (the smartphone application) an Asset object was used to form a container for an image and then the PutDataMapRequest class was used to create a composite data synchronization object containing the image and textual information I wanted to send to the wearable. The Google Play Wearable Data Api was then used to initiate synchronisation with my smartwatch. Note the inclusion of a time stamp in the data Put Data Request. This is necessary because the Data Api caches data and will not transfer data if it thinks it has not changed since the last synchronization event.

Figure 3 – Smartphone App Using the Data Layer API to Send Data to the Wearable

In the Android Wear application I implemented the DataApi.DataListener interface and handled data synchronization events in the on Data Changed method.

Figure 5 – Using the Capability API

Handling the Like Button

I wanted my wearable application to inform the smartphone application whenever the Like button was pressed by the user and used the Message API to accomplish this. I also used the Capability API to ensure the smartphone node was selected as the target for the message.

Figure 5 – Using the Capability API

When the Like button was pressed by the user, I sent a message containing a path which means “Handle this as a Like Button Pressed Event” and a payload containing the name of the exhibit being “liked” from the wearable application to the smartphone application.

Figure 6 – Sending a Message from Wearable to Smartphone with the Message API

In the smartphone application, the MessageApi.MessageListener interface receives messages via calls to its on Message Received method.

Figure 7 – Smartphone Application Receiving Messages from the Wearable Application


And that’s it! Android Wear is great to work with and has excellent APIs and Bluetooth® Smart provides an excellent, low power wireless transport for communication between nodes in the Wear Network.


How to Do Stuff with Bluetooth® Technology

Got a robot dog you want to remote control? You came to the right…

An Introduction to the Bluetooth LE Security Study Guide

My house has locking doors and windows, an alarm system, and several security cameras.…

Why Bluetooth Technology is the Developer’s Swiss Army Knife

Members of the Bluetooth® community are continuously innovating. Over the last two decades, members have…

Updates to the Bluetooth Internet Gateway Study Guide

According to the ABI report Installed Base of IoT Devices by Connectivity Technology, published…

In Case You Missed It: What’s New With Blue This Summer

The Bluetooth® developer community is always pushing the technology forward, and this summer has…

New Core Specification v5.3 Feature Enhancements

One of the key reasons why Bluetooth® technology has emerged as the global wireless…

Bluetooth® Core Specification Version 5.3 Feature Enhancements

Bluetooth® Core Specification version 5.3 includes several feature enhancements with the potential to improve…

Connect: Car Access Demo

In this demo, Texas Instruments will discuss and demonstrate Bluetooth 5.1 and its cutting…

Wireless Connectivity Options for IoT Applications - Commercial Lighting

Industry 4.0 is no longer a thing of the future. The term describes the…

Designing and Developing Bluetooth® Internet Gateways

Learn about Bluetooth internet gateways, how to make them secure and scalable, and design and implement your own working prototype gateway and web application for use with either Bluetooth LE Peripherals or with Bluetooth mesh networks.

An Introduction to Bluetooth Low Energy for Swift Developers

All smartphones support Bluetooth® Low Energy (LE) and it is used in all manner…

Building a Sensor-Driven Lighting Control System Based on Bluetooth® Mesh

A technical examination of which Bluetooth mesh models to use in different types of…

How Bluetooth Low Energy Works: 21 Interesting Facts

Whether you’re a beginner or an expert in Bluetooth Low Energy development, it’s always…

How to Deploy BlueZ on a Raspberry Pi Board as a Bluetooth Mesh Provisioner

This step-by-step study guide will teach you: How to rebuild the kernel on a…

The Bluetooth LE Security Study Guide

Learn about fundamental security concepts, the security features of Bluetooth Low Energy, and gain some hands-on experience using those features in device code.

How Bluetooth 5 Increases the Achievable Range of a Bluetooth Low Energy Connection

Texas Instruments offers their theory on how to achieve long range with a Bluetooth…

Testing Long Range (Coded PHY) with Nordic Solution (It Simply Works)

There has been a lot of discussion and confusion about testing the long range…

 Get Help