• State Verified Answer
  • Replies 5 replies
  • Subscribers 16 subscribers
  • Views 948 views
  • Users 0 members are here
Options
Related

ActivityRecording.session.createField -> fieldId - zero based? sequential?

OttawaDeveloper
over 4 years ago

I have an app using the ActivityRecording.session.createField() to create fit contribution fields.
This seems to be working. In the developer conference i saw a slide that i think indicated the fieldId must be zero based and sequential.
I see now that examples seem to do this also. I hope to review the videos and find the point where this statement was made when they are available.
In my app, i used sequential numbers for fieldId however they did not start at zero, instead about 50.
It all seems to work and the values are correctly displayed in Garmin Connect.
I have searched the documentation and cannot see anywhere that it indicates the need to be zero based, or even sequential.
Here is the documentation i was able to find.

ActivityRecording.session.createField -> fieldId — (Toybox.Lang.Number) — The unique Field Identifier for the Field
resources/fitContributions/fitField/id -> A numeric value from 0 to 255 used to refer to your field, No duplicates within an app are allowed

So questions:
1) is there a need to be zero based?
2) if i change the app now, causing my fit developer fields to have new ID, will it effect existing data in Garmin Connect recorded with old ID?
This would be a concern as many are currently using the app and have collected good data.
3) if the need to be zero based and sequential is real, then could the documentation be updated to indicate this

  • +1 over 4 years ago

    I am sorry that we did not get to you question during the live Q&A. I did some digging, and the field ids are treated more like dictionary keys rather than an index in to an array. Actually, the App Id and Field Id are used together to create the key. So we probably should have said "best practice" versus requirement. I apologize for the confusion.

  • 0 over 4 years ago in reply to Ben FIT

    I have had issues with fit files being corrupt at times as reported here, so had considered if it could be related to this fieldId numbering.

    forums.garmin.com/.../corrupt-user-defined-activity-fields

    So very good, thanks for the update, i was concerned if i would make a change to the fieldId it would mess up existing. So per your answer i will not make any change in this regard.

    cheers

  • 0 over 4 years ago in reply to OttawaDeveloper

    The info to understand the user fields is part of the iq file, gets send to the store when you update and the correct version of that should be used when info is displayed in GC. So if you have one field in version 5 of your app, and add a 2nd one in version 6, if you are looking fit recorded with version 5, you only see one, but with one recorded with version 6 of your app, you see 2.

    The fact this info is in the store (by way of the iq) is the reason you won't see your data with a side load of your app and need to supply a iq file for MonkeyGraph.

  • 0 over 4 years ago in reply to jim_m_58

    thanks jim, good to know.

    If for example version 5 and 6 have completely different fieldId. Then if i user records an activity using app version 5, then later another user records an activity using app version 6. Then to allow both can view their past results correctly, both with a totally different set of added fit fields then perhaps they must retain all old .iq files to allow interpretation and display in garmin connect, along with the associated version of the app so as to interpret incoming activities correctly according to the app version used by the user. It must be possible that people will have different app versions in the field, some may be out of date, but should still be working.

    Does this logic make sense?

    If not maybe there is some requirement for developer to retain some backward compatibility of fieldId?

  • 0 over 4 years ago in reply to OttawaDeveloper

    It's actually the same with app settings.  That info is also included in the .iq.  So if between version 5 and version 6 of your watchface, the settings a user can see/change is based on if they have version 5 or version 6.  (again, why you can't do app settings with sideloads as the store has to have the info)