Fitfield: override unitlabel depending on user units

Hi,
i want my app to support imperial units.
Depending on the system being used, the unit label being used for some fit data, might change "yd" or "m", "min/100yd" or "min/100m", and so on.

<fitFieldid="1"displayInChart="true"sortOrder="1"precision="2"chartTitle="@Strings.pace_label"dataLabel="@Strings.pace_label"unitLabel="@Strings.pace_units"fillColor="#FFA500"/>

is this possible at all?
  • I'm not sure its a good idea to be saving varying data types and units in the FIT file. If your data matches a pre-defined (distance, speed, etc) type you should use both that data type and unit of measure, especially if you intend to ever use the native number mapping. If it isn't already listed and you're creating something new, it is probably best that it is always the same data type and unit of measure in the FIT file. Garmin Connect is going to be limited to some degree because developers don't control the display of the data. But if you want to have your data consumed by sites other than connect it's going to need to be a consistent and well defined entry in the FIT file.

    To get more specific about the question you're asking, the FIT contributor definition file your discussing is specific to Garmin Connect and is not read dynamically in conjunction with the FIT files your application produces. I would not expect it to automatically adjust based on the data found in the FIT file and I don't think you can achieve what you want this way. The way this should work but you aren't going to have control over Connect is: application records the FIT data with a known data type and unit of measure. The displaying application (in this case Connect) will need to be able to convert the units of measure based on user preference to display the preferred units. The second part doesn't exist at this time.

    EDIT:

    <fitFieldid="1"displayInChart="true"sortOrder="1"precision="2"chartTitle="@Strings.pace_label"dataLabel="@Strings.pace_label"unitLabel="@Strings.pace_units"fillColor="#FFA500"/>


    I would add that the @Strings.* are I believe intended for language translations and different devices and not to be dynamically adjusted but rather chosen when specific language/device resources are defined in the project. You can read some more on it here: https://developer.garmin.com/connect-iq/programmers-guide/resource-compiler/ under "Overriding Resources".
  • Hi,

    my app is a pool swim app. The standar type for these data are m for distance and m/s for speed. I write the data in these units, wi the corresponding native id, so that third party sites like sporttracks.mobi, trainingpeaks.com or runalyze.com can interpret them.
    unfortunately GC does not override the native fields. This means, that i have to translate the units to something that GC users are used to handle. No swimmer tracks speed in m/s. They usually use min/100m or min/100yd. For these fields, i have additional fields in the fit field, without the native id. These fields are ignored by third party plaforms. They are only created so that i can show something reasonable in GC. Which is ironic, given that garmin is somehow behind the FIT format.

    thank you anyway.
  • I completely understand the situation you are in. I have a rowing application that the data is stored as m/s but users use pace/500m. With the charts there is no way at this time to get the axis to represent that unit of measure and users are completely confused about why distance and all other metrics are 0 while the Connect IQ metrics are all correct and filled in. The lap data isn't working at all. The best thing I can suggest is document this and have users express an interest so the need for native number integration into Garmin Connect is seen, that is really the correct answer to the problem, not the random generation of duplicate data by all developers to achieve the end result. You can see some of the user comments I get here if you're interested: https://forums.garmin.com/showthread.php?366510-Erg-IQ. But I do fully appreciate the situation and feel your pain :(
  • Hi again,
    Indeed your case is very similar to mine.
    GC is the weakest part of CIQ as of now, tons of bugs known for several months and no news about fix schedule or new features :-(
    Garmin guys are not so responsive to GC issues as they are for other stuff.
    Anyway we'll keep on trying:)
  • To be completely fair, the Connect IQ and Garmin Connect teams most likely aren't one and the same which is expected in a company this large. Clearly the Connect IQ piece does exactly what it says it will do based on the success found in third party sites using the native mapped data and their presence on the forum is all aces. :cool: I've never communicated in the forums with the other side (see edit below) but it is a shame that users might be looking at other display sites because Connect won't do what they want :confused: These complaints probably really should be getting put into the Connect forum but on the outside they look like Connect IQ issues ... lets think positively that these are growing pains because Connect IQ is pretty young and it'll eventually do the things you and others are expecting.

    EDIT: I did start a thread in the Connect forum about this issue but there were minimal views and I didn't get any response **shrug**, here is the link in case you care or want to add things you found I might be missing: https://forums.garmin.com/showthread.php?367612-Feature-Request-Provide-Integration-For-FIT-Developer-Fields
  • Former Member
    Former Member over 8 years ago
    Hey everyone,

    I know it's a disappointment that this feature is lacking right now. Unfortunately it is the case that there are moving pieces across multiple teams. However, each team does have the issue on their radar. I'm going to try and do what I can to make sure to push the priority of this issue among our team and others. What I would love to see from the forums is some help in that effort. I've tagged this post with "fitcontributor" and "garmin connect" tags. Would you guys be willing to tag any new posts or other posts related to this issue with those tags? The more data I can get about the issue will only help to raise the level of importance.

    Thank you all!

    -Coleman
  • I have a thread with a bunch of comments outlining specifically the issues with connect here:

    https://forums.garmin.com/showthread.php?366510-Erg-IQ

    I can't add any more tags to that thread and don't want to remove the tags there since they are more relevant for searching. I also saw on Reddit comments about connect in relation to the application:

    https://www.reddit.com/r/Rowing/comments/5n4hff/ergiq_connect_your_garmin_to_a_pm5/
  • Hey everyone,

    I know it's a disappointment that this feature is lacking right now. Unfortunately it is the case that there are moving pieces across multiple teams. However, each team does have the issue on their radar. I'm going to try and do what I can to make sure to push the priority of this issue among our team and others. What I would love to see from the forums is some help in that effort. I've tagged this post with "fitcontributor" and "garmin connect" tags. Would you guys be willing to tag any new posts or other posts related to this issue with those tags? The more data I can get about the issue will only help to raise the level of importance.

    Thank you all!

    -Coleman


    Sure! Thanks Coleman
  • Former Member
    Former Member over 8 years ago
    Until Garmin fixes this i use two different fitfield id's depending on the units, eg.:

    if (Sys.UNIT_STATUTE == weightunits) {
    fitFieldWeight = session.createField(Ui.loadResource(Rez.Strings.fitFieldNameWeight), 1, Fit.DATA_TYPE_FLOAT, { :mesgType=>Fit.MESG_TYPE_SESSION, :units=>"lbs"});
    } else {
    fitFieldWeight = session.createField(Ui.loadResource(Rez.Strings.fitFieldNameWeight), 0, Fit.DATA_TYPE_FLOAT, { :mesgType=>Fit.MESG_TYPE_SESSION, :units=>"kg"});
    }


    <resources>
    <fitContributions>
    <fitField id="0" displayInActivitySummary="true" sortOrder="0" precision="1"
    dataLabel="@Strings.fitDataLabelWeight0"
    unitLabel="@Strings.fitUnitsLabelWeight0"/>
    <fitField id="1" displayInActivitySummary="true" sortOrder="0" precision="1"
    dataLabel="@Strings.fitDataLabelWeight1"
    unitLabel="@Strings.fitUnitsLabelWeight1"/>
  • This approach crashes MonkeyGraph, though. It works great with Garmin Connect, but it means I can't test my app 
    "as is" to see how it will look. Specifically, the problem is you can't have two identical sortOrders in the XML file. You can't have a missing "sortOrder" either. They have to start at 0 and exactly increase by 1 ... even if you never instantiate the fitcontributor field in your IQ app. MonkeyGraph doesn't care ... it crashes with nullpointerexception every time (even though it does indeed work with Garmin Connect correctly). Has anyone figured out a workaround for this workaround so I can do local testing with MonkeyGraph to see how it would look on Garmin Connect?