[MUSIC PLAYING]
MICHAEL STILLWELL: Hi, I'm Michael Stillwell,
and in the next seven or so minutes,
I'm going to take you through some of the ways
to test Wear 3 health and fitness
apps without breaking a sweat.
So imagine it's your job to test a scenario like this-- start
tracking a run, run up a hill, run down a hill,
and then after 30 minutes, stop running.
Not so straightforward, is it?
You get sweaty.
It takes a lot of time.
It's not easily repeatable.
And taking bug reports and screenshots while running
is a pain.
And how do you check the UI remains smooth while
in the middle of a run?
There's also a few other reasons testing
is difficult for apps like this.
Compared to phones, watches have more input types.
So there's a screen, but also, around 10 sensors.
But not all watches have the same collection of sensors.
And even if they do, they can have different capabilities.
So for example, some watches can automatically pause an exercise
if it looks like you've stopped moving, but others don't.
Also, there's some variation in how frequently
data is delivered to the app.
So even if data is being recorded continuously,
it will typically be delivered in batches.
And the size and timing of the batches
will vary from one device to another.
One final difficulty is that there's
a few unusual states and transitions
the watch can make that are difficult to produce,
such as your app losing permissions.
So there's two broad options for simulating different activities
on different devices.
You can use an emulator, or you can use an ADB-powered command
line API.
The emulator works just like the phone emulator
and is especially useful for testing
UI on different screen sizes.
You can also pair an emulated watch
to a physical phone or even an emulated phone.
The other approach is to use Health Services synthetic mode,
and this works with both emulated and real devices.
So here's a quick tour of the emulator.
It's accessed via the Device Manager
panel in Android Studio.
And you can use it to provide fake or simulated heart
rate sensor data.
The emulator is also useful for testing
how your app works on different screen sizes
and shapes, including shapes that are not
available on physical devices.
Another thing you'll probably want to do at some point
is pair the emulated device to a real phone
to get a Google account onto the device,
and this process has got a lot easier
over the last few months.
Next up, synthetic mode.
So the emulator can only generate fake events
for the heart rate sensor.
However, synthetic mode simulates the behavior
of multiple sensors at the same time.
To get this working, pick an exercise type
and tell Health Services to simulate that exercise.
Health Services will generate synthetic exercise data
across multiple sensors.
To communicate with the Health Services Library,
you need to have ADB configured.
You may have set this up already,
but let's just quickly go through your options
since it's different to how you might do it on a phone.
Since watches don't have data cables, for Wear 3 devices,
the only other option is Wi-Fi.
This works pretty much as you'd expect,
although some devices consume a lot of power
with Wi-Fi debugging turned on.
So remember to turn it off when you're finished.
If you're on a network that isolates clients
from each other, I recommend setting up
a Wi-Fi hotspot on your phone and connecting
both your computer and your watch to your phone.
This will allow your computer to communicate with your watch
without being blocked.
So now you have ADB set up.
Here's how to simulate an exercise.
First, enable synthetic providers.
Then, tell it what exercise to simulate.
As soon as you issue the command,
Health Services will generate realistic but fake sensor data
for you to use to test your app.
And remember to revert to the sensor providers
when you're done.
Different devices have different capabilities.
This can affect both features, such as whether auto pause is
available or not, and also, the data
types you get back, such as where the elevation is
delivered when tracking a run.
It's very important that your app
checks for and correctly handles these differences
between devices.
Attempting to configure a device to do
something it doesn't support can cause your app to crash.
So here's some sample code showing how to safely create
an exercise config.
Note the set intersection operation
that ensures only data types that are supported
by the device are requested.
Another common source of bugs is not
handling some of the more unusual Health Services states
properly.
So typically, as your app records an exercise,
the service transitions through a few different states,
from preparing to active to stopped.
However, there are several unusual states
that are not frequently encountered that your app must
still be able to handle.
You should verify your app handles these states correctly
by, for example, manually removing permissions or opening
another app and starting recording there
while your app is still running.
Wear health and fitness apps typically
have far fewer screens and functions than phone apps.
They're usually pretty simple.
However, they're often used in situations
where users expect things to just work
where they don't have the time or patience to investigate
glitches.
So it's important that app quality is high,
and one of the best ways to achieve this
is to thoroughly test your apps.
So don't skimp on testing because it
seems like physical exercise is needed.
As I hope this talk has shown, there's
a lot of things you can test without doing
physical exercise.
Finally, keep checking the docs to see
if new features have been added to the tooling
to make testing even easier.
Thanks for watching.
[MUSIC PLAYING]