0

We have a localization module in our projects, We only maintain one default string folder, The localisation module keeps string value in dB for all the supported languages, and we have extended the Resource class.

    @Override
public String getString(int id) throws NotFoundException {
    String value = null;
    try {
        value = getStringFromRepository(id);
        if (value != null) {
            return value;
        }
    } catch (Exception ex) {
        
    }
    return super.getText(id).toString();
}

and keeps the LRU cache, and loads/sync from the Network in the app start-up when needed and when the language is changed. Network sync is done asynchronously on the background thread.

Load from cache and DB lookup is done on UI, It is giving ANRs.

I think they have probably done it to save on the initial app installation size.

The Android recommended and the simple way is to keep lang-wise string resources in the res folder. I want to know more, about how it internally manages and loads the correct string values to the texts, in order to reevaluate our existing implementations.

Vikas Pandey
  • 1,115
  • 1
  • 15
  • 25
  • You'd need to show us the code of getStringFromRepository. But if you're getting ANRs, it's because you're taking too much time on the main thread and not passing control back to the looper. If getStringFromRepository is a synchronous local DB lookup, that can be bad. If it's a remote db lookup on the server, that's never going to work- WAY too long. In that case you'd need to make EVERY call to the network happen off main thread and cache the result, you can NEVER do a networking call on the main thread. – Gabe Sechan Mar 10 '23 at 06:06
  • Basically, if any lifecycle method, including onCreate, onStart, or onResume ever take more than 2 seconds, you're going to get an ANR. If you're making a synchronous network call in any of them, especially a somewhat lengthy one like downloading a database of localized strings, you're going to fail the watchdog timer. You'll need to rearchitect how your localization works, or provide some way of asynchronously binding text values after they're downloaded asynchronously. Which could be done via reactive code, but you'd be rearchitecting how your front end works instead then. – Gabe Sechan Mar 10 '23 at 06:13
  • Actually by default an attempt to do networking on the main thread will crash the app, so you know you're doing something wrong. You have to explicitly turn that behavior off. If you ever see code doing that, you know the people who wrote it don't know what they're doing. – Gabe Sechan Mar 10 '23 at 06:14
  • Network sync-up is done on the Background thread, sorry for my mistake while putting the question. the rest cache lookup and then DB lookup is done on UI thread. Edited my question. – Vikas Pandey Mar 10 '23 at 06:37
  • What's the best way to do the localization, given we have thousands of strings? If I keep all those language strings in resources, It will increase the app size? – Vikas Pandey Mar 10 '23 at 06:39
  • Thanks a lot, @GabeSechan for trying to help here. and yes We are thinking of using binding adapters can be one way to asynchronously load the string to text view. – Vikas Pandey Mar 10 '23 at 06:52
  • 1
    Yes, strings add to the size of the app. But not by all that much. Let's say you have 1000 strings, an average length of 100 byes (50ish unicode characters). Let's say you have it in 30 languages. That would be 1000*100*30, or a bit under 3 MB. A single png photograph would be bigger. You can save space that way, but it's probably not the best place to start with. It's more of an argument if the content is too dynamic. Generally apps use the built in system for fixed strings, and use over the network values for content. – Gabe Sechan Mar 10 '23 at 07:56
  • whenever we ad a new string, we add it to the default ( the English ) string file and tell another team to update those strings with translation into some panel. – Vikas Pandey Mar 10 '23 at 10:02
  • 1
    What I have seen a lot of teams do when they want to maintain the same translations across multiple platforms (Andriod, iOS, web, etc) is keep it in a server side db and have a process that writes the strings.xml files and checks them into source control when there's new data (like once a day or so). That may be the type of thing they should have built. That keeps the translations in a single place and consistent, but uses the platform's existing systems. – Gabe Sechan Mar 10 '23 at 15:02
  • Now I realize, Sometime in the app in some API we just get a string resource id that is dynamic, so we might not have that id in the resource files that are shipped with the app installation, that seem like a valid reason to keep the strings in the remote. – Vikas Pandey Mar 10 '23 at 16:54

0 Answers0