You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Fit files which consist of slices of messages (e.g. ActivityFile.Records), the writer implementation constructs the definition message based on the first element in that slice, and omits any fields which are invalid in that first element.
This means that if later messages include data in fields which were invalid in the first message, they will not be encoded because they weren't in the original definition.
I can see a few ways to improve this, with various tradeoffs:
Encode all fields all the time. This will waste huge amounts of file space, but it is simple. This could be added as an encoder option
Compare each new message against the current definition message. If they differ, encode a new definition message. This would be computationally slower, but that hasn't been quantified
Allow the caller to "register" a particular message template before encoding begins. This registration should include all fields which the user wants to encode. This would use less space than 1.
With 2., there would need to be considerations made about whether to use more than one local message ID. The FIT SDK suggests that local message IDs should be kept to a minimum to ensure maximum compatibility for decoders. That might be something else to add as an encode option.
The text was updated successfully, but these errors were encountered:
In Fit files which consist of slices of messages (e.g.
ActivityFile.Records
), the writer implementation constructs the definition message based on the first element in that slice, and omits any fields which are invalid in that first element.This means that if later messages include data in fields which were invalid in the first message, they will not be encoded because they weren't in the original definition.
I can see a few ways to improve this, with various tradeoffs:
With 2., there would need to be considerations made about whether to use more than one local message ID. The FIT SDK suggests that local message IDs should be kept to a minimum to ensure maximum compatibility for decoders. That might be something else to add as an encode option.
The text was updated successfully, but these errors were encountered: