Support writing FIT files

[wtchen]

Adding encoding support would open up this library to a number of new uses, such as data collection (e.g. sport watches etc) and file conversion. It would also distinguish this library from others, most of which don't provide any encoding support.

We could use tormoder's Go library as a reference implementation. I'm happy to help work on this over time.

[stadelmanma]

Hi @wtchen I’m not opposed to the idea. I simply didn’t have a personal use case for writing files or the time to commit to it.

I suspect to write files we’ll need something like #14 implemented as well to make a more friendly API. Although the data structures returned by reading probably could work just as well but provide less built in type safety.

[wtchen]

@stadelmanma Thanks for getting back to me, glad to communicate with you. Personally, I think it would be useful to use for scripts where I can edit my FIT files. It would be nice if I can edit out a faulty data point without having to use an intermediate format.

I would probably inclined to use the existing data structures. From a glance, they seem to be more than good enough 🙂

I'm happy to start on this, though I would have to work on this piecemeal on weekends. Perhaps you can create a branch I can submit PRs to? Or I'm glad to accommodate however you'd like me to submit features related to this.

[stadelmanma]

Hi @wtchen simply forking this repo and opening up a draft PR would work well enough to collaborate on changes. Sorry for the delay I thought I had responded already.

[stadelmanma]

Adding a note here based on discussion in #47. When serializing FIT files from library data we will need to assert that any instances of Value::Array being serialized only contain the same type and don't contain nested arrays. We'll also need to reject arrays that are too long but contain valid data, and pad arrays that are too short with the proper Invalid value.