opening settings editor consumes app memory

Slightly off-topic, but IMO, the worst design decision that was made regarding app settings was to have the strings for app settings as part of the CIQ app’s resource table.

This means that if you call loadResource() at least once in your app, then each of your settings strings consumes memory at run-time in the resource table (although at least it’s a fixed amount of memory per string — the content of strings themselves doesn’t take up memory.)

Same goes for FIT contributor string resources.

I don’t understand why there couldn’t have been a separate resource section for strings that the app doesn’t actually need at run-time, on the watch. Then you could put your app settings strings here, as well as FIT contributor strings. This would’ve been really helpful for old watches which only have 16 KB for data fields, and even for those current watches which only have 32 KB.

I also feel like this change could still theoretically be made — it seems it would require a change to the compiler and the store infrastructure, but not the watch firmware itself, so it could be done even for older watches which would benefit most from this improvement. But I’m pretty sure it would never happen.

Slightly off-topic, but IMO, the worst design decision that was made regarding app settings was to have the strings for app settings as part of the CIQ app’s resource table.

This means that if you call loadResource() at least once in your app, then each of your settings strings consumes memory at run-time in the resource table (although at least it’s a fixed amount of memory per string — the content of strings themselves doesn’t take up memory.)

Same goes for FIT contributor string resources.

I don’t understand why there couldn’t have been a separate resource section for strings that the app doesn’t actually need at run-time, on the watch. Then you could put your app settings strings here, as well as FIT contributor strings. This would’ve been really helpful for old watches which only have 16 KB for data fields, and even for those current watches which only have 32 KB.

I also feel like this change could still theoretically be made — it seems it would require a change to the compiler and the store infrastructure, but not the watch firmware itself, so it could be done even for older watches which would benefit most from this improvement. But I’m pretty sure it would never happen.

"Regarding the slightly off topic.... imho they should give the developer the choice to not use resource strings for app settings and allow to just hardcode strings, that would solve so many issues..."

That would be another solution. I'm guessing the reason that app settings and fit contributor strings are resources as opposed to hardcoded strings is so they can be localized. I still don't see anything preventing Garmin from having a *separate* resource section that's only for (off-device) app settings strings and FIT contributor strings. The app literally does not need those strings on the device, especially for old watches which do not support on-device settings (which would also benefit the most from this change.)

Just have a new resource qualifier: e.g. "resource-offdevice" (but ofc with a much better name.) Only strings are allowed, and everything in this section gets sent to the store but not the device.

Afaict, this is one of the few architectural changes that Garmin could make which could potentially benefit all devices, no matter how old, since it doesn't seem to require any firmware updates.

I have a data field app which has a theme color setting - on devices with 64 KB and more, it's a dropdown, as you'd expect. But this consumes precious memory due to the string resources used for the enum values. So for devices with 32 KB and less, I ask the user to enter a CSS color code that they have to look up the docs. This is the kind of embarrassing workaround I would love to avoid.

Regarding the slightly off topic.... imho they should give the developer the choice to not use resource strings for app settings and allow to just hardcode strings, that would solve so many issues...

The memory needed for app settings is something you need to consider when designing and building an app. 92k is actually on the larger size for a watch face, where the fr45 only allows 48k, and others, 64k.

Garmin itself writes many CIQ apps using the same stuff we use.

Solution is simple, Garmin should use the same things offerers developers and see how is difficult is to write something more than time/date and 2 notification with 94kB - 70kB for system things

For example, I have an app that doesn’t load resources, so the number of settings strings don’t affect the amount of memory used at runtime. I had an opportunity to try to save memory by moving some fairly large fixed data into a JSON resource. But as soon as I call loadResource, the whole resource table is loaded into memory permanently, which includes memory for the app settings string entries.

My app actually uses *more* memory after moving data into a JSON resource.