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.

I'm not new to settings but again surprised how it can be done this way... As I mentioned there is time to merge it outside app and call onSettingsChanged after this. If user change settings from app, ok it can be peak but not when system does.

> A few booleans is cheaper than a number of strings for example

It depends, if somebody nam key "very_long_property_key_id.................................." event bool may weigh in property and in code:)

But I understand, it's by design.

Yes.  You must be new to app settings.  When new settings are sent to a device, both the old and new settings are in memory at the same time while things are merged, and that's why there is a peak.

One thing that determines that is the number and type of settings involved.  A few booleans is cheaper than a number of strings for example

FIRST
What happens when I change settings on device?
- go to IQ Connect
- run settings
- save
- something is transferred to device and saved somewhere
- system calls onSettingsChanged()
- now app can read new settings
So, where is my "work" to make peak - nowhere. How to manage memory if I don't have any control on huge object. System inject data and kills app.
SECOND
Settings - dictionary and it is in memory and consumes it from the app start (and for this reason you have less memory than totalMemory, so if you have 94kb totalMemory from the start is 92 because 2kB takes settings). There is no need to keep 2 dictionary settings in one time (another thing is that the data accessible by services - getProperty - should be in the service/system memory not application, the application can save data in storage and this is its data. All the luck that the data from the storage is not in memory). Apps settings are members, globals etc. Nobody read settings in loop but only after onSettingsChanged and now not in lowpower. So it's easy to chenge settings without any peak even in app memory.

But it means - everybody using setting have to remember to make free memory = 2xSizeSettings, so typically 4kB~5%... And of course - code ~40kB  and heap and data...

When you select the eclipse app settings editor and select something, things start  The current settings get transferred, and that explains what you are seeing.

When you change something in the editor and save it, that will cause a larger peak,