\n<\/p>\n
![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEg9hPoEMQhoOUSubWVgO-U3FPA17XPYAfWC0TTYoNJu74a2hXCiWBrRM-jacwcSbAMh8smzUt_oh2lk1MpicWicpLKpB4nhPNVfOAv5-m9r1eIe_5ScQbRRuUDbNYnup4pa5z382RJpf_-VRWD1zd58Gi9AOm6ou5HAw7HBRBBFtqEGQ5zIuPJW76vUBSQ\/s1600\/watch-face-push.png\")
<\/p>\nPosted by Garan Jenkin \u2013 Developer Relations Engineer<\/em><\/p>\n This post is part of Wear OS Spotlight Week<\/a>. Today, we’re exploring the wonderful world of watch faces<\/b>.<\/i><\/p><\/blockquote>\n At Google I\/O \u201825 we launched Watch Face Push<\/a>, a new API aimed at enabling watch face marketplaces for watch and phone. Watch Face Push is now available to develop with and use on Wear OS 6 on devices such as the recently-launched Pixel Watch 4<\/a>.<\/p>\n In this blog post, we\u2019ll show how Watch Face Push (WFP) can be used in a whole host of other ways, including:<\/p>\n <\/p>\n The first example we\u2019ll focus on is building a watch face with an accompanying phone app. It can apply a color theme based on a photo taken on the phone – perfect for matching your watch face to your outfit! And it\u2019s perfect for demonstrating how Watch Face Push allows developers to bring dynamic data to the watch face.<\/p>\n Let\u2019s go through some of the main techniques which combine together to make this possible:<\/p>\n A powerful feature of Watch Face Push is the default watch face<\/a> feature. This allows the developer to provide a watch face that\u2019s installed onto the Wear OS device at the same time as the overall app. This watch face is bundled as an APK and placed in the assets<\/span> directory in the app.<\/p>\n The system checks for the presence of this APK as the app is being installed, and it checks for the validation<\/a> key in the app\u2019s manifest.<\/p>\n This enables you to deliver a single package that contains both the watch face and app components, whether that\u2019s a full Wear OS app, where the app is the primary focus, or app components such as complication providers, where the watch face is the primary focus.<\/p>\n In our project structure, we define two modules, wear<\/span> and watchface<\/span>. By using a unified versionCode<\/span> across both, we can keep the app and watch face versions in sync. We use Gradle<\/a> to build the watch face and generate the validation token. This makes it easy to treat the watch face and the app as part of the same project.<\/p>\n Now that we\u2019ve successfully supplied both watch face and app components together, we need a way to provide data.<\/p>\n The watch face is now able to rely on the presence of complication data sources<\/a> provided by the app. For example, a surfing watch face could bundle with a water temperature complication. This can be set as the default on the watch face using DefaultProviderPolicy<\/a><\/span> and is guaranteed to be present.<\/p>\n Taking it a step further, we can configure the complication<\/a> to be non-customizable, so that the complication becomes more of a custom data source. We can then use the complication however the watch face may need:<\/p>\n <\/p>\n In the case of our watch face, we define a SHORT_TEXT<\/span> complication service PaletteComplicationService<\/span>, which sends the following data:<\/p>\n <\/p>\n By using two of the fields on SHORT_TEXT<\/span>, we\u2019re able to send our color palette to the watch face, along with an indicator of whether the app has been configured (more on why that is important later).<\/p>\n We\u2019ve demonstrated how using the guaranteed presence of the PaletteComplicationService<\/span> allows us to ensure the watch face can receive our data, but we still need to define how to use and show the data within watch face elements.<\/p>\n Within the ComplicationSlot<\/a><\/span> element on the watch face, these data items can be accessed as COMPLICATION.TEXT<\/span> and COMPLICATION.TITLE<\/span> respectively. The various functions<\/a> such as abs()<\/span> and subText()<\/span> can be used to extract parts of these strings, or convert them into numeric types.<\/p>\n We combine this with the use of REFERENCE<\/a><\/span> to define colors. We can retrieve these colors everywhere on the watch, including outside of the ComplicationSlot<\/span>:<\/p>\n <\/p>\n This snippet illustrates creating a very small ComplicationSlot<\/span>, which will simply serve as a pipeline for our data:<\/p>\n Within the complication, a placeholder PartDraw<\/span> is created, and the extractColorFromColors()<\/a><\/span> function is used to transform the PartDraw<\/span> to the first color supplied by the complication. Using the Reference<\/span> element, this color value is then available to the rest of the watch face as [REFERENCE.primary_color]<\/span>.<\/p>\n In the full example, two more PartDraw<\/span> elements are used to provide the secondary_color<\/span> and tertiary_color<\/span>, simply providing the 0.5<\/span> and 1.0<\/span> index to the extractColorFromColors<\/span> function instead of the 0.0<\/span> value.<\/p>\n\n
\n
![\"illustration](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEj5BNn-eFschBMOkZae4r0sNEjAQx9NREnLJWHC91SxzgcNN-x7ndLg6A3vBXizg62vzkCXN0Cy6pxX2-LDIPJhnpVgg881N7w8wwU5l5NoLPP3X8RL40d5713sep3mkgfhDZ0oLkIrVoLtS0LnEcHARgkHneRpvXOLx89rQlUwtwcLKA8qzfoCA0hexEM\/s1600\/updating-watch-face-push-dynamic-colors-from-phone.png\")
<\/div>\nThe default watch face – bringing components together<\/span><\/h2>\n
Complication data sources – pipelines for data<\/span><\/h2>\n
Extracting and manipulating complication data<\/span><\/h2>\n