I’ve been playing around with the new version and I found a feature I don’t remember in ver 1.3.x, but I can’t find anything definitive about it online.
In the style editor (Style->Customize Style->), in the left hand column if you hover over any of the headers marked “ID_SET_xx”, a button called “text id” is revealed . Clicking it opens a dialog box with an editor of some type.
Then, in the main menu, in the “Project Settings” dialog box, there’s a new tab called “Data”. This opens a DB that is related.
What’s this about? I have a feeling it has something to do with the new Watch Face Format feature coming in OSW 4, but again I can’t find anything about it.
If anyone can shed some light on this, I would be grateful. I’ve been lurking on the forum for about 6 months or so without posting, so I’m not a total newbe, but I’m close enough (lol).
I think you are correct. As you might already know, new watch faces using the Watch Face Format won’t have any code (see Watch Face Format | Android Developers). WearOS 4 itself will run your watch face and even have a built-in customization editor. The following screenshots are from the current WearOS 4 preview running in an emulator:
As you can see there will be many customization options available for watch faces: complications, color, layouts/styles, “on/off”-options. The text you see in this screenshots are provided by the watch face (“Graphite”, “Modular II”, “Bold Time” and so on). That’s what this “Text ID” in Watch Face Studio is for.
WFS will support more and more of the Watch Face Format (I hope). The technical documentation for those customizations are here: UserConfigurations
Edit: If you want to test your watch face on WearOS 4, you can follow this guide: https://developer.android.com/training/wearables/versions/4/setup
[edit: This link is broken, reformatted to no longer autolink]
I found out. This works in Wear3 and does not require Wear 4.
It is to localize the style settings as well as the Watch Name setting in the publish window.
Edit & Properties
• Support Text ID for localized text which is displayed on device such as Style name and used in Talkback use.
Oh ok, thanks for clarifying that. If I’m understanding the concept correctly, a “Custom Watch Face” in Wear OS 4 will consist of not much more than a file of options, configurations and perhaps vector/raster image descriptions in XML format, and Wear OS 4 will handle the heavy lifting? Maybe that’s too simplistic, but it also would seem as if Wear OS 4 has been “dumbed down” a bit.
I’m not sure how I feel about that. I haven’t done much Android anything in Android Studio but it seems as that is the definitive “no limitation” tool in order to manipulate low-level code. Now, it seems as if the future direction is leading away from this a bit. There are already 3-4 platforms (including WFS) that allow the less learned and those that don’t understand low-level Java or Views/Compose etc. to create nice watch faces.
I could have this all wrong, I really need to do some serious studying of the whole platform and run through some codelabs and ordinary app development to feel like I really understand. I already see some increased limitations relating to complications (albeit minor, but still more limiting) with the latest version update and I’m hoping that won’t be the norm. I’m definitely looking forward to easier and more comprehensive customizations in the future, regardless of implementation.
The Jetpack Watch Face libraries are not going away though. If you wish for a more complex or interactive watch face, maybe including a companion app on your Android phone, then this is still the way to go. Android Studio, Java/Kotlin and all that.
But for the most other use cases the Watch Face Format is good enough. Customization will be fine once WFS supports the Watch Face Format completely in a future release (hopefully sooner than later). I still want to localize my color palette names instead of seeing “1. option” to “30. option”.
Besides the WYSIWYG designer for non-developers, I think the lack of code is the biggest advantage. I don’t have to worry about draining the battery because I called some function too often. That’s the job of Wear OS 4! No need to recompile my watch face in Android Studio with the newest libs, to get bug fixes and improve on the battery life. Also I don’t have to bother with the lengthy Google Play testing process.
I just provide an aab bundle with some XML and assets and the smartwatch takes care about everything else. Awesome!
Two things to understand.
First
In older Galaxy Watches they only supported Samsung Watches so the complications and data sharing from Health or Weather API was a lot more and allowed more customizations. WFS is for all Wear OS (3+) based smartwatches so are limited in the scope of customizations
Second
The shift has gone from a complication and design being static with little ability to change by the end user to a more standard format with the end user having much more ability to change complications to suit their needs.
Ah, I see your point. I haven’t had the pleasure of publishing to Google Play Store as of yet, so there is certainly something to be said for making that whole process easier. And it does seem like we’re getting more end-user customization options with more coming in the pipe.
So yeah, once I get more familiar with the new format I’m sure I’ll recognize the benefits more easily. Of all 5 major custom watch face authoring tools, it still seems as if Android Studio is the only one that will give me everything I want, but WFS is pretty close and easy to use, too.
I was working on a watch face that had a group of complications move around the dial as a unit, sort of an eccentric off-center pointer, like this (I know, the colors are horrible):
This does not look possible with the 1.4.x release, because I can’t group or apply tag expressions that are needed to complications now. Is this an example of what you’re referring to?
This does not look possible with the 1.4.x release, because I can’t group or apply tag expressions that are needed to complications now.
This FAQ 13 I think this is because some of the available complication types may require tap action or something.
Is this an example of what you’re referring to?
About dumbing down? No that is a result of GDPR and other governments privacy standards. With Tizen Watches the Samsung Health API (Application Programming Interface) knew that the data would only be used for a display and not shared by Galaxy Watch Studio.
On Wear OS we do not know it the watch being run on has Samsung Health. With Wear OS 3 there is a new way called Health Connect /Health Services where all the Watch Health apps can share Data to one API. Heart Rate and Steps data will be shard by Samsung Health and Google Health to Health Services in Wear 4 (available soon). Hopefully other health data will be share with WFS in the future.
Unfortunately Weather Data is all licensed and the Free API Galaxy Watch Studio used is not an option at this time.
