Support for sports and sub-sports

Cool thanks for testing that. I do wonder what would happen with a combo that's "obviously" wrong, like your original example of SPORT_MOTORCYCLING and SUB_SPORT_INDOOR_ROWING.

I guess some of the possibilities are:

- it crashes on the device

- it works but looks no different in connect

- it works but looks kinda funny in connect

- it works but connect "crashes" or acts unacceptably bad when you open the activity

In the simulator any combination of sport: [0, 86], subSport: [0, 124] works (checked with the oldest device: vivoactive, and some of the newest as well). Now the interesting question is if this is also true in real devices. Probably not.

Created a small app to test these things: https://github.com/flocsy/GarminSportsDev

Will also be available here, once Garmin approves it: https://apps.garmin.com/apps/a478d5f2-0a0a-4ba3-87aa-4832e97007ed

In Connect web it's just Motorcycling:

Just like in the mobile app (where you can "edit" the type, but not with the granularity of sport+sub sport):

In fitfileviewer.com you can see the sport:22, sub-sport:14

So basically it's as expected: The sport is used by Garmin but the sub-sport is disregarded.

This is in contrast to let's say Rucking (sport: Hike, sub-sport: Rucking) which is displayed as Rucking different from Hiking (different type, different icon, etc)

My problem now is how can I do a session that represents a treadmill walk. I don't want to use Treadmill Run, because it's not a run. So I tried sport: walk(11), sub-sport: treadmill(1) but it looks just like regular walk, and also tried: sport: fitness equipment(4), sub-sport: treadmill(1), which .... I don't like how it looks in Connect. It has an icon that is ok for "fitness equipment", but not for treadmill - and this is one of the supposedly supported combination. Maybe should open a bug?

see: https://postimg.cc/Rq4v5d08

I don't know if this is related, but I wanted to save the sport and subSport not only as text in the session name but also as 2 session fit fields (uint8). For some reason they are not recorded. They supposed to be added even to Connect.

fitcontributor.xml:

<fitContributions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://developer.garmin.com/downloads/connect-iq/resources.xsd">
    <fitField id="0"
		displayInChart="false"
		displayInActivityLaps="false"
		displayInActivitySummary="true"
		sortOrder="0"
		dataLabel="@Strings.sport"
		unitLabel="@Strings.empty"
		precision="0" />
    <fitField id="1"
		displayInChart="false"
		displayInActivityLaps="false"
		displayInActivitySummary="true"
		sortOrder="1"
		dataLabel="@Strings.subSport"
		unitLabel="@Strings.empty"
		precision="0" />
</fitContributions>

The activity (aka session) is saved, I do see it in connect, but there's no session section in it (not even looking in fitfileviewer.com)

I tried changing the order of the 2 calls of setData and session.start, but it doesn't make a difference.

I tested with speedMs = 4000, but even if the recording is set to smart (which it isn't) then it still should save it even if I only start the recording for 1 second (or even just half). I mean if the session (aka activity in connect) is recorded, then why the CIQ fields aren't? I also don't see my app listed in the 1st page.

function startSession() as Void {
var session = ActivityRecording.createSession({
:name => "" + sport + ":" + subSport + " " + name,
:sport => sport as Activity.Sport,
:subSport => subSport as Activity.SubSport,
});
session.start();
session.createField("sport", 0, FitContributor.DATA_TYPE_UINT8, {:mesgType => FitContributor.MESG_TYPE_SESSION, :units => ""})
.setData(sport);
session.createField("subSport", 1, FitContributor.DATA_TYPE_UINT8, {:mesgType => FitContributor.MESG_TYPE_SESSION, :units => ""})
.setData(subSport);
self.session = session;
timer.start(method(:stopSession), speedMs, false);
}

function stopSession() as Void {
var session = self.session;
if (session != null) {
session.stop();
if (save) {
session.save();
} else {
session.discard();
}
self.session = null;
}
}

I tested in the sim with fr955, opened the resulting FIT file in www.fitfileviewer.com, and saw the same thing as you.

After playing around with the code, I found 1 issue in the code and 1 issue in fitfileviewer.

1) You call createField() without saving the result to a member variable, which means that the result goes "out of scope" immediately, and the Field object is automatically destroyed (apparently because there are 0 strong references to the object).

The fix here is to assign the result of createField() to a variable that will last at least as long as the corresponding session (e.g. in this case, a member variable).

You would think that the corresponding session would *also* have a reference to the field, but maybe not? Maybe it's the field that has a reference to the session? But wouldn't that cause a circular reference meaning that neither the field nor session could be automatically destroyed when one goes out of scope? Maybe a field has a *weak* reference to the session? I guess it kinda makes sense for any internal references from field to session or vice versa to be weak references, to avoid causing issues with memory management in the app. But it would also make sense for the session to have a strong reference to all of its fields, because you'd think the fields should exist as long as the session exists.

Idk, maybe the idea is to support some edge case where you can "free" a record field in the middle of the session, to save memory.

Or perhaps the part of the FIT recording/contributing code that links a session to a field [and vice versa] is in native C/C++ code and not Monkey C code.

2) At least in the sim, a CIQ session field with the name of "sport" will apparently not be written. (No, really) This may or may not have something to do with the fact that one of the fields in the session message is called "sport" (although ofc in the file itself, the "sport" field id is encoded as a number, not as a string)

The fix here is to use any name other than "sport".

EDIT: actually this is just a bug in fitfileviewer. Since it already shows a native field called "sport" in the session message, it will ignore a ciq field that's also called "sport".

Viewing the FIT file in https://runalyze.com/tool/fit-viewer confirms that a CIQ session field called "sport" is actually written to the FIT file after all.

Interesting find. It kind of is between a bug and a feature. But here's a use case that I couldn't understand until now, but now it starts to make sense:

In my app (the real one, not the one for testing all sport profiles) I do keep all the Fields in the class and when the user changes config I either recreate them (i.e based on setting I either use stepsPerKm or stepsPerMile) or if the session wasn't started yet then I allow the activity type to be changed, in which case a new session is created, with all the Fields. And I noticed that in certain case I was expecting crashes, because I thought I used up all the bytes available (i.e when changing km/mile or speed/pace) but usually (though not always) it was fine. So it looks like in some cases some fields are recovered cleverly. This still needs more testing though.

Further testing could be needed to look into lap fields. After your find I would guess they behave similarly, so one would need to be holding on to them until the end of the lap (i.e if they would be used in a similar manner, to give a "name" to the lap at the beginning of the lap, we probably should keep a reference to them until the lap ends)

Anyway, all this is great find, but if course would not hurt if Garmin could add something about this to the documentation. Brandon.ConnectIQ