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.
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:
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.
In the Android Wear application I implemented the DataApi.DataListener interface and handled data synchronization events in the on Data Changed method.
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.
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.
In the smartphone application, the MessageApi.MessageListener interface receives messages via calls to its on Message Received method.
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.
Martin is on the Bluetooth Developer Relations team. He specializes in mobile applications and technology, with over 30 years of experience in software development.