opening settings editor consumes app memory

"I don't agree  because as you noticed, when you load one string all strings are loaded. why? by design... probably"

No, when you load one resource, the whole *resource table* (Rez) is loaded permanently. This doesn't load all the strings. If it did, then there would be no memory savings at all by using resources. But there's significant memory savings (assuming your app uses all the resources), because they don't all have to be loaded at once.

The problem is that the resource *table* is loaded all the time, and it contains all the entries for app setting strings and fit contributor strings, which the app does not need.

So say you have 50 strings for app settings, that's 50 x 12 = 600 wasted bytes. It doesn't matter how short or long those strings are, it will always be 600 bytes. Even 100 bytes is a lot for a Garmin app.

"I don't agree  because as you noticed, when you load one string all strings are loaded. why? by design... probably"

No, when you load one resource, the whole *resource table* (Rez) is loaded permanently. This doesn't load all the strings. If it did, then there would be no memory savings at all by using resources. But there's significant memory savings (assuming your app uses all the resources), because they don't all have to be loaded at once.

The problem is that the resource *table* is loaded all the time, and it contains all the entries for app setting strings and fit contributor strings, which the app does not need.

So say you have 50 strings for app settings, that's 50 x 12 = 600 wasted bytes. It doesn't matter how short or long those strings are, it will always be 600 bytes. Even 100 bytes is a lot for a Garmin app.

So it's good news that only *table* is loaded

There several "type" of strings:

- system - for settings, properties, app name etc - nothing to do

- text for users, usually language dependent

- "data"  you can put any data into string and convert to number, double etc

Solution depends on situation, but you can do always one thing. When app starts, you have a lot of memory so you can put all non system string in one and parse it and insert into storage at form match your requirements (e.g. months/weekday into array of string). After then you can access string as you want without loading rez/strings any more (or rather to time when you don't change strings).

No I've cleared my code and save a few kB so it's ok, The problem is with new SDK e.g new memory bomb e.g. connectionInfo 332b adding to getDeviceSettings...

And also 2 thing CONST and ENUM, it is incredible that it consumes memory they are common variables so why somebody add? For autnum of enum? To save memory we need #define statement which puts defined values  into code...

But subject of this thread is settings. Why there is the peak? If I have several WF and somebody change settings in non active WF system cane do it so why there is the peak if app runs? Why settings can't run like strings?