FitContributor lifespan

enki42ea said:

Code that happens in onTimerLap runs after a new lap has started in the fit file so can't write to the previous lap?

It's somewhat counterintuitive, but you get around this by calling setData() as often as possible (e.g. once per second) regardless of whether the field is a session, lap or record type (assuming you have valid/changed data to write). setData() doesn't write to the FIT file immediately, it just queues up the next value to be written (*).

So if you're calculating a lap average (or something), you would be constantly re-calculating it and calling setData() as long as the timer is running. (If the timer isn't running, then presumably lap data isn't changing.)

This is essentially how the MoxySensor SDK sample sample works.

developer.garmin.com/.../Field.html

Once a Field is created with the createField() method, you can submit the next Field value with setData(), which will get written to the FIT file at the next opportunity.

enki42ea said:

Do we need to keep a reference around for the lifespan of the data field or if we know when we want the data saved we can create the field write the data and forget it. 

I think it has to be the lifespan of the data field (assuming that data can be saved all the way up until the end of the activity). IIRC, in the past I've tried to call createField() after DataField.initialize(), and it didn't work. I found that createField() has to be called as early as possible.

(*) So one limitation of CIQ FitContributor vs. native apps is that as soon as you call setData() for the first time, you can't *not* write data after that.

e.g. In a native app. if you're on an old watch with no optical HR (or optical HR is disabled), and you record data from an external HR strap, if you have a period of time in the middle of the activity where HR connectivity was lost, that shows up as a gap in the HR graph. (i.e. No data, as opposed to zeroes).

With FitContributor, you can only have "no data" at the beginning of a graph (by delaying the first call to setData()), because calling setData(null) is an error and causes a crash. So if you're recording data from a sensor or something, and that sensor loses connectivity, you have 3 choices:

- Continue to write the last good value to the file (which is misleading)

- Write 0s to the file (also misleading)

- Write some weird invalid value (if possible), such as -1