GPS MAP 67 crashing with system error when creating a fit record field

It could be that it happened to the same user twice and could be due to other data fields not leaving space for 4 more user fitContrib elements.  About all you can do is try reducing the number of elements you use or include a warning in the description about using it with other data fields that also use fitContrib data

System error on createField usually means that there is another DataField that uses too many fields and doesn't let enough for this DataField. 

You can tell the user to remove other datafields that record to fit file and test my theory.

You can also play with Fit Field Waster DF: https://apps.garmin.com/apps/2e8bf443-f030-4bee-b816-35f5eb404550

is it possible to catch this in code by using try?

No, the only way to "prevent" it is to play nice and hope that other devs also play nice. So make settings in your app that enable/disable the recording of fields (you can still display them all the time, just don't record them to fit) and if the CIQ developer of the other DF that records to fit file in the same activity also does this then maybe the end-user will be able to pick the fields they're most interested in... 

The problem is that some CIQ data fields need to record a certain amount of data as an essential feature.

For example, there's no point in using the Stryd data field unless it records data. The whole point is to get that Stryd-specific data into the FIT file so it can be analyzed by the Stryd app later on. And Stryd needs to record a ton of data, beyond just running power.

That's why Stryd support just tells users to uninstall all other CIQ data fields from an activity that uses Stryd.

It's not just a question of CIQ data fields playing nice, it's obviously a consequence of Garmin imposing a per-activity limit on the amount of FIT data that can be recorded, where each activity can have multiple CIQ data fields which record data. It's a collective limit on the amount of data that can be recorded, where it might make more sense to have an individual limit.

If there was only a per-CIQ field limit, then it would be trivial to comply with. Since there's a per-activity limit, it's impossible for to devs to be sure in advance that their one CIQ data field won't be "responsible" for the user going over the limit. (But if there's multiple CIQ fields, is any single CIQ field ever responsible for going over the limit, unless it records an unreasonable amount of data?)

To illustrate my point, the max number of CIQ data fields has been increased from 2 (most pre-Fenix 8 watches) to 4 (Fenix 8). Over on the Fenix 8 forums, people have said that they perceive an increase in the frequency of CIQ data field crashes compared to older devices. It was speculated that it's specifically fields which record data that are crashing. 

My educated guess is that while the max number of CIQ data fields has doubled, maybe the total amount of data they can record has not? Meaning that the average permissible amount of data per CIQ field has been cut in half. It's just a guess, but it could explain why these users see more crashes now. Garmin lets them install more CIQ data fields than before, so they do so, but some or all of those fields record data, which makes it more likely than ever that the total data limit will be exceeded.

If my guess is right, then this is just another example of a not-so-great situation that wasn't really created by devs, but imposed on them by the design/constraints of CIQ.

Sure, devs could 'play nice' by allowing users to turn off FIT recording (or as I've seen in some cases, to set a mode in the app where a *minimal* amount of data is recorded). That's still not a perfect solution as:

- it imposes a burden on the user to change a setting to prevent the app from crashing (I doubt any user likes this)

- it's not a solution at all for an app like Stryd where recording a certain amount of data is an essential function

Another thing devs could do is never record more than (activity limit) / (max number of CIQ fields). But that only works if every other dev agrees to do the same thing. It also doesn't work if the app in question needs to record more data.

I'm not saying that Garmin doesn't have good reasons to have a per-activity limit. I'm also not saying that Garmin should try to strictly subdivide this per-activity limit to make a per-CIQ field limit which is activity limit / max number of CIQ fields (this would suck in the case that a user only wants to install one field that records data, since that field would only be able to record 1/2 or 1/4 of the total limit.)

But at the very least, it would be nice if Garmin would make this a catchable exception instead of fatal error. At least CIQ data fields could try to gracefully recover from this situation.

But that's still not a solution, as it would simply circle back to companies like Stryd suggesting that users uninstall all other CIQ data fields.

So maybe the real solution after all is for Garmin to multiply the current activity data limit by the max number of CIQ fields, and also give each CIQ field a strict limit of (new activity limit) / (max number of CIQ fields). That way every CIQ field could record just as much data as they could before, but they would also be able to avoid crashes by simply adhering to the per-CIQ field limit. Since every CIQ data field would be subject to this per-field limit, it would also be impossible for multiple CIQ fields to *collectively* go over the activity limit while still functioning individually.

I'm guessing they can't or won't do this due to real memory constraints though. (Or perhaps that was historical reason).

How to code this best effort, avoiding tons of "if fit logging enabled then ..." statements? Is there any example or sample code for this use case?

If you have memory to spare for the code, you could create a wrapper class for the recording session and fit field objects.

If FIT logging is enabled, this class will create the session and field(s) as necessary.

If FIT logging is disabled, this class will do nothing.

The class would also wrap setData() and any other FIT-related methods.

It would be similar in principle to a debug logging function that calls System.println() for the debug build and does nothing for the release build.