opening settings editor consumes app memory

“In can't access strings like directory/arrays directly but first has to put rez,strings.str1b... to array, how is it possible to take memory, add more code to write and do nothing except”

You can’t access resource strings directly because resources aren’t loaded in memory, as you pointed out. The resource table (which is loaded the first time you call loadResource()) only has resource IDs, not resource contents.

So the contents of your app settings strings don’t take up memory at runtime, but the more strings you have, the more memory is wasted (if you call loadResource()) once. I just don’t understand why the app settings and fit contributor strings need to be in the pool of resources that goes on the device, since the device won’t use them.

If you’re suggesting that there should a way to load all resource strings at once into an array using a single call to loadResource(), this would not be a great design (IMO), because then you’d have a memory spike equal to the size of *all* your strings. In some cases (or most cases), this would be just as bad (or worse) than having all your strings hardcoded in the app.

(As a side note, I often do hardcode strings in my app because calling loadResource() wastes so much memory by loading the whole resource table into memory - this is obviously only for apps where I don’t need resources for anything else and where I don’t want to localize strings.)

it's good that Garmin doesn't load to memory all fonts and bitmaps because they.only exist in resource :-) Of course they afraid about often reading data but who does it? So there dozens of solutions. 

the most strange thing is

- they load all watering to metody

- In can't access strings like directory/arrays directly but first has to put rez,strings.str1b... to array, how is it possible to take memory, add more code to write and do nothing except

"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...

Yes, you are right some are good but some unfortunately not.

I've decide to write my own WF because I couldn't find anything that in 100% met my requirements (and of course I like to write software and to be honest it was a good lesson :)).

The biggest problem is with 240x240 devices, 94kB is a little to small  should be 100 and in my opinion, the size of the screen does not matter in the case of memory, except for buffered bitmaps, but this can be managed by developer (most of the memory is practically occupied by code, data, settings and resources that are practically independent of the device).

Using devices settings probably doesn't solve problem with the peak.

And as usually, any more work and I'll protect app from the problem...