Chapter 11.  Advanced Features and Concepts

"Man is a genius when he is dreaming."                                               - Akira Kurosawa

In this chapter, we introduce the design concerns and API features related to making apps run as if they were always on. We develop an activity to demonstrate the always-on capability. We then touch upon debugging wear apps over Bluetooth connections and conclude with a preview of Android Wear 2.0.

Note

The code accompanying this chapter is available for reference on GitHub (https://github.com/siddii/mastering-android-wear/tree/master/Chapter_11). Note that for the sake of brevity, code snippets are only included as needed. The reader is encouraged to download the referenced code from GitHub and follow along as they progress through the chapter.

Keeping the watch running

You may recall our discussion of watch faces in the previous chapter wherein a watch face starts out running in interactive mode. As the screen times out, the watch face continues to run as the device goes into its power-saving ambient mode.

While this feature, meaning the watch face's always-on capability, is inherent to watch faces—we don't want our watch to slack off when we want the time—it is not necessarily inherent to all wearable apps. For instance, if we had our todo app or Step counter app active, it would only be a matter of time before the screen timed out and rendered the watch face. If we then wanted to return to our app, we would have to interact with our wearable device to snap it out of ambient mode and bring up our last used activity or app. We can imagine scenarios where this can be a source of user frustration.

Fortunately, if our devices are running Android version 5.1 or higher, we can harness the power of the Android Wear APIs to conserve power...

An always running step counter

Now, let's demonstrate everything we presented in the previous section in practice by augmenting our step counter from Chapter 7, Voice Interactions, Sensors, and Tracking, to be always on. Let's dive right in.

The Android manifest file

The first thing to do is to update the AndroidManifest.xml file and set up the StepCounterActivity class to have its launchMode set to singleInstance. This is necessary in order to update the screen more than once per minute in ambient mode. Not doing so will cause the AlarmManager class to launch an intent to open a new activity every time the alarm is triggered rather than reusing the same (already active) activity. Here is the snippet from the file:

<activity 
    android:name=".StepCounterActivity" 
    android:label="@string/daily_step_count_title" 
    android:launchMode="singleInstance" 
/> 

As soon as we launch our step counter, we see a colorful background image and a display showing the number of steps taken so...

Debugging wearable apps

An important and extremely useful tool available to developers is the ability to set up debugging for our wearable apps running on our wearable device. We have the ability to run debug commands from our development machine to troubleshoot our wearable apps and have any debug output from the wearable be sent over to the handheld, which in turn must be connected to the development machine. Some setup is required in order to accomplish this. The general connectivity between devices is as shown in the following diagram:

The greatest payoff here is that we don't need to run two separate USB connections from the development machine—one to the handheld and the other to the wearable device. Instead, we can deploy and debug code straight to the handheld device from the development machine using a Bluetooth connection. This becomes especially helpful when such troubleshooting needs to be performed repetitively during development. Without this feature, we would have to endure...

The way forward - reviewing Android Wear 2.0

Back when we began work on this book, Android Wear 2.0 was well past ideation and into design. The Android Wear preview API was still in the works, being scheduled for release about the time we rounded a corner taking us past the halfway point of our first draft. Although the 2.0 APIs are still being fleshed out and development is underway, interested developers can try it out as part of the Android Wear 2.0 developer preview edition of the API.

In this section, we are going to highlight some of the key new features being baked into the 2.0 APIs, with an eye on what we've seen in the previous chapters of this book.

Watch face complications

In our discussion of watch faces, we had advanced the idea of interactive watch faces whereby we made available limited user interaction with the watch face primarily through tap gestures. Android Wear 2.0 formalizes such additional display complexity into the idea of a complication. A complication is essentially...

Summary

We began this chapter with a discussion of how to keep our apps running when our wearable device goes into ambient mode. We then augmented our step counter activity using our Today app from Chapter 7, Voice Interaction, Sensors, and Tracking, to make it always on, thereby getting up close to the parts of the Android Wear API that let us enable ambient mode for our apps. We then concluded with a brief note on debugging wearable apps over Bluetooth before proving a sneak preview of Android Wear 2.0.