2.0 launched back in February with added support for new hardware features
in addition to adopting new
Design themes,
g
and a simpler vertical UI pattern. It also introduces a
API, making it easier for apps to provide data to watch faces, and watch
faces to incorporate external data. The final big update was that, apps
targeting Wear 2.0 now have the ability to operate in a
mode, without needing a connection to a companion app on the phone.
There are a few design considerations in relation to navigation, notifications,
the complications API, and the standalone functionality to help you better
optimize for Wear 2.0 devices:
Navigation
- Use the
a drawer">WearableDrawerLayout navigation drawer for simple and infrequent
navigation: Simple navigation includes tasks such as accessing app
settings, switching users or logging out. You can implement
this on Wear 2.0 to switch between different views or sections of the app via a
swipe down from the top of the screen, or an action drawer can be set up for
context-specific actions when swiping up from the bottom of the screen. - Present a navigation drawer as a single-page drawer to enable users
to navigate views quickly: A navigation drawer can be presented as
either a multi-page or single-page drawer. The single-page layout is useful for
when the user is expected to navigate quickly between 7 or less views of the
app. Remember that if the app is using a single-page drawer, the iconography
should be clear and understandable as there will not be any sort of text
labeling in this layout. If there are more than 7 views to navigate to or the
views are not easily represented by icons, you should instead use the multi-page
drawer layout.
- Use multiple app launchers if your app has two or three discrete
functions: For example, if your app supports
both activity tracking—with various options, actions,
and views—and historical analysis and management of tracked activities, you can
use multiple app launchers to handle these tasks. Alternatively, if your app has
a simple home screen, these features could be placed in line, at the bottom of
the screen. - Use peeking at the top of the action drawer to provide quick access
to the primary action: If there is no primary action associated with
the view, override the default behavior and force an overflow button to peek
instead, exposing all actions at the bottom of a view, when tapped.
Ensure that for devices using Wear 2.0, your app takes advantage of these new UI
patterns to provide a consistent user experience. Check out more training
resources for
Navigation and Actions and the Material Design specifications for
and
Drawers.
Notifications
Wear 2.0 uses a simpler vertical navigation pattern, removing the horizontal
swiping gesture to present actions for a notification. Notification actions are
now presented as a single primary action (if applicable) at the bottom of a
notification. If there is no primary action, expanding the notification will
present options in a single, vertically scrollable view.
Notifications will work without needing many changes on both 1.x and 2.0
devices, but appear quite different:
When creating apps for Wear 2.0 devices, improve the user experience with
notifications by applying the following best practices:
- Support expandable notifications: Use
so that users can see more content on their watch. - Use the collapsed view of the notification (if applicable):
Add the primary action for your notification to the collapsed view of the
notification using setContentIntent(), where appropriate. - For messaging apps, use the
Provide a rich chat app-like experience in the expanded notification using this
style. - Update user directions which are specific to Wear 1.0:
Remove any text guiding users to act on a card by swiping horizontally
(the Wear 1.x pattern). - Enhancing notifications to use inline actions: This allows
users to do things without needing tap to see the expanded notification details.
Actions for messaging notifications can use several different input methods
including Smart Reply presets, voice, and keyboard input. Take advantage of
these features to provide added functionality and delight users.
To learn more about
wearable features to notifications.
Complications
The complications API in Wear 2.0 makes it much easier for watch face developers
and third-party data providers to surface important information users want, at a
glance. Watch faces that support the API can be configured to use any of the
data providers that have been installed on the watch while maintaining complete
control over their appearance. Apps supporting the complication API allow the
app's data to be accessible on any watch faces that support complications. These
complications can be displayed in a variety of forms (short text, icon, ranged
value, long text, small image, and large image) depending on what the data
provider has configured and how much space has been allocated on the watch face.
To ensure that complications fit the overall design of the watch face and
properly handle their data type, when adding complication support we recommend
watch face makers should:
- Use the
class found in the Wear 2.0 SDK: This allows the text within
complications to be adjusted to their bounds by shrinking the text, dynamically
supporting line breaks or ellipsizing strings when they exceed the bounds of a
text-based complication. - Use the
class to set the background color, shape, border, and font options for the
complications: This gives complete control of how the complication is
rendered to the watch face. - Design the watch face to provide a way for users to configure or
adjust complications on the watch face through a settings menu: To
learn how to construct these settings see the
on GitHub. - Use the data provider
suite app to feed dummy data to the watch face complications: This
will enable you to verify that all of the complications render properly and have
fonts formatted for their bounds. - As a complication data provider, expose relevant data by using the
Simply define and configure what types of
the app can provide for complications.
Standalone functionality on Wear devices
- Make sure your app is able to handle itself if there is no companion
app installed when using the android.hardware.type.watch hardware feature
flag: Using this feature enables your app to become searchable and
installable directly on Wear devices without needing to install a companion
phone app, so ensure your app can handle itself to avoid a confusing or broken
user experience. - Ensure your wearable app doesn't rely on the phone app for
sign-in/authentication or primary functionality: When requiring
complicated input for authentication (for example, password entry) your wearable
app can point to the companion phone, but should rely on web UI for
account/password entry rather than an app. - Where a companion app must be present on a phone to support your app
in some other way, the app should use the
This should be used to properly direct users to the Play Store listing on their
companion device to install the missing app. Otherwise, the app should function
on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.
- Include wording about any companion app requirements or briefly
mention how your Wear app should function within the Play Store listing
description: This will help set expectations and guide users to install
the correct apps for the best possible experience. - Incorporate the
flag in the manifest if your Wearable app can function without any phone
companion interaction: This flag indicates that the wearable app can be
installed and will fully function when not paired to an Android or iOS companion
phone.
Though a lot was covered here, there are additional resources you can use to
ensure that your apps or games are optimized and use the latest patterns and
functionality on Wear. Be sure to
the quality guidelines and check out the developer training documentation to
learn more best practices for
development and
app design in order to build quality apps for Wear.
How useful did you find this blogpost?
0 comments