This is part 3 of a 4 part series where we explore the challenges of making wearable apps, by building an Android wear watch face with real-time weather data. In Part 1, we provided an overview and created our first watch face. In Part 2 we took a deeper dive into the watch face. In this part we explore the Wearable Communication APIs and build the real-time weather communication component of our app. Finally, in Part 4, we show how to package and publish a watch face app.

Wearable APIs

A key thing to note about wearable devices is that they do not connect directly to the internet. A mobile phone or device must be paired with a wearable. Furthermore, once paired, they can only transfer data only via the Wearable APIs.

Edit: This may be changing soon with wifi available directly on wearable devices see google announcement.

There are three wearable APIs:

Node API : for detecting devices connect or disconnect.

Message API : for sending messages to another device.

Data API: for storing and retrieving data from a device.

As with other Google APIs, we need to use the GoogleApiClient class in order to use Wearable APIs. Figure 1 shows how wearable & mobile apps work with the GoogleApiClient and the wearable APIs.

TIP: If your app also use one of the other API components (such as Google+, Games, or Drive), remember to use a separate instance of GoogleApiClient for the Wearable API, as the connect call will fail unless the Android Wear App has also been installed on the device. For more information, see here.

Once the GoogleApiClient is connected, add listener for each of the Wearable APIs:

Message Api

MessageApi is similar to a Message Queue, you can send messages into a queue and GoogleApiClient will deliver the messages to the other device, but unlike some other message queue technologies, there is no persistence. A active connection is needed between both the wearable and the phone. If the connections is lost, GoogleApiClient doesn’t keep the messages.The following example shows how to send and receive a message containing weather data via Wearable.MessageApi.

WARNING: When you update data via PutDataMapRequest, be sure to include all the attributes as update replaces all items with the new map, instead of updating individual properties.

When the data has been saved successfully, the path to access it again will look like the following

wear://<NodeId>/<path> //the path is given when you call PutDataMapRequest.create()

You can’t assign the node Id. DataApi uses the local node id when you call Wearable.DataApi.putDataItem() either on a wear or handheld. If you want to access the data, you have to use this path to access it:

Note also, the data for an app is isolated by it’s package name, let’s says you install another app, you cannot use DataApi get to the data from a different app, even if it shares the same path.

Wearable Listener Service

You can use WearableListenerService to listen Wearable APIs’ events when a device boots (either Wear or Handheld). This feature is the same as you add listeners on the wearable app example which is inside of WatchFaceService, but the benefit of using WearableListenerService is that it runs on background independently. Let’s say you are using a watch face called A, and you open the config Activity on a phone of another watch face called B. Your config changes will lost because watch face B isn’t active so it can’t receive any message. Therefore, if we add a WearableListenerService, you can get all messages although a watch face isn’t active.With the following example, we will use this class on a phone app and listen a message(a require) from a wear. When WearableListenerService on a phone app get the message, it will call weather API to get current weather data and send the data to the wear.Step 1: Create a WeatherService class which extends WearableListenerService

Performance Considerations

We considered several approaches for communication between our wearable and handheld apps. The goal here was to preserve battery while providing up to date weather data.The approaches we tried included:

A service that always runs on the phone with regular weather updates and pushes them to the watch face. This is not ideal as the service runs constantly though the wearable device may not even be paired.

Next we tried enabling the service only when a wearable device is connected. i.e. When a wear is paired, get weather information and push it to the wearable device. This, however, meant that the service is running, even if our watch face is not selected. Here the handheld app may send data but there is no receiver.

Finally, we moved the trigger for updating the weather data to the watch face. The timer runs on the watch face (we use the same timer for redrawing). If the weather information is stale, it sends a message to the handheld. The service on the handheld receives the message and gets the latest weather information and updates it on the wearable. Using this approach, the service only runs when the watch face is in use, and the weather data is kept up to date!

Figure 2: Weather Data Communication

Configuration Activity

A configuration activity to manage watch face attributes such as color, time format etc can exist on either the wearable or on the phone. The implementation of the activity is exactly like a regular activity, so we don’t cover this in detail, the source code is here. We will focus on how to set up the connection between a watch face and it’s configuration activity via AndroidManifest.xml.

After you deploy the apps, navigate to the change watch face screen, if the watch face has the config activity, a gear icon appears below the watch face on the wearable. On a phone, open the Android Wear app, a settings gear appears as well as a menu option is added for “Settings”. see Figure 4.

Figure 4: The config gear and menu on a wearable and on the android wear app.

Sending and receiving the watch face configuration data is similar to how we sent and received weather data, so we don’t duplicate the same code here, you can refer the example above.

Storing data for multiple wearables

We want each wearable device to have its own configuration settings. Let’s say one watch face has a blue background and another has an orange background. In this case, we can’t just use DataApi to save the data on a phone because when we save the data, as it will use the phone’s ID for identification. We want custom settings for each watch face. So we used the following approach:

Use MessageApi to send a ‘setting changed’ message to the wearable from the phone.

When the wearable receives the message, use the DataApi on the wearable to save the data. Now, the DataApi will use the wearable’s ID to save the info and each wearable can use it’s own ID to map to it’s own settings.

Figure 5: Managing data for multiple devices.

Congratulations! Now the only step left is to publish your watch face on the Google Play Store. We’ll cover this in Part 4 of this series.

Share

GET CURATED TECH NEWS WEEKLY

Recommended Posts

10

October

Android Fragment Animations – Transition and Animation As a digital consulting company we deem it important to give back to the community and continue to publish open source software on our GitHub page, ...Read More >

26

March

Tutorial: Building an Android Wear Watch Face, Part 2 : The Watch Interface This is part 2 of a 4 part series where we explore the challenges of making wearable apps, by building an Android wear watch face ...Read More >

04

May

Hacking together mobile apps using Twitter data store At SWARM, an app design and development company in New York, we love to run experiments and try new things. Some of our experiments like ...Read More >