DataFields for Watch Faces

Hi guys,

I was trying to develop a data field that can be selected to be shown on a watch face (like the other small fields that one can select when configuring a watch face) but it seems, that this is not possible. At least I have not found a way to do this. The DataField and SimpleDataField classes can only be used to create a data field for activities that is shown separately and not inside the current watch face. Is this really the case that it is not possible to write own WatchFaceDataFields or did I miss something?

Thanks!

Bye
  • The "data fields" you see on CIQ watch faces are part of those watch faces. If you mean adding something to a native watch fave, you can't write those in CIQ.

    You're correct that in CIQ, "data fields" only apply to native activities, such as running or cycling.
  • The "data fields" you see on CIQ watch faces are part of those watch faces. If you mean adding something to a native watch fave, you can't write those in CIQ.

    You're correct that in CIQ, "data fields" only apply to native activities, such as running or cycling.


    Thanks for confirming this!

    I think it is really a missed opportunity on Garmin side to disallow custom data fields for native watch faces. I have a very simple use case that I wanted to implement: one of the watch face data fields should show the current week number (week of the year). Development is done but I cannot add it to my watch face... :(

    I was using another smartwatch some time ago and there data field objects were exactly doing this, showing custom data on a watch face. This might be the reason I thought Garmin data fields do the same :)

    In that case I would like to put this as a suggestion for future releases of the CIQ API, it would be a great improvement and I don't think, this is too complex to integrate.

    Bye
  • On most, if not all watches, native watchfaces run in their own "mode" to save battery. They also differ a great deal based on the specific watch.

    Up until 1hz watch faces in CIQ (only available on some devices), only native watchfaces could do things like display seconds all the time (due to this special mode).

    Since you've written some monkey C, why not just write your own watchface and display the data you want? If you like the look of a native one, make it look like that, or use your own design.
  • one of the watch face data fields should show the current week number (week of the year). Development is done but I cannot add it to my watch face... :(


    It's not ‘your’ watch face, though, but just the one you chose to use.

    Connect‑IQ already allows you to develop ‘your’ every own watch face, and you can reproduce the elements and layout from the watch face you're currently using in watch faces you code from scratch. It's of course more ‘costly’ to you, but you can nevertheless have the functional outcome through Connect‑IQ if you really wanted to. I don't see it as a ‘missed opportunity’ for Garmin by not offering an easier way for users to selectively customise their factory-installed watch faces with arbitrary logic.
  • Former Member
    Former Member over 7 years ago
    I think Talkabout was confused because of Android Wear 2.0 watch face complications, which tasks the developer with creation of small data providing applet, which can be displayed on native watch face. This removes the necessity of a full watch face development cycle as native watch face allows to change these "complications" on the fly taking care of other time display related functions. I agree, that Google did a nice job trying to integrate multiple data sources within one watch face, but, as the others have already said, this is not the case with Garmin watches, although I must admit that AW's "watch face complication" concept is very similar to Garmin's "data field" one indeed.
  • I think Talkabout was confused because of Android Wear 2.0 watch face complications, which tasks the developer with creation of small data providing applet, which can be displayed on native watch face. This removes the necessity of a full watch face development cycle as native watch face allows to change these "complications" on the fly taking care of other time display related functions. I agree, that Google did a nice job trying to integrate multiple data sources within one watch face, but, as the others have already said, this is not the case with Garmin watches, although I must admit that AW's "watch face complication" concept is very similar to Garmin's "data field" one indeed.


    Well it was not Android Wear but the Vector Watch, that allowed to develop data fields selectable on build in watch faces.

    Connect‑IQ already allows you to develop ‘your’ every own watch face, and you can reproduce the elements and layout from the watch face you're currently using in watch faces you code from scratch. It's of course more ‘costly’ to you, but you can nevertheless have the functional outcome through Connect‑IQ if you really wanted to. I don't see it as a ‘missed opportunity’ for Garmin by not offering an easier way for users to selectively customise their factory-installed watch faces with arbitrary logic.


    The problem here is if I like a watch face that introduces a lot of own data fields that I like and use, but only need one more (in my case the week of year), it is a hell of work to implement everything from scratch again only to add a small functionality. In my case this is too much work for me and I will simply resign on doing it. The question is why in your opinion the possibility to add custom logic to standard watch faces is not something that is worth to integrate? There wouldn't be any harm to the existing faces if the APIs would be limited but would spare the need of developing a complex watch face because some need one more information to be shown on it.

    Bye
  • BTW, you used a quote from someone else as mine... :)

    How often did you have to charge your other watch? Could you go a week or more without charging? I've done that many times, even with some GPS involved.

    Battery is a biggie with garmin, and with WF's pretty much running 24/7 really come into play.

    Even if you don't want to do a CIQ WF, look at some of the restrictions there, such as on most devices and at most times, the WF only runs once a minute (native, as I said, run in a different mode - and aren't CIQ - and do things differently) It's a battery thing.

    To do a small little addition to a native watch face isn't just a few lines of code. You'd also need the CIQ environment there (the VM, etc)

    If you want this on a WF and don't want to do your own, maybe find a CIQ WF you like and suggest to the developer that they add it.
  • The question is why in your opinion the possibility to add custom logic to standard watch faces is not something that is worth to integrate?


    I've never been an advocate of making something easy and/or cheap for the average user, unless the commercial and/or strategic advantage for the technology provider – most likely to be funded directly or indirectly through increased out-of-pocket spend by users, as opposed to incidental cost savings or tapping new revenue sources so that the requestors and beneficiaries of ease-of-customisation don't have to wear the price in exchange – dwarves the benefit that the user would get.

    It's a win-win when the user gets something ‘more’ that he wants, and the technology provider gets to help itself to even more of what the user has to offer in exchange.

    Otherwise, I think developing software to suit one's own requirements as a user is a noble and interesting endeavour, but the pain, effort, and cost of ongoing maintenance is not something anyone else ought to be concerned about minimising for the individual (unless, again, there is commercial gain in doing so to be extracted from the user and amateur developer).

    Just to be clear: I like users and consumers to be offered what they want – functionally or qualitatively – but on terms (including but not limited to price) to be ultimately decided by someone else; leaving them with more money in their pockets or more spare time to run or ride (instead of hacking away in front of a computer) is not the goal, but commercial progress is.
  • JAMES Matchwood

    BTW, you used a quote from someone else as mine... :)

    How often did you have to charge your other watch? Could you go a week or more without charging? I've done that many times, even with some GPS involved.

    Battery is a biggie with garmin, and with WF's pretty much running 24/7 really come into play.

    Even if you don't want to do a CIQ WF, look at some of the restrictions there, such as on most devices and at most times, the WF only runs once a minute (native, as I said, run in a different mode - and aren't CIQ - and do things differently) It's a battery thing.

    To do a small little addition to a native watch face isn't just a few lines of code. You'd also need the CIQ environment there (the VM, etc)

    If you want this on a WF and don't want to do your own, maybe find a CIQ WF you like and suggest to the developer that they add it.


    The watch I was talking about, that allowed it to create custom data fields for watch faces (Vector Watch), was running 30! days with an always on watch face. So it is surely possible to integrate such a feature without losing the ability to make the watch run for weeks without charging.

    Sorry for using wrong person in the quote :)
  • I've never been an advocate of making something easy and/or cheap for the average user, unless the commercial and/or strategic advantage for the technology provider – most likely to be funded directly or indirectly through increased out-of-pocket spend by users, as opposed to incidental cost savings or tapping new revenue sources so that the requestors and beneficiaries of ease-of-customisation don't have to wear the price in exchange – dwarves the benefit that the user would get.

    It's a win-win when the user gets something ‘more’ that he wants, and the technology provider gets to help itself to even more of what the user has to offer in exchange.

    Otherwise, I think developing software to suit one's own requirements as a user is a noble and interesting endeavour, but the pain, effort, and cost of ongoing maintenance is not something anyone else ought to be concerned about minimising for the individual (unless, again, there is commercial gain in doing so to be extracted from the user and amateur developer).

    Just to be clear: I like users and consumers to be offered what they want – functionally or qualitatively – but on terms (including but not limited to price) to be ultimately decided by someone else; leaving them with more money in their pockets or more spare time to run or ride (instead of hacking away in front of a computer) is not the goal, but commercial progress is.


    I agree. But I think for a company like Garmin it should also be a goal to make their framework as flexible so their community has an easy job to integrate custom implementations to make their products more valuable. I am pretty sure that a lot of developers creating code for Garmin devices would love to have the possibility to "only" create a small data field showing data instead of creating a new watch face only to provide a look at custom values. Of course this is not a feature that will increase Garmin's profit big time but it would be a good sign for their community that they care also about small things their developer community requests. I am not saying that this feature is a critical one, it is simply a change that would improve flexibility of the Garmin framework.

    Bye