Complication vs direct data access

    var comp = Complications.getComplication(new Complications.Id(Complications.COMPLICATION_TYPE_RECOVERY_TIME));
            if (comp.value != null) {
                return (comp.value / 60).toNumber();
            }

Note that the doc for COMPLICATION_TYPE_RECOVERY_TIME says "value is a Number of minutes remaining in your recovery time" (context for anyone else reading this comment).

This code, which converts the recovery time from minutes to hours, will always truncate/round down the answer. e.g. 59 minutes will be converted to 0 hours, 119 minutes will be converted to 1 hour, etc.

In this case, you may wish to always round up (especially to avoid the edge case where 1-59 minutes will be converted to 0 hours, which could be misleading for ppl who want to know when they're fully recovered). (I'm assuming that displaying fractional hours for recovery time is out of the question.)

e.g.

return ((comp.value + 59) / 60).toNumber();

Also note that toNumber() is redundant here (although it doesn't hurt), assuming that the complication value is indeed always a Number. (Might not be a bad idea to *not* make that assumption, since Garmin has been known to change things like that.)

I've just tried on a beta wathcface with TYPE_STEPS and it updates at the same time than activityMonitor, the question is, as you said which takes more resources, my plan is about for example Weekly running distance, if we use UserProfile, we have to loop through all data and compare a date etc...so lots of code line, but if we can use Complications without subscribing etc, it would be great.

Good spot, thanks! :)

If you use the value for steps from the complication, once you pass 9999 steps, you'll see something like "10k" steps, so while I use the complication for onPress, I use ActivityMonitor for the actual value.

thanks! steps it is what I implemented to easily see what is happen, but for thing like this is quite easy to get it through ActivityMonitor, but for stuff like weekly running distance we can't have it directly so that might be more interesting to get it through Complications

"Suscribing or not suscribing, that is the question."

-Omlet

What I tried to explain maybe not very well, Jacquers's "technic" could be very interesting.

let's say we propose a wf with Next Calendar Event, training status which are not in API, or data like weekly runnin distance which can be a mess to get.

if we suscribe, I think it is a nonsense to suscribe for all complications, that will take resources even if user does not select them, so, here, when settings change or initialize, we have to

- Clear all suscriptions

- Loop on all wf datafiled to check if one of them is selected

- suscribe for the selected one (is there any suscription number limit ?)

- Deal with complication update, so store the ID suscribed, store the value received etc.

if it is not mandatory to suscribe, we can just use the Jacquers's technic and display the value returned if available.

which in my opinion would take less resources that delaing with suscription/update etc.

(mine is a Fenix8Solar47mm and without scribing seems to work)

FlowState said:

return (comp.value + 59 / 60).toNumber();

Shouldn't this be:
return ((comp.value + 59) / 60).toNumber();

?

btw, I was trying to get recovery time and someone else showed me this technique :) forums.garmin.com/.../vivoactive-5-time-to-recovery

And with this techniques I don't think you get new values every time you call comp.Value, it seems you have to init a new instance to get an updated value.

yes, i did no specify, your tec has to be called on onUpdate()

Yep my b thanks!