Settings failed to push to simulator/device

I tend to switch to a ciq3 device to push settings then back to the device I was testing to see the results. 

Ps: Not always but often the failure is shown as “failed to serialise” or similar. 

Sure there's various workarounds for the sim, but I'm more concerned when users see this in the field....

you might see it when the data field is active as I believe pushing the settings needs extra memory to hold the new copy of the settings

but i think it's rather uncommon that people change the settings of the data fields while the data fields are active so personally i don't care too much about being near to the limit (and to be fair in connect iq 1 you have not a lot of option to be not near when you only have 16k)

Yep, I agree.That's my recollection of the original discussion when this was brought up a couple of years ago.

But my (admittedly niche) data fields get a handful of bad reviews stating:

"Seems like a cool idea, but the settings don't work."

It's pretty frustrating, because I feel like the world's worst dev for using all the available memory for CIQ 1 and CIQ 2 devices, in trying to support as many features as possible without creating two dozen different versions of the same app.

I really don't want to set aside / waste precious kilobytes of RAM just to half-support a scenario (pushing settings while the data field is active) which my app *literally does not support by design*. (Even if the settings push was successful, my data field apps won't act on them, because, quite appropriately, I don't want to waste the memory for the code to handle this situation.)

That's why I wish I could just set a flag in the app manifest which says "settings push not supported while data field is active" and let the CIQ app tell the user why it failed. I realize that will never happen for many reasons.

I've mentioned this before, but it's very frustrating that memory is so limited for CIQ devices, yet there are so many things which waste memory. e.g. The fact that settings strings / FIT contributor strings are not even accessed by the data field on the watch, yet actually consume memory at run time, because all of the resources are in the same bucket. Or the fact that once you load a resource, any resource at all, then a certain amount of memory is consumed for the resource table which will never be freed.

It's very frustrating to be constantly thinking about tradeoffs like asking the user to enter CSS codes for colors instead of giving them a drop-down list, simply because of memory issues. The actual strings used by settings in the CIQ / Garmin Connect app should take 0 bytes at runtime, since it's almost 100% likely that the watch app will not reference them. (At least for pre-CIQ 3.2 devices. I suppose the dev of a CIQ 3.2 data field may wish to replicate all their settings in a context menu -- I've been considering it for some apps. But the dev should be given the choice of whether they want/need access to those strings on the watch itself, and not be forced to use memory at run time for no reason, just to support off-device settings configuration.)

So this is obviously a WONTFIX and I suppose the resolution is just "live with bad reviews" or "cut 2-5K of features from data field apps just so users won't complain."

I've made the suggestion in the past to give a developer the option to specify a data field does not support app setting changes while the app runs (I mean I dont even handle onappsettingschanged so i definitely dont want my df to get crashed by an out of memory because of a settings change that i wont handle anyway).

Unfortunately it's not a suggestion that got through as they dont want a developer to be able to use compiler flags on how an app behaves because it make things more complicated

peterdedecker said:

I've made the suggestion in the past to give a developer the option to specify a data field does not support app setting changes while the app runs (I mean I dont even handle onappsettingschanged so i definitely dont want my df to get crashed by an out of memory because of a settings change that i wont handle anyway).

I like the way you think.

peterdedecker said:

Unfortunately it's not a suggestion that got through as they dont want a developer to be able to use compiler flags on how an app behaves because it make things more complicated

I can see that line of reasoning, but from my POV there's so many problems (nearly) beyond our control that get blamed on us. I was just browsing reviews of some popular apps recently, and half the negative reviews were met with replies such as "We're sorry you're having this issue but it's a Garmin problem not an app problem." I feel like this is very frustrating for both devs and users, as users couldn't care less "whose fault it is", and devs get sick of telling users to "apply workaround X" or "pls contact Garmin for help".

I don't know if this is related (probably not, but ...)

I noticed recently that when installing a new data field on my watch or a new version of a data field (from the Garmin App Store using Garmin Express) then if I make changes to the app settings (in Garmin Express) on that first install/update then the settings are completely ignored.

I first had to disconnect my watch from Garmin Express (& I always then ran the activity / data field, only to discover my settings were ignored). Then reconnect back to Garmin Express, change the settings, and this time they would work.

So it seems like if you try and change settings in Garmin Express and that happens to coincide with a new data field update then you won't see your changes ...