Maximum size of settings file: bug in simulator or bug in my expectations thereof?

Hi,

Are there any express limitations in either the size or complexity of settings files?

Here's why;

1. I have built a series of DataFields with quite large settings files and extensive lists of preferences

2. They _functionally_ work perfectly... when I load on my watch, they do what they are expected to and respond correctly to settings...

BUT...

3. In the simulator, settings appear to save but in actuality are lost as soon as my DataField starts

In other words, I cannot _TEST_ my settings in the simulator, but I can _RUN_ them on the watch...

This is very irritating and not a little nerve-wracking.

  • What limits are there in the size and complexity of settings files?
  • Is it just a fluke that the thing actually works in the live environment or is it a bug that it doesn't work in the test environment?
  • WHAT CAN I DO TO ALLEVIATE IT?

Haven't seen anything in the docs about limitations.

Thanks,

G

  • How many properties are you using?  While I've not seen it myself, people have posted they've had problems with more than say, 100, and some of that depends on the type (booleans vs strings).

    When you test in the sim, are you using the same target as the device you have?  They reason I ask is you may also have memory problems, where some devices have a limit of 32kb (28kb after the VM grabs some) or 128kb(124kb after the VM grabs it's 4k), and some are higher.

    When you change settings, the peak memory will increase as there's a time where the new settings get merged with the old settings.  You can see where you're at with "view memory" in the sim watching "peak".

  • About 30 settings in all, including some labels, most of those are lists - for example, colour settings where I have a list of all the available colour options.

    I'm running way closer than 4KB to the memory limits... to the point of rewriting methods even to gain ten or fifteen bytes!

    Yes, I use the same targets (where I can). But due to the problems of resetting settings, I have had to resort to launching as a Fenix to store settings and then launching as a 735xt in order to check how close I am on memory when running with those settings...

  • Again, it's also when you change settings, and not only when you run with the current settings.

    I'm most places, the number's you see for max memory already take into accout the VM's 4k - the bottom line of the sim will show 28kb max for example.  But in some places you'll see the max memory being stated as 32kb

  • Again, it's also when you change settings, and not only when you run with the current settings.

    Yep, I get that...

    But...

    The specific settings I have to worry about are to specify values as a string that must be parsed. If I leave these values empty, then I might run with a peak memory of < 24kb but if I set them I might have a peak memory > 28kb.

    In other words, I need to be able to modify and store settings before I can run a valid test as to whether or not it is safe to release to the public.

    (ETA: Because watches run in a separate environment to the apps that modify their settings, the live devices can just read whatever was sent to them without issue.)

  • What you're likely seeing is free memory on a real device can differ a bit from the sim.  It's really only an issue when you're right at the edge memory wise, where a small number of bytes different can push you past the max.

  • It's really only an issue when you're right at the edge memory wise, where a small number of bytes different can push you past the max.

    Quite.

    Welcome to my world!

    However, I am still in the situation where I have no reliable means to modify settings in the sim in order to test the effects on running DF. 

    Although I can  USUALLY  get away with changing to Fenix, then changing back to 735xt, sometimes even that is not enough as the simulator can often decide to just reset my settings entirely. And, no, I cannot  AFFORD the memory of a .println() to see what the values are! And there is  NO POINT checking what the  App Settings Editor says as that will be out of date if the simulator resets it. And the memory inspector only shows the RESULTS, not the inputs.

    So...

    Essentially, I am running blind unless I can test what I need to test on the bigger watch.

  • What you probably need to do is reduce the memory needed for your DF and settings.  Or restrict your DF to devices with enough memory.

  • Or...

    Based on some of the other discussions we've had about settings, I just deleted a single line of code (app.setProperty() during DataField.initialize()) and peak memory plummeted by a good 2kb or so!

    Again, it's also when you change settings,

    I should have paid more attention to this, but I'd kinda forgotten I was writing anything anywhere (or at least, I had one essential write to properties, and didn't see the difference in having two).

    Two, it turns out is one too many!