Locale changes and the AndroidViewModel antipattern

Jose Alcérreca
Android Developers
Published in
2 min readApr 2, 2019

TL;DR: Expose resource IDs from ViewModels to avoid showing obsolete data.

In a ViewModel, if you’re exposing data coming from resources (strings, drawables, colors…), you have to take into account that ViewModel objects ignore configuration changes such as locale changes. When the user changes their locale, activities are recreated but the ViewModel objects are not.

The localized string is not updated after a locale change

AndroidViewModel is a subclass of ViewModel that is aware of the Application context. However, having access to a context can be dangerous if you’re not observing or reacting to the lifecycle of that context. The recommended practice is to avoid dealing with objects that have a lifecycle in ViewModels.

Let’s look at an example based on this issue in the tracker: Updating ViewModel on system locale change.

The problem is that the string is resolved in the constructor only once. If there’s a locale change, the ViewModel won’t be recreated. This will result in our app showing obsolete data and therefore being only partially localized.

As Sergey points out in the comments to the issue, the recommended approach is to expose the ID of the resource you want to load and do so in the view. As the view (activity, fragment, etc.) is lifecycle-aware it will be recreated after a configuration change so the resource will be reloaded correctly.

Even if you don’t plan to localize your app, it makes testing much easier and cleans up your ViewModel objects so there’s no reason not to future-proof.

We fixed this issue in the android-architecture repository in the Java and Kotlin branches and we offloaded resource loading to the Data Binding layout.

--

--

Android Developers
Android Developers

Published in Android Developers

Articles on modern tools and resources to help you build experiences that people love, faster and easier, across every Android device.

Jose Alcérreca
Jose Alcérreca

Written by Jose Alcérreca

Developer Relations Engineer @ Google, working on Android

Responses (16)