By Mikhail Mikhailov and Yevgeny Nagibin, Android Developers at Rosberry
Most often, developing mobile applications, we build them for only two types of devices — smartphones and tablets. And every time we start a new Android Studio project we come across the proposed templates for other types of devices. Unless necessary, developers wouldn’t use those templates especially if there are no corresponding physical devices at hand. But the situation may change when it is required so by the app development project itself. The time is now to tell about the mobile app project we’ve been busy with at Rosberry.
The app is all about a healthy lifestyle and is a tool for tracking water balance and managing liquid intake based on the environment, user activities and other individual measurements. Using the app daily, one can develop healthy habits replenishing water loss in a timely manner. To make this experience even more friendly we’ve built an app for watches powered by Wear OS by Google.
The actual task was to build a wearable app within a short period of time and make it as simple as possible. So, the basic issues we had to face first were: Wear OS capabilities, the way the Wear OS app would interact with the phone app and the component interdependencies inside the project. In this article we would like to share some development aspects for Wear OS we had to take into consideration down the road.
Development of a wearable app suggests that we add a separate module to the existing project.
To do so, we should proceed as follows:
Step 1. Add a new module to an existing project.
Step 2. Add dependencies
In the newly created module named ‘Wear’ we should update the dependencies section to include the following:
This way we’re adding the Wearable Support Library to our watch module.
Step 3. General classes for the phone app and smartwatch app modules
Since we are using one and the same code base between the modules of the phone application and the smartwatch app, we’re adding a common module which is added to the project as a library. To use this module we should declare the following dependencies of the phone and watch app modules:
Step 4. Linking the phone and smartwatch app module
To link the watch module to the existing project we should declare the following dependencies in the build.gradle of the phone app module:
To create a wearable application we use the same components as for smartphone apps with only several exceptions: your Activity may extend WearableActivity — a special class which allows for setting the behaviour of the display when idle. The setAmbientEnabled() method, which is called for in the extended Activity when it is created, allows for switching to ambient mode instead of blocking the watch display.
Interaction between devices is ensured by the special component — Wearable Listener Service which has a special priority in the system.
To add the component you should:
How it actually looks:
When the application is unloaded from memory, the WearableListenerService will continue and will accumulate the data coming to the callback which will be delivered to the destination at the next active state of the application.
In order to get the data in the callbacks one should register as a data client and a capability client in the smartwatch module using the following methods:
and implement the callbacks themselves
To check the status of the smartwatch pairing with the smartphone you’ll need to take a couple of steps.
First up, we shall set the strings with random entries in the the wear.xml file of the phone application module for the smartwatch to be able to check if the device with such Capabilities is paired. Wear content.xml looks like this:
Then in the smartwatch module itself we shall set a string constant with the same entry as in the capability indicated above. With the help of this constant in the callback onCapabilityChanged()of the smartwatch module we will determine if the state we receive relates to the state of our device (connected to our phone app). After verifying that we’ve received the pairing status of the appropriate device, we shall be busy with the following check-up:
The result of this check-up will show whether there is an actual connection with the device. It should be noted that we cannot request the pairing status directly, only through the callback, which implies some delay between the actual disconnection of the device and the callback trigger.
To transfer data from your smartphone to your smartwatch and vice versa you should use the bundle com.google.android.gms.wearable.DataMap which is created simultaneously with the Karl À College Sweat Capuche Noir Kani com.google.android.gms.wearable.PutDataMapRequest, calling a static method PutDataMapRequest#create, which should have one of the paths declared in the manifest as an input:
To add all necessary data to the DataMap bundle you can use a range of methods. For example, to send the current timestamp with a query you should call the following method:
Then comes the chain of transformations of our request into a task (com.google.android.gms.tasks.Task) — the end point before processing of our data by the Google services library.
For our request to be processed and could reach the paired device, it is necessary to:
2. get DataClient:
3. pass our request to DataClient and finally get the Task:
4. Task execution is carried out with the await static method of the Tasks class:
The Task execution is blocked until the result is obtained synchronously. This operation must be performed in a separate thread.
Usually the data for the watch is not delivered immediately, in order to optimize the use of resources and save battery life it is time-lagged and the lag as the documents say is 30 minutes. To instantly deliver the data for the watch you must use the setUrgent()method for the PutDataRequest class object which ensures that there is a minimum delay between sending and receiving data.
As described above, the data is received through the Karl À College Sweat Capuche Noir Kani WearableListenerService#onDataChanged callback which gets the DataEventBuffer object as an input after the execution of each task and which should be parsed using the keys that we have defined in the application manifest. It looks like this:
On receipt of the “/drinkEvent” we parse it using the keys of the dictionary.
The devices pair with each other via Bluetooth, so the offline operation of the smartwatch means that there is no pairing between the smartphone and the watch. If the task is sent to be carried out with no pairing, its execution will not take long when connection is there again. Thus, working with the smartwatch in an offline mode, all scheduled tasks will be performed and the data on both devices will be synchronized.
Developing applications for smartwatches one should borne in mind that they come in different shapes and sizes with circular and square faces. Moreover certain watches might also have an inset called chin which is usually located at the bottom of the display. To determine the resource only for circular face watches, you should add -round or not-round to those directories that you want to override.
We used BoxInsetLayout to create the screen layouts — it allows to place the content in the center of the display of the circular face watch — the content will be sized to fit into the round display (Fig. 1). This effect is achieved by using the app:boxedEdges=”all” attribute (you can also use left, top, right and Karl À College Sweat Capuche Noir Kani bottomvalues to size to only fit into a specific side).
To support a chinned smartwatch, one should add the fitsSystemWindows=true attribute which will raise the markup above the chin so that it would not be overlapped (Fig.2).
Figure 1 — UI screen for the circular and rectangular face watches
Figure 2-UI for the circular face with an inset (chin)
To hand over the builds to the client we used Beta by Fabric. Unfortunately Beta is available for smartphones only, so it is not possible to install it onto your watch. The only way to get the build on the watch was to directly install it or use Google Play beta testing.
As you see, the situation has not improved in 2019.
Our smartwatch app is for Wear OS 1 version.x and 2.x thus, Wearable API lets us exclude the smartwatch APK from the app APK and release two separate APKs to Google Play. One should remember that APK versions should be unique. Google suggests that we follow the the below approach to app versioning:
To distribute the app on Google Play, as we know, it is necessary to prepare a signed build of the application. Building the release version of the smartphone APK in our case we should also build the watch APK, which at the end of the process can be found in the directory /build/outputs/apk/
It is worth noting that you can submit your wearable app for review for Google to qualify it as a Wear OS app. To do this in the developer console, you need to:
In this article we have tried to cover all the aspects that might turn important to developers of wearable apps, especially to those who are just starting out with Wear OS. We very much hope that the points outlined here will facilitate your acquaintance with this operating system. Our experience has shown that development for Wear OS is not much different from the development of smartphone applications. However, developing Wear OS apps you should remember about the guidelines, since, for example, the navigation inside smartwatch apps is somewhat different from the usual one in the apps for “larger” devices. Check out the following link to learn more about the guidelines — design guidelines.
Karl À College Sweat Capuche Noir Kani Written by