Feature-request: split the strings.xml for in-device and settings related strings

App can't crash because you can't build it  (Undefined symbol ':StringSymbol' detected).

I've made some test and it is possible to save some memory (but only for ID in rez.strings and strings, peak when changing properties is also a bit less).

But I'm curious how it works since it's from 4.2.x:

- adding scope settings

- building app

- running app on device with 4.2.x, device knows new scope

- running app on device with 3.2.x, device doesn't know new scope so

-- ignores scope so all is in memory optimisation?

-- compiler prepares different version for older firmware? 

App can't crash because you can't build it  (Undefined symbol ':StringSymbol' detected).

I've made some test and it is possible to save some memory (but only for ID in rez.strings and strings, peak when changing properties is also a bit less).

But I'm curious how it works since it's from 4.2.x:

- adding scope settings

- building app

- running app on device with 4.2.x, device knows new scope

- running app on device with 3.2.x, device doesn't know new scope so

-- ignores scope so all is in memory optimisation?

-- compiler prepares different version for older firmware? 

good trick, probably I'll save less, because usually use

var s = Rez.Strings;

WatchUi.loadResource(s.myString).

App can't crash because you can't build it  (Undefined symbol ':StringSymbol' detected).

In my case, it can, because of the way I access the strings. I have

(:typecheck(false))
function loadString(string_id as Symbol) as String {
    return WatchUi.loadResource(Rez.Strings[string_id] as Symbol) as String;
}

And then I call loadString(:my_string), rather than WatchUi.loadResource(Rez.String.myString).

Each call to loadString generates much less code than the corresponding call to WatchUi.loadResource would have done (saves 5 bytes for the call itself, and 14 for the argument) - but yes, I guess it does have the downside that it subverts the compiler's undefined symbol checking.

But I'm curious how it works since it's from 4.2.x:

No device needs to know about the new "scope", because anything with that scope is left out of the .prg file. Settings still work because all the information about the settings is (and always has been) encapsulated in the MyApp-settings.json file (which is sent to the store in the .iq file).