new settings are not visible after downloading new version for couple of days

"It means users have to use default values hardcoded (if developer doesn't forget to handle it and it's additional waste of time/memory because default values should be always returned as defined in properties.xml but they don't or rather they are after couple of days)."

I agree that this is a waste of memory. There has been a similar situation in the past: if the user entered a non-numeric value for a number setting (for example), the app would receive null for that property, instead of the default value (or the previous value). I don't know if this is still the case, but due to that behavior, I had to hardcode defaults in my app too. It's also a shame that there's no way to programmatically retrieve defaults property values, for situations like this (or even for the on-device app settings case, if you have memory to spare).

"It means users have to use default values hardcoded (if developer doesn't forget to handle it and it's additional waste of time/memory because default values should be always returned as defined in properties.xml but they don't or rather they are after couple of days)."

I agree that this is a waste of memory. There has been a similar situation in the past: if the user entered a non-numeric value for a number setting (for example), the app would receive null for that property, instead of the default value (or the previous value). I don't know if this is still the case, but due to that behavior, I had to hardcode defaults in my app too. It's also a shame that there's no way to programmatically retrieve defaults property values, for situations like this (or even for the on-device app settings case, if you have memory to spare).

---So every time new members are added...

It, isn't true because as I mentioned there was no metersDescended (from 2.1) on fr55 and it has COQ >2.4 the same is florclimbed for venuSQ just because i they have not barometer...

now, I've optimised code and don't need preprocessor but still have ~400 enums = ~3,2kB to remove but thanks you to give me idea to write a script in php.... It's pity, in this very memory limited environment, monkey C doesn't have such simple and very useful functionality (how it possible, that we get very complicated to develop type checking and not simple - grep/find/search on text file?).

"I don't want to access future function/member:"

1) metersDescended was new at some point

2) there needs to be a way to add new members in the future without impacting devices which don't need them.

So how does this work:

"I don't know how SDK is prepared but it seems easier to have always all members"

So every time new members are added, they're added for all devices? Even CIQ 1? New SDKs already waste memory for old devices, this will waste even more memory.

"How do you use preprocessor?  Any external tool or built in? One built in is jungle but it not solve my all problems and there is duplicating code."

I use the C/C++ preprocessor with my own script and mini-build system (just a file targets to annotations and #ifdefs). This post is for Eclipse, but I'm sure it could be adapted for VS Code (I haven't gotten around to it). You can easily write your own solution if this approach doesn't meet your needs.

forums.garmin.com/.../solution-for-line-by-line-mc-conditional-compilation

I don't want to access future function/member:

-  have SDK e.g. 4.0.7

- target app to devices with e.g. CIQ > 2.4.0 so I should expected that all function/members from 2.1 are implemented in 2.4 (aside from deprecation)

But now I can't simply call info.metersDescended because some device even with 3.2 has no all members.

How do you use preprocessor?  Any external tool or built in? One built in is jungle but it not solve my all problems and there is duplicating code.

Also, if you always have all members, that wastes memory in other ways.

"I don't know how SDK is prepared but it seems easier to have always all members and only def directive in function"

That wouldn't work when new members are added, though. You still have to support older devices.

If you want to save memory and have line-by-line conditional compilation, you could run a preprocessor yourself (I use #ifdefs for one app myself), but that still doesn't solve the problem where you want to access a field that will be added to existing devices in an upcoming CIQ/firmware update (especially for the case of APAC devices).