Android Wear 2.0: Making Watch Apps more Standalone – Google I/O 2016

Android Wear 2.0: Making Watch Apps more Standalone – Google I/O 2016


KENNY STOLTZ: Hey everybody. Really glad that you
could join us here today. I’m Kenny Stoltz. I’m a product manager on Wear. And I lead product for some
of the standalone and iOS features. GRIFF HAZEN: And
I’m Griff Hazen. I’m a software
engineer and tech lead for Wear’s Developer Platform. KENNY STOLTZ: So both of us have
been working on Android Wear since before 1.0. And today, we’re
going to take you through a couple of
the things that you’ll want to consider when you’re
designing and building standalone apps in Wear 2.0. OK. So first, a question. Why would you build
a standalone app? There are three reasons. And the first is
the most obvious. Sometimes, you just don’t
have your phone with you. Running is an obvious
use case where you might want not to have some
phone strapped to your wrist. And a bunch of other fitness
scenarios are similar. But standalone offers
the opportunity to free you from your phone
in a lot of other situations that you might find yourself
in throughout the day. So if you run to the store,
and you forget your phone. If you’re doing chores
around the house, and you don’t want to
have it in your pocket. If your phone dies, etc. Standalone will
let you still use that small screen on your
watch between the times when you’ve got
your phone with you. Second that building
standalone apps is a lot more like
building mobile apps. It’s particularly faster
and easier to build them if you already have an
existing mobile app. So you’ll spend
less time rewriting the basic infrastructure
for your app, which means that you can spend more
time making your app better on wearables. The last reason is
that standalone apps will work on watches connected
to both Android and iOS devices. So you want to make
your app as– you want to offer your app to
as many people as possible. And if you follow
the design patterns that we’ll share
with you, you can write one wearable app
that will work on watches connected to both devices. OK. So now we’ll go through
a couple of things that you’ll want to consider
before you start coding. So first of all, what
should a standalone app do? The easiest way to
start is to think about what your phone app does
and then distill that down. So think about what the most
important tasks that your app allows the user to accomplish. And then what flows
are absolutely necessary for the user
to go through, in order to accomplish those tasks. Now, you want to think a
little bit about your user and how they’ll
be using your app. They’re likely to be on the go. So you don’t want to hold
their attention for too long. And you want to make
sure that you’re making it fast and easy
to complete those tasks. Keep in mind, that
you don’t want to let the user get
halfway through a task, and then ask them to switch
from the watch to the phone. First of all, obviously,
they might not have their phone with them. And second of all, they
might get frustrated or lose their place. So you want to try to support
every flow that you can from end to end on just the wearable. That said, your user often has
two awesome devices with them at the same time. So it’s great to make
the two work in harmony and have appropriate and
useful content on each screen. The data layer APIs that we
released with Android Wear 1.0 will continue to work. And you can use those to
build multI-screen experiences with Android phones. Finally, you want to
consider both types of phone that your user might have
while they’re using your app. So Wear 2.0 Developer
Preview will allow you to pair with an iOS phone. Once you’ve paired
with the phone, you can sideload your app onto
the watch, and then test it. There are performance
differences, particularly the amount of bandwidth
that you’ll have. So you really should test. And it’s a great way to
make sure that you’ve got a standalone app. GRIFF HAZEN: If you’re
already familiar with how to architect an
Android phone app, you’ll be glad to learn
that Wear apps can now be written in a very similar way. Sure, the user
interface may need to be scoped down to
the most important user flows and the
limited real estate, but the underlying
code and services can be written in the same way
and even shared between phone and Wear apps. You can access the
cloud in the same way, use similar
authentication methods, and the same cloud
to device messaging. Let’s dig in to
a few areas where we are providing additional
help for standalone apps. We’ll also go through
some Android APIs you may be familiar
with on the phone, and how they can be
applicable and useful in Wear. First off, well take a
look at how standalone Wear apps can communicate with
cloud services and store data. One of the most important
platform changes to enable standalone
apps is the expansion of direct network access. Wear apps will now be able
to communicate directly with cloud services,
and can also schedule background work
that requires network access. When the phone is
connected over Bluetooth, network traffic proxies through
the phone’s connections. When the watch is
outside of phone range, Wi-Fi and cellular
networks are used, depending on hardware support. The Wear platform takes
care of the transitioning between networks. In existing wearable apps,
data stored in the cloud was often relayed to the
wearable via an Android phone– via an Android app on the
phone, using data items in the wearable data layer APIs. The wearable data
layer is still useful when coordinating
between watch and phone. But with standalone,
it may be simpler to go directly to the
cloud for many use cases. In addition to
simplicity, it also works when the phone
is not available, or when paired to an iOS device. When talking to the cloud,
you can use protocols that you’re already familiar
with like HTTP, TCP, or UDP. Once your data is fetched,
you can store it locally on the device,
just like on phones using shared preferences,
SQLite, or internal storage. If your Android phone app is
well maintained and tested, you may be better off starting
from your existing code base, and cutting things out
as opposed to starting from scratch. Common code and services, like
your networking data model and business logic, can be
shared between your phone app and Wear app, using
a shared library. Form factors, specific
code, and resources can remain in separate build
flavors for phone and Wear. This type of structure is
already supported natively in Android Studio and Gradle. When fetching data
from the cloud, it’s important to fetch only
the data that your wearable app will need. Otherwise, you may introduce
latency, memory use, or battery use unnecessarily. In some cases, for example, when
over a Bluetooth LE connection, your app may have access
to just 10 kilobytes per second of bandwidth. We recommend auditing your
network traffic, both requests and responses, for extra
data that perhaps is only intended for phones. Shrinking large
images server-side before sending them
to the wearable is another great way to
reduce network traffic. In Android, background
services are a powerful tool but should be used wisely in
order to preserve battery life. In Android 6.0,
Doze and App Standby resulted in significant
improvements to battery life by allowing devices to
enter a deep sleep when idle or stationary. Doze has been extended in
Android and in Android Wear 2.0 to enable some lighter
optimizations whenever the screen is in low power,
ambient mode, or off. Here’s an overview of
the new Doze lifecycle. After the screen turns
off or enters ambient mode for long enough, lightweight
Doze can kick in. During Doze,
background tasks may be deferred to execute during
periodic maintenance windows. If the device later becomes
stationary for long enough, a deeper Doze mode kicks in,
similar to Doze in Android 6.0. To ensure your background
tasks are executed as desired, it’s important to write
them in a Doze-safe manner. The JobScheduler
API allows an app to register for
Doze-save code execution, and is recommended
for background work. Various constraints
can be selected when scheduling
jobs, for example, the need for connectivity,
device charging, or periodic execution. It’s important to
be conservative when scheduling jobs,
and to avoid execution in ways that could adversely
impact battery life. Job scheduled with
the JobScheduler API use the JobInfo Builder
object to provide constraints and metadata. We’ll go on for a few useful
constraints that are available. To request networking, use the
setRequiredNetworkType method, and specify any or unmetered. NETWORK_TYPE_UNMETERED
is an appropriate choice for large data transfers. While NETWORK_TYPE_ANY is
more appropriate for smaller transfers. Note that in Wear 2.0, some
low bandwidth networks like, Bluetooth LE, are considered
unmetered– sorry– considered metered. To schedule a task that
requires the device to be on the charger, use the
setRequiresCharging method, or to be currently
idle, by calling the setRequiresDeviceIdle
method. Using both of these
together can be useful for lower
priority background work or synchronization. Here’s an example of
a job being scheduled that requires
unmetered networking at the time the job is run
in addition to the device being on the charger. JobScheduler will
activate MyJobService when both of these
constraints are met. The Builder method
setExtras can be used to provide additional metadata. This bundle will be passed
to the job when executed. Note the MY_JOB_ID value
passed to the JobInfo.Builder constructor. This is an application-specific
identifier. Subsequent calls to cancel
jobs or create a new job with the same job ID will
update the existing job. Here is an implementation
of a JobService to handle the job from
the previous slide. When the job executes,
the onStartJob method is called with the
JobParameters object passed in. The JobParameters object
allows you to get the job ID and also any extras
bundle provided when scheduling the job. The onStartJob method is called
on the main application thread. So therefore, if any expensive
logic needs to be run, it should be pushed
to a separate thread. In this example, an
async task is used to run code in the background. Once your work is completed,
call the jobFinished method to notify JobScheduler
that the task is done. KENNY STOLTZ: OK. So now we’ll go over a
couple of different options that you have for
authentication. The reason that
you need to start thinking about authenticating
is that now your app is running entirely on the wearable. So whenever it makes a request
for the cloud on behalf of the user, it’s going to need
to have a valid auth token that shows that web
service that it has access to that private data. But before you rush to
ask the user to login, please consider what you can
do with an anonymous user. You want to try to
avoid authentication where it’s not necessary. And if you need to
record data, you should try to record it
locally, instead of writing it to the cloud by
default. You have to remember that
the user might not have access to the
network at the time when your app is running. Finally, when you do need
to authenticate the user, you want to focus on the
fastest and easiest methods from the user’s perspective. So the simplest way, from
a developer perspective, is the same as on the phone. You can create a login activity. And you can ask the user to type
in their username and password. Now this activity is
a normal activity, and if it has an input
field with the inputType textPassword, then Wear 2.0 will
show a special password style keyboard that will
allow the user to type in their password on the watch. Now, this keyboard is
optimized for the watch, but it is still
very small, so you should try to keep from having
to show that keyboard where you can. A couple of ways that you
can do that which are better and avoid that typing are to
use our sign in technologies, like Google Sign-in or
Smart Lock for Passwords. So both of those technologies
use the existing authentication that the user already
has to Google, and exchange that
for a token that’s valid for your web service. Smart Lock for
Passwords, in particular, is very simple to add to
your existing client app. It only requires
client-side changes. And it works with
existing users, who’ve already registered using
whatever IDP they’re using. So both of these options
will be available in some future
developer previews that we’ll be releasing
throughout the summer. So please keep an eye on it. So if you’re familiar with
writing Wear on the data layer, you might have already
thought of one way that you can get a
token over to the watch. That’s to request that
token on the phone, and then pass it over to the
watch via the data layer. So this method
has some benefits. It’s fast and easy for the user,
but it may have some problems if your off provider doesn’t
like the fact that you’re requesting a token for the watch
on the phone, so a token that’s destined for a different device. It also does require the user
to have their phone with them and have it on and connected
when they’re running your app. And finally, it
doesn’t work on iOS. So if you do choose to use
this method in your app, make sure that you have
at least one backup method that does work. So one final method
that we’ll also be bringing to a future
developer preview is the ability to open
an OAuth URL on a phone. So this OAuth URL points to
an OAuth 2.0 authentication service. The user will then
switch to their phone, follow through the
OAuth login flow. And then when they
complete, the auth service will return a token destined
for the wearable, which is sent via a call
back to the same call that you used to open that URL. So this option will
work on iOS, but it does require the user to have
their phone with them when they need to log in. So there are a lot
of options here. So here’s a quick table
showing some of the tradeoffs. As you can see, Google Sign-in
and Smart Lock for Passwords both work if the watch is
connected or disconnected from the phone, and they
work on iOS and Android, and they’re fast and
easy for the user. The middle two options
both require the user to have their phone with them. And the final option is
a good fallback option if all else fails. If you follow along
with the previews, we’ll be sharing these methods
throughout the preview cycle. And that will help
you to build apps that are as fast and easy
to log onto as possible. GRIFF HAZEN: A third area of
focus for standalone Wear apps is how to retrieve
notification from the cloud, either for display to
the user or as data for your wearable app to use. Google Cloud
Messaging, now known as Firebase Cloud Messaging or
FCM, is now supported by Wear. FCM allows you to push data
and notifications directly to Wear devices from the cloud. Example uses include delivering
sync tickles, small data payloads, and user
visible notification. It works well with Doze
and is cross-platform. The same reasons to use
the service on phones apply to standalone Wear apps. It’s the recommended way
to push events to watches. To send messages
using FCM, first collect your registration token
when your wearable app runs, and include it as
a destination when posting messages to the FCM
rest endpoint from your server. Those messages will then be
delivered to that device. FCM messages can include
two types of payloads. Here’s an example
of a JSON formatted a message that will deliver
a user-visible notification directly to the stream when
received by a Wear device. When the user taps
this notification, your app is launched. The second type of
payload is a data payload with a set of
custom key value pairs. You can include both of
these types of payloads in the same message, as well. Where FCM is for notifications
from cloud to device, we’ll now talk a little bit
about Android Notifications. One of the most useful
features of a Wear device is the ability to see your
phone notifications bridged to the wrist. With standalone Wear
apps, both phone and watch may receive a
similar cloud event and decide independently
to display a notification for that content. This may result in
duplicate notifications showing in the stream. One for the Wear-side
notification and one for the phone-side notification. You can stop a notification
from bridging phone-side using the setLocal.only API,
but that would also prevent it from displaying on Wear
devices that don’t have your wearable app installed. Therefore, we’re
introducing a new API to disable notification bridging
only when the Wear app is installed on the device. By adding the notification
bridge mode metadata element to your
Wear app’s manifest and setting it to no
bridging, phone notifications will be ignored
and not displayed in the watch when
your app is present. Another API we’re adding for
end notifications is the ability to link a phone-side and
the Wear-side notification together, so they
dismiss at the same time, even if they were
posted independently. This is useful if the content
is for the same topic. The new API,
setDismissalId, allows you to tag notifications
on both watch and phone as dismissing together. This API is now available
in the Wearable Extender class in Android N’s
Preview Support Library. You can see how to
add a dismissal ID string to a notification here. If you’re add on
watch and phone each post a notification with
the same dismissal ID, and the user dismisses
either one of them, the other will
dismiss automatically. A fourth area of focus
for standalone Wear apps is how to get them
installed and distributed. And we have some exciting
changes coming in Wear 2.0. In Wear 2.0, Wear apps
are downloaded directly to devices from Play Store. You no longer need to bundle
them inside of your phone app. We are expanding the
multi-APK feature of Google Play Developer
Console to support Wear. Multi-APK allows you to
publish separate APKs for your application
for different device configurations. You’ll now be able to
have one or more phone, tablet, Wear, or other APKs
in your Play Store listing at the same time. This change brings with
it a number of benefits, including smaller phone APKs,
a decoupled release process, where your phone
app and Wear app can be updated
independently, support for per-application APKs, when
using the– per-architecture APKs when using native
libraries, and more. To give you a taste for how
multi-APK support will work for Wear, here’s an
Android manifest file for a typical wearable app. It includes a
uses-feature element set to hardware type watch. Because of this
feature restrict, APKs built from this manifest
will target only Wear devices in Google Play. Similarly, APKs built
without this restrict will not target Wear devices. Wear device targeting
can be combined with other criteria, such as
SDK version, screen resolution, and CPU architecture. Let’s walk through
an example of how this may work in Google
Play Developer Console. Say you’ve built both a
phone APK and a wearable APK for your application
in Android Studio. You then go to the Google
Play Developer Console to upload both of
them, one at a time. You’ll need to select
Advanced Mode in order to have more than one APK
in your application at once. After uploading the
wearable APK first, we’d expect the list
of Supported Devices for this application to
be just watch devices. And by clicking the
Supported Devices link, you’d be able to verify that
only watch devices are shown. Now you upload the phone
APK to Developer Console. The set of Supported
Devices for this app has now increased to over
2000 and includes phones. You’ll also notice, at
the bottom of the screen, there are two APKs listed: one
for watch and one for phone. The watch entry shows the
feature restrict being present. Multi-APK a support requires
that you use a unique version code for each upload APK. In this example,
the wearable APK was set to version code
two, while the phone APK used version code one. Since Wear 1.0, Android
Studio and Gradle have provided a very simple
way to automatically bundle Wear APKs inside of
phone APKs, as shown. You can turn this bundling
off by removing the Wear app project dependency
from your phone apps Gradle file while
testing standalone apps. Multi-APK support for
Wear 2.0 is coming soon, and we’ll have
more announcements on this over the summer. For now, simply sideload
your application, your standalone
Wear app, directly to your device for testing. Now I’ll hand it over to Kenny
to show you a couple examples. KENNY STOLTZ: OK. So let’s put together
all the principles that we just talked
about and see what it will be like to make
standalone apps in Wear 2.0. We’ll start with a chat app. And For this example, I’ll
assume a couple of things. I’ll assume that you’ve already
got an existing Android phone app. You are at production
quality, and you’re public, and you have a
fairly big user base. OK. So going from the top, key
use cases are pretty obvious. The key use cases are
going to be sent a chat, receive a chat, basically. So that’s going to require a
bunch of different activities: log in, list of friends,
chat settings, etc. But because we’re really trying
to streamline interactions, you want to make sure that
every UI that you build is in service of
those key use cases. OK. So now let’s talk about how
we’re going to build it. We’ve already got a phone
project in Android Studio. So we’re going to create a
second flavor of our build. So this new flavor is going
to be our wearable build. And it will start out
the same as the phone. But we’ll factor out the shared
code between the two builds. And we’ll build a shared library
that both of those will use. So the first thing
that we’ll put into that will be our entire
REST client service that we had built for the phone, so that
both are wearable and phone are now able to
talk to the cloud. So on top of that
REST client, we’re going to build some activities. Now, we’re going to use
material design for Wear and I’ll just hand
wave through that, because the next
talk in this room, at 3:00, is about
material design for Wear. So now we have a wearable app
that uses those material design principles and can talk to
a web service on the watch. So we’re already pretty far
along in building an app. But this app is not always
going to be in the foreground. Messaging is really
driven by notifications. So the next thing that we’re
going to add to our app is we’re going to
register it for FCM. So once we register
for the FCM, we’re going to start
getting pings from FCM whenever we need to
show a notification. Because we’re now
getting pings, we’ll disable bridging
so that we don’t get bridge notifications from
the phone at the same time. When we show a
notification, we’ll use the new messaging style
for a notification, which will show a really nice
presentation for that message on the user’s watch. Now when the user taps
that reply button, we’ll use a content
intent, which will allow us to start
a reply activity that’s custom-designed for our app
and meets our exact needs. OK. So we’re going to have to
make this user sign in. There is no– well, we could
make an anonymous chat, but we won’t. That means we’re going to start
with a basic sign-in activity. So we’re going to have
a username and password as our two blank boxes. But then we’re going to add
some fast sign-in features. So I’m going to assume here
that I already had an existing OAuth web service. And since I have
that, Smart Lock is a really good option,
because it integrates well with an existing auth service. Another option that I
can add is OAuth URL, which will allow me to log
in via a couple of changes that I’ll have to
make to my web flow. So now let’s start
thinking about how to make this app work
really well when you’ve got your phone. We’re going to
coordinate dismissal by sending a notification ID
inside the FCM payload for each of our messages from FCM. And then we’ll
add that dismissal ID– sorry– we’ll add the
notification ID as a dismissal ID to both the phone and
the watch notifications. So then, when I swipe away
a notification on one, it will swipe away on both. So now we have a great
wearable chat app. It works well with the phone. But we really need to
test it on all the watches we can get our
hands on connected to both types of device. You really have to make sure
that your app is working well on both Android and
iOS connected watches. And then the next
thing that you really want to do when you
have an existing app is to profile your REST services. So probably in this app,
what we’re looking for is data that’s not being
used on the wearable. And there are a couple
of options we have if we find big chunks of
data that aren’t actually being shown to the user. One is that we can cut it
out entirely if it’s not being used on the phone either. Or we can make new
requests and responses that are specific
to the wearable app. So sort of cutting
out that data, and only showing the wearable
what it needs to know When we’re ready to distribute,
make an unbundled wearable APK, set up the manifest as Griff
described and upload to Play. So now we’ve built a
pretty easy chat app based on our existing phone app,
and it works great in Wear 2.0. OK. Go to another example
now– a fitness app. So everybody has their favorite
running and cycling app. And those are all
pretty horizontal. So a new idea might
be to go vertical. So I’m going to make
rock climbing app. And this is a new idea, so
we’ll start from scratch, with no existing phone app,
no existing web service. So since we’re
starting from scratch, we’ll really be thinking
about the wearable first, how people are
going to use a wearable to track climbing, what
kind of information they might want to
see on their watch. So I’m going to assume here that
there is some black box sensor magic that somebody is
going to build in order to make this work,
because I’m a PM, and that means that
I don’t have to code. So thank you, engineers. But what we do want to
make sure is happening is that, when we’re
processing sensor data, that were as battery-efficient
as we possibly can be. Because whenever
you’re processing data, the processor has to stay awake,
and that is burning battery. So what we really
don’t want to have is the user gets halfway
up that rock wall, and then their watch dies. So once we process
all the data, we’re going to store it locally
in a SQLite database, in case the user isn’t currently
connected to the network. Now, we’re going to
build some new activities with material design for Wear. We’re going to support
Always On, which is something that we release last year
and allows apps to keep running in the foreground
when the watch goes into ambient mode. So if you want to find
out more about that, you can to still check
out last year’s talk on YouTube about Always On
apps, and those principles will still work in Wear 2.0. So at this point, we
have a wearable app that’s storing data locally, and
it’s a cool app for climbers. What we might want to
do next with the app is start storing
that data in Fit. Now, Fit can give us a
lot of interesting stuff. We can get biometric
data from the user, like their height
and their weight and other data that
they’ve entered. And we can also write
into the Fit platform, our rock climbing
sessions, so that the user can see all of their
fitness data in one place. And I can verify that
Fit has an activity type for rock climbing. So we’re already
halfway there, easily. So far, our app is a
generic, anonymous app, but if you’re not a
generic lumberjack, and you’re a climber Jane,
you want the user to log in, so that you’ll be
able to identify that user in the future, and
also bring that user online onto the cloud. So our app can offer
a good amount of value without a login, so we’re
going to make login optional, and defer it to when the
user wants to log in. And when we do ask
the user to log in, we use fast sign-in flows,
such as Google Sign-in, which is easy because, if I’m
starting out from scratch, I don’t have an auth
service, I probably don’t want to deal with all the
requirements of figuring out how to do an auth service. So I can just let Google
do that hard work. OK. So now we’re logged in. That means that we can
write data to the cloud. What you want to
remember here is that, although watches
can run standalone apps, not every watch
has cellular, which means that not every watch
is going to be continuously connected to the cloud. So whenever you’re writing
data to those two sources locally and remotely, you
want to think about a sync. So you want to make sure
that they’re eventually consistent on both the
local store and the cloud. So this diagram is
getting pretty busy here. But let’s say we want
to throw the phone in. And how do we tie the
phone into the party? OK. Now, I think there’s a
pretty easy first step. This is, again, my
PM speak– I think there’s a pretty easy first
step, which is basically just to do everything that we
just did on the wearable, but now, since the wearable’s
writing all this data to the cloud, we
just need to write the same thing on the left on
the right, and then we’re done. Right? We have a phone app that can
now read and– see everything that happened on the wearable. But what would be
even cooler is if I could hand my phone to my
belayer while I’m on the wall, and my phone could stream
real time data from my watch down to my phone, and my
belayer could be checking out how my progress is going. So if I wanted to do that, I
would use the Data Layer APIs, and particularly here,
probably the messaging API is a good choice, because
it’s very low latency. OK. So as before, test. Test on iOS, test on Android,
profile– so there’s probably less to do on the web
services side here, since we’re sort of
starting from scratch. There’s probably
not a lot of cruft sitting in the web services. But where you would
want to focus here is on how much processor
that you’re using. So make sure that
you’re not going to leave the
hanging– oh, well– that’s the first time
I tried that joke. Last, we’ll set up
an unbundled APK and upload it the Play
Developer Console as before. So those are just
two examples of how you’ll now start to build
standalone apps in Wear 2.0. So just to recap–
three easy things to remember about why you
want to build standalone apps. So first of all, standalone
is phone-independent. It allows you to free
yourself in any situation during the day from
the phone and still be able to use those
apps on your wrist. Next up, standalone apps
are built like phone apps. So they use phone
app architecture. And all of those skills that
you’ve learned and honed apply to the wearable apps
that you’re going to build. And finally, standalone apps
work with both Android and iOS phones. GRIFF HAZEN: If you like what
you heard today, and can’t wait to try it out, you can. Just go to g.co/wearpreview. You can find out about how to
get the preview SDK, device images, and more information
about the new APIs we’re launching. In addition to the
developer preview, we also have a
few other sessions that you should check out. The next session
in this very room is about how to build Wear
2.0 apps with material design. You can also catch up on YouTube
if you’ve missed anything. One of the main reasons we
are doing a developer preview is to get your feedback. So if you have any bugs
or API suggestions, please g.co/wearpreviewbug. We also have an Android Wear
Developers Google+ Community, where you can discuss
with your peers. The URL is g.com/androidweardev. And with that, let’s go to Q&A. [MUSIC PLAYING]

4 thoughts on “Android Wear 2.0: Making Watch Apps more Standalone – Google I/O 2016

Leave a Reply

Your email address will not be published. Required fields are marked *