Seems odd that this API is not supported when there is a app/widget/glance for it.
I had to go with the getting the data via the complication API instead.
Seems odd that this API is not supported when there is a app/widget/glance for it.
I had to go with the getting the data via the complication API instead.
I expect you'll see more cases where things are only available with a complication.
Just seems weird to leave that one API out when others are there. Seems like an oversight in this case. Dunno
It's also not there for the va5, which also has complications.
But it is there for 265, 965, Fenix 7, Fenix 7 Pro, and other devices which also have complications.
I tend to agree with the implication that it's not oversight, but an intentional decision (albeit one that doesn't make a whole lot of sense from the outside looking in.)
Kinda like how 255 and 265 support navigation (as in following a course), yet CIQ does not expose course-related fields such as ActivityInfo.distanceToDestination on those devices.
Or as someone else posted, how onDrag is not supported for 265, even though it is supported for 955/965, and all 3 devices have a touchscreen.
It just seems that Garmin is adding an extra layer of market segmentation for CIQ, where certain devices lack CIQ support for certain native features, even though said CIQ support is available for other devices with the same features.
I just don't understand what the point is, since:
- this kind of thing is not on the spec sheet, so it won't affect the user's purchasing decision
- most users don't care about CIQ anyway
The reason it doesn't seem like an oversight to me is:
- it happens across multiple generations (like 255/265)
- it's always the lower-cost devices which lose CIQ features (255/265 vs 955/965, Venu/Vivoactive vs Forerunner)
If it actually is an oversight, the only explanation I can think of could be that a device was not originally planned to have a certain feature (and therefore it was left out of CIQ for that device), but the feature was added at later date. (It has happened in the past that a device was supposed to have a certain feature, but it was ultimately removed, which is the opposite situation.) However, this explanation wouldn't explain why onDrag is missing from 255/265, since it's inconceivable that those devices were originally not planned to have touchscreens (especially 265.)
Many times it's not the CIQ group that defines what's there, it's the platform groups. If they don't have something, like an API call, that the CIQ VM can use, it's not in CIQ. They are also the ones that define what the native fonts will be,etc.
The "Lifestyle" group (va and venu) at times don't have a feature. The forerunner group is better, and with the fenix group, devices tend to have everything.
for some things it can be a limit based on something like HW. With timeToRecovery, it could be the platform group didn't want to use the memory to build a CIQ VM API, and said "we already got this available with complications, so just use that. For onDrag, it could be something like the specific display they used doesn't handle it well, etc
The "Lifestyle" group (va and venu) at times don't have a feature. The forerunner group is better, and with the fenix group, devices tend to have everything.
OP and I are specifically talking about features that exist in the device, but are not reflected in CIQ. I think it's blindingly obvious that if a device doesn't have a feature, it's not going to be reflected in CIQ.
The question is: "why do devices X, Y, and Z have feature A, but only device X and Y reflect feature A in CIQ, not Z?"
Nobody is asking why VA5 doesn't have CIQ fields related to following a course, for example, since we know that VA5 doesn't support following a course. Although I guess we could ask why lifestyles devices like VA5, which support "limited navigation" (navigating to a location or back to start), don't support CIQ navigation fields relating to the limited navigation that they do have. e.g. distanceToDestination could conceivably still apply when navigating back to start. But at least in that case, the rule is applied equally to devices supporting "limited navigation'.
for some things it can be a limit based on something like HW. With timeToRecovery, it could be the platform group didn't want to use the memory to build a CIQ VM API, and said "we already got this available with complications, so just use that.
Forerunner 965 and Vivoactive 5 have the exact same amount of available memory for each CIQ app type, and they both support the same kinds of apps, yet the former supports timeToRecovery and the latter does not. If the argument now becomes "different teams are working on these devices", that just proves the point that these differences seem arbitrary to users (including CIQ devs), kinda like like the little UI differences between 955/965 and Fenix 7/Epix Gen 2, despite all of those devices apparently using similar similar firmware.
255 and 955 have identical memory limits for apps, as do 265 and 965. All of those devices support navigation (following a course). 955/965 have navigation-related CIQ activity info fields, but 255/265 do not.
For onDrag, it could be something like the specific display they used doesn't handle it well, etc
I don't have a 265, but I do have a 955. Precise drag detection clearly works for the native UI, considering how the UI reacts smoothly (with seemingly single-pixel granularity) and follows your finger (*), when you literally drag your finger after pressing on a draggable user interface element, such as a glance, data page or circular menu item. I saw pretty much the same thing in a DCR video review for 265, although it's hard to tell for sure. It's not like the original Vivoactive which only supported horizontal swipes and not vertical swipes (iirc). It's also not like the 630 which could be perceived as not supporting precise drag detection (although it's not clear whether that's due to touchscreen limitations, other limitations, or all of the above) -- see below.
(*) You can make the 955 display half of one data page and half of a neighboring data page at the same time by simply dragging your finger on the screen, stopping halfway, and not letting go (this was impossible in the 630, for example.) This indicates to me that the watch knows exactly where your finger is. This is also demonstrated by the watch UI precisely following your finger when you scroll, same as any touchscreen on a modern phone. To me this demonstrates that the watch knows where your finger is at all times, including while you're dragging. I guess to be sure that 265 supports drag detection, I'd have to do the "half data page drag" test. Maybe I'll try it next time I see a 265 in a store.
Contrast with the 630 where the UI would always scroll the exact same way no matter how you moved your finger, as long as you met the minimum threshold for a swipe gesture. The UI didn't precisely follow your finger, it reacted to a swipe gesture in a predefined way. In this case, I would definitely understand if CIQ only supported onSwipe and not onDrag (ofc, onDrag did not exist back then.) Whether this was due the touchscreen itself or other limitations (lack of GPU, poor software, etc.), it does demonstrate how older Garmins had a significantly worse touchscreen experience which I doubt can be seen in any modern Garmin watch, even the cheaper ones.
I also find it hard to believe that the 265 would use a touchscreen that's significantly inferior to the 955 or 965's touchscreen, again because of the usability implications.
I could be wrong though.
Only Garmin knows the answer to any of the questions.