Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

writer: All messages in a slice are encoded based on the valid fields of the first message #36

Open
usedbytes opened this issue May 9, 2019 · 0 comments
Milestone

Comments

@usedbytes
Copy link
Contributor

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:

  1. 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
  2. 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
  3. 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.

@tormoder tormoder added this to the Unplanned milestone May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants