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.

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

    I would guess that it just builds all the PRGs without the string resources specified with the settings scope. Any resource string that's only for settings would only need to go in the metadata that gets sent to the store for use by the Connect app.

    I tried it myself: added some strings to a demo project, built the PRG for fr235, then changed the scope for those strings to settings and built the PRG again. The 2nd PRG is smaller, and a hex diff of the two files shows that the first PRG contains those strings and the 2nd one does not.

    In other words, as discussed years ago, it's a compile-time change which every device can benefit from.

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

    I would guess that it just builds all the PRGs without the string resources specified with the settings scope. Any resource string that's only for settings would only need to go in the metadata that gets sent to the store for use by the Connect app.

    I tried it myself: added some strings to a demo project, built the PRG for fr235, then changed the scope for those strings to settings and built the PRG again. The 2nd PRG is smaller, and a hex diff of the two files shows that the first PRG contains those strings and the 2nd one does not.

    In other words, as discussed years ago, it's a compile-time change which every device can benefit from.

Children
No Data