Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon

Using Android Wear 2.0

Save for later
  • 6 min read
  • 04 Apr 2017

article-image

As of this writing, Android Wear 2.0 was unveiled by Google a few weeks ago. Like most second iterations of software, this latest version of Android Wear adds various new features that make the platform easier to use and much more functional to its users. But what about its developers? Is there any critical change that developers should know about for the platform? Let's find out together.

One of the biggest additions to Android Wear 2.0 is the ability of apps to run on the watch without needing a companion app on the phone. Devices running Android Wear 2.0 will have their own Google Play Store app, as well as reliable internet from Wi-Fi or a cellular connection, allowing apps to be installed and operated without requiring a phone.

This feature, known as "Standalone App," is a big deal for developers. While it's not really complicated to implement said feature, we must now reevaluate about how to distribute our apps and whether our apps should work independently, or should they be embedded to a phone app like before.

So let's get into the meat of things. Right now Android Wear 2.0 supports the following types of apps:

- Standalone apps that do not require a phone app.

- Standalone apps that require a phone app.

- Non-Standalone apps that are embedded in a phone app.

In this case, "Standalone apps" means apps that are not included in a phone app and can be downloaded separately on the Play Store on the watch. After all, a standalone app may still require a phone app to function.

To distribute a standalone watch app, all we have to do is designate an app as standalone and upload the APK to the Google Play Developer Console. To designate an app as standalone, simply add the following metadata to the <application> section in the app manifest file.

<meta-data

   android_name="com.google.android.wearable.standalone"

   android_value="true"

/>

Do note that any app that has that metadata will be available to download on the watch Play Store, even if the value is set to false. Setting the value to false will simply limit the app to smart devices that have been paired to phones that have Play Store installed.

One more thing about Standalone Apps: They are not supported on Android Wear before 2.0.

So, to support all versions of Android Wear, we will have to provide both the Standalone and Non-Standalone APKs. Both of them need the same package name and must be uploaded under the same app, with the Standalone APK having a higher versionCode value so the Play Store will install that version when requested by a compatible device.

All right, with that settled, let's move on to another big addition introduced by Android Wear 2.0: the Complication API.

In case you're not familiar with the world of watchmaking. Complications are areas in a watch that show data other than the current time. In traditional watches, they can be a stopwatch or the current date. In smartwatches, they can be a battery indicator or a display for a number of unread emails. In short, complications are Android widgets for smart watches.

Unlike widgets on Android phones, however, the user interface that displays a complication data is not made by the same developer whose data was displayed. Android Wear 2.0 gives the responsibility of displaying the complication data to the watch face developer, so an app developer has no say on how his app data will look on the watch face.

Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at £16.99/month. Cancel anytime

To accommodate that Complication system, Android Wear provides a set of complication types that all watch faces have to be able to display, which are:

- Icon type

- Short Text display

- Long Text display

- Small Image type

- Large Image type

- Ranged Value type (value with minimum and maximum limit, like battery life)

Some complication types may have additional data that they can show. For example, the Short Text complication may also show an icon if the data provides an icon to show, and the Long Text complication can show a title text if that data was provided.

Okay, so now we know how the data is going to be displayed to the user. How then do we provide said data to the watch face? To do that, first we have to create a new Service class that inherits the ComplicationProviderService class. Then, on that class we just created, we override the function onComplicationUpdate() and provide the ComplicationManager object with data from our app like the following:

@Override

public void onComplicationUpdate(int complicationID, int type, ComplicationManager manager) {

   if (type == SHORT_TEXT) {

       ComplicationData data = new ComplicationData.Builder(SHORT_TEXT)

           .setShortText(dataShortText)

           .setIcon(appIconResource))

           .setTapAction(onTapIntent)

           .build();                       

       manager.updateComplicationDatra(complicationID, data);                  

   } else if (type == LONG_TEXT) {              

       ComplicationData data = new ComplicationData.Builder(.LONG_TEXT)

           .setLongTitle(dataTitle)

           .setLongText(dataLongText)

           .setIcon(appIconResource))

           .setTapAction(onTapIntent)

           .build();                                   

       manager.updateComplicationDatra(complicationID, data);                              

   }

}

As can be seen from the code above, we use ComplicationData.Builder to provide the correct data based on the requested Complication type. You may notice the setTapAction() function and wonder what it was for. Well, you may want the user seeing your data to be able to tap the Complication and do an action. Using the setTapAction() you will be able to provide an Intent that will be executed later when the complication was tapped.

One last thing to do is to register the service on the project manifest with a filter for android.support.wearable.complications.ACTION_COMPLICATION_UPDATE_REQUEST intent like the following:

<service

   android_name=".ComplicationProviderService"

   android_label=”ServiceLabel”

> 

   <intent-filter>

       <action android_name="android.support.wearable.complications.ACTION_COMPLICATION_UPDATE_REQUEST" />

   </intent-filter>

</service>

And that's it for all the biggest changes to Android Wear 2.0! For other additions and changes to this version of Android Wear like the new CurvedLayout, a new notification display, Rotary Input API, and more, you can read the official documentation.

About the author

Raka Mahesa is a game developer at Chocoarts (http://chocoarts.com/) who is interested in digital technology in general. Outside of work hours, he likes to work on his own projects, with Corridoom VR being his latest released game. Raka also regularly tweets as @legacy99.