onTimerLap() in CIQ 3 functional for structured workouts?

I've read in the list of changes that the lap function would work in CIQ 3. Until now datafields with lap functions (like lap power) didn't work well during structured workouts, as onTimerLap() wasn't working. I have a user reporting with beta CIQ firmware that laps are still not registered. Did I misunderstood this?

Former Member over 7 years ago

The change log does not indicate that the lap function will be triggered for workout transitions. The entry in the change log for this update says this:

Add additional callbacks to the DataField class for workout step and multisport activity leg transitions.

Workout step transitions are not equivalent to lap transitions on our system. If you open the API documentation in the beta SDK, you will find the addition of two new callbacks as indicated by the change log. These callbacks are:

onWorkoutStepComplete()
onNextMultisportLeg()

If you wish to handle workout steps in the same manner as laps, you can implement the onWorkoutStepComplete() method and call the onTimerLap() method from there.

flowstate over 7 years ago

Workout step transitions are not equivalent to lap transitions on our system.

I know that this was stated before (and the current resolution was also proposed at the same time), but I'm wondering if you could shed some light on the exact reasoning behind the original design?

Sure, it makes IQ apps more flexible, but at the same time, any app the records data to a FIT file and/or displays lap values has no practical choice but to handle workout steps in the same manner as laps, otherwise nonsensical data will be recorded or displayed. When the user does a workout, there's no "choice" as to whether a lap is triggered when a workout step is complete -- it always is.

Is there any app at all which used onTimerLap() in a manner where they wanted to capture auto laps and manual laps, but not the end of workout steps? All three of those events trigger a lap record in the FIT file, and they cause native lap metrics (like lap pace) to be reset. AFAIK, from the end user's POV, there is no absolutely difference between the effect of an auto lap (for example) and the end of workout step, as far as native "lap stuff" goes (*). (Please correct me if I'm wrong.) Why should it be different for CIQ?

(* In fact, we all know that when you have auto laps during a workout, the resulting activity record contains a mix of the auto lap transitions and workout step transitions, and there's absolutely no way to distinguish between the two after the fact.)

I really can't think of a situation where an app would want to either display or record bad data just because you're doing a workout. One problem here is that everyone who deals with lap data has to change their apps. Another problem (correct me if I'm wrong) is that this change is only coming to CIQ 3, so older devices cannot benefit from this change.

I understand the reasoning behind not wanting to change the semantics/behaviour of an existing API call, but what if that change is something that everyone wants?

It would've been great to have the two new calls, but also to have onTimerLap() automatically be triggered any time that a lap record would be written to the FIT, or when native lap metrics would be reset/incremented. Whenever I see a new lap in the FIT file and/or the native "Laps" counter field increments, it would be consistent if IQ data fields also detected a new "lap" at the same time.

Sure, the function name might make less sense and it would be a change in existing behaviour, but I don't know if anyone would complain about that, since the overall consensus seems to be that users and developers don't like the existing behaviour.

GHG23 over 7 years ago

I know that this was stated before (and the current resolution was also proposed at the same time), but I'm wondering if you could shed some light on the exact reasoning behind the original design?

Sure, it makes IQ apps more flexible, but at the same time, any app the records data to a FIT file and/or displays lap values has no practical choice but to handle workout steps in the same manner as laps, otherwise nonsensical data will be recorded or displayed. When the user does a workout, there's no "choice" as to whether a lap is triggered when a workout step is complete -- it always is.

Is there any app at all which used onTimerLap() in a manner where they wanted to capture auto laps and manual laps, but not the end of workout steps? All three of those events trigger a lap record in the FIT file, and they cause native lap metrics (like lap pace) to be reset. AFAIK, from the end user's POV, there is no absolutely difference between the effect of an auto lap (for example) and the end of workout step, as far as native "lap stuff" goes (*). (Please correct me if I'm wrong.) Why should it be different for CIQ?

(* In fact, we all know that when you have auto laps during a workout, the resulting activity record contains a mix of the auto lap transitions and workout step transitions, and there's absolutely no way to distinguish between the two after the fact.)

I really can't think of a situation where an app would want to either display or record bad data just because you're doing a workout. One problem here is that everyone who deals with lap data has to change their apps. Another problem (correct me if I'm wrong) is that this change is only coming to CIQ 3, so older devices cannot benefit from this change.

I understand the reasoning behind not wanting to change the semantics/behaviour of an existing API call, but what if that change is something that everyone wants?

It would've been great to have the two new calls, but also to have onTimerLap() automatically be triggered any time that a lap record would be written to the FIT, or when native lap metrics would be reset/incremented. Whenever I see a new lap in the FIT file and/or the native "Laps" counter field increments, it would be consistent if IQ data fields also detected a new "lap" at the same time.

Sure, the function name might make less sense and it would be a change in existing behaviour, but I don't know if anyone would complain about that, since the overall consensus seems to be that users and developers don't like the existing behaviour.

I agree with Flowstate, this is not a very elegant solution. Also the developers will have to change code, to get a datafield detecting laps at the end of a workout step, while manually triggered laps and laps triggered based on distance (like every 400 meter) aren’t possible this way. Ah well, at least there is a solution....

Martin Strachota over 6 years ago

+1 It seems strange to handle laps and workout steps in a defferent manner. I'm also *very* disappointed that the older devices (Fenix 3) did not get the update.