Breakout Session: Android Wear 2.0

Lot of new devices available.  Lot of OEMs getting involved in Wear -- including high-end brands like Tag Heuer (no idea if that's spelled right... sorry all...)

Watchface complications:
"Complication" is something on the watch face that tells end-user something *other* than the time.  We've learned users really like complications and like the ability to customize what's included in them.  In the past, everything had to be handled by the wear developers for complications.  Now the API is adding new tools to accelerate this piece (e.g. TextRenderer (handles text and size) and ComplicationDrawable (handles placement and location) rather than having the wear OS developer create all the containers, text, placement, etc.)

Android Wear App Design:
Now there are guidelines for when to use what features.  For example, if you have only a few functions you may want to use an App Launcher instance (this is what swipes right to left) rather than using the Settings Drawer (scrollable list).

Developer Feedback:
Past 1.5 years Google has sent surveys to get feedback from developers.  Added examples to developer guide, along with a few other options.

Android O updates for Wear.  Play store for Wear as part of Wear 2.0.  The Play Developer Console houses Wear apps just like phone apps.  This will also be backwards ported to Wear 1.x

What's new in Android O?  Notifications are huge (since this is a BIG use case for wear users).  Now developers can house notifications into a single channel which will allow them to exhibit the same notification type (e.g. vibration, sound, etc.).  This is all configurable from the Android Wear phone app for end users.  Only a few lines of code to implement:

Another big feature is layout and sizing for texts.  Now there's a way to do this seamlessly by utilizing the TextView object.  Wear will automatically resize as necessary based on the form factor of the device.  Developers no longer need to worry about resizing (*note: this can be overridden if more customization is desired)

Background execution best practices for battery and usability.

Battery optimization.  What drains battery?

-Display - 3 use cases in power draw (screen off, screen on, and screen on and interactive)

We want to keep the display off whenever possible.  How do we do this?  Keep use cases simple - let users get in and out.  Also, leverage ambient display and dark themes (all-white display can use up to 7x power when compared to dark themes).  Animations are very expensive for battery draw.  Here's the comparison between animations vs. the other use cases (the screen off, screen on, etc.).  Even though animations are short they are VERY costly:

Here's an example of something Google has done to decrease the wear spinner.  Smaller spinner and less redrawing.  Another example - sweeping seconds hand vs. ticking seconds hand.

Avoid background synching.  When user is not using app there should be no reason for synching (unless watch needs to notify user of something).  We recommend batching data to do this as infrequently as possible using the JobScheduler API.  Here's an example of batching data vs not in terms of battery cost:

For large data transfers, always use WiFi or cellular.  Bluetooth is more costly.  Here's an example for two cases (1mb and 100mb transfer over different radios).

Other expensive features - make sure you use these sparingly because they're very expensive!

Battery Historian for Android Wear (same tool as available for Android) is a great tool for identifying battery issues and troubleshooting.

Here's the recap: