Generic decoder w/ new Swift SDK

So I've been playing around with the new Swift SDK, thanks Garmin for this! I added the new SDK to the benchmarking project Brice posted on GitHub. Not as fast as C, but happy with the results!

I was working on creating a general parser to test the SDK and become familiar with it. I'm still figuring out the best approach*, but I've run into questions on the subfields. I'm following the approach used in the CSV example in the java SDK. In the MesgCSVWriterBase.getValueString() function, the for loop uses fieldBase.getNumValues() to know how many subfields it's dealing with. In the SwiftSDK, the FieldBase.numValues computed property is not public, nor is there any kind of getValues() to get a hold of the array to be able to loop through it.

Its easy enough to extend the class in Swift and add a new method to get access to this, but so far every time I've run into something like this I realized there was a different way that seemed to be the "intended" path. So this is making me wonder if I'm missing something and there's a better approach to a generic parser.

Thanks for any insights.

* specific Mesg types have getter methods that return values already resolved to the respective enum value, but every Mesg type has differently named getter functions so using them is not very generic.

0 Ben FIT 19 days ago

Sub fields are a way to reinterpret the main field. Most of the time the reinterpretation is a different scale and offset, or to map to a different custom type.

For example, in the file_id message there is the manufacturer field and the product field. When the manufacturer is Garmin then the product field is interpreted as the garmin_product type. The garmin_product sub field includes the reference field (manufacturer) and refercne value (garmin) and these reference values are used in the settters/getters to return the correct value. If the manufacturer is not Garmin, then getGarminProduct() will return null.

The fieldBase.getNumValues() does not return the number of subfields, it returns the number of value when the field is an array. These are two different things. In most SDKs the sub-fields are not evaluated until the getter is called. So you can probably omit sub-fields from your benchmark testing, since no code is executed during decoding. The Python and JavaScript are the exceptions since there are no getters/setters, but subfields can be disabled through a decoder option.