Under Review
over 1 year ago

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

In most of the apps I've seen most of the strings are used for settings, still those strings are included in the memory footprint of the app. It would be very useful to split strings.xml to device-strings.xml and settings-strings.xml.

  • I can't edit the original post, but actually there's a 3rd type of string: only used in fit translations. So ideally we should be able to differentiate at least between these classes of strings:

    foreground (device)
    background (device)
    settings
    fitcontributor

    and I guess it would be useful if the device strings could also be used in settings / fit OR there would be a way to enumarate multiple values of this enum on each string.

  • I'll throw in one more idea. It's similar to scopes, but with different logic: if we could use annotations and excludeAnnotations then it would be very easy to set the strings up, if it's used in code that uses some annotations we could annotate the string with the same annotations, and only the relevant strings would be included in the prg, depending on the monkey.jungle. This would also enable us decrease the memory footprint, and also to keep all the strings in 1 file (resources and resources-<lang>) as opposed to split them with some complicated monkey.jungle juggling. And it would also make translation easier because all the strings could be kept in 1 file.

  • Maybe it could be easier fixed and in a way that is easier to be backwards compatible: add new scopes: settings, fit and maybe device? And of course the default would be: app.
    Scope: settings, fit are pretty self explanatory. I'm not sure about the 3rd one (device), but what I meant is what @FlowState wrote about the AppName, that is almost never used inside the app, probably only in the device when it's a widget's name. So it should be in the prg but should not allocate a memory slot in the Global.Rez.strings table.

  • yes, I've just want to write the same:

    - can be check during compiling if I use Rez.strings item.

    - saving only for ID but better anything than nothing

  • Same issue applies to other strings that are probably never used by the app, like:

    - the string for the app name

    - strings for FIT contributor labels

    So to be precise, "settings-strings.xml" would really by "non-device-strings.xml" (or something like that.)

    Basically any resource that's only needed for the store (and not the app at runtime), should be allocatable to a separate resource area, at the developer's discretion.