Propagate activity config changes to library authors on Android

[itsramiel]

Hi,

I would like to be able to listen to config changes to the main activity in android in a native module.

As far as I know I am able to listen to activity config changes by overriding the activity's onConfigurationChanged method. However, since that is part of the app and not my native module then I cant edit this part.

Library Users can manually emit that change (using intents as an example) as done in react-native-locale-listener, but it is inconvenient.

import android.content.res.Configuration;
import android.content.Intent;
...
@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);
    Intent intent = new Intent("onConfigurationChanged");
    intent.putExtra("newConfig", newConfig);
    this.sendBroadcast(intent);
}

I see that ReactActivity already overrides this method for some internal use cases I believe:
https://github.com/facebook/react-native/blob/4076dbfc8651fcd193b886bf63b23728fad466d7/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactActivity.java#L141-L145

I think it would be really convenient if somehow this listener can propagate the event to library authors.

Example use case

Listen to app locale changes which results in a onConfigurationChanged on the activity

Let me know your thoughts

[itsramiel]

I thought some react native apis must for sure listen to config changes, so I can implement that in a similar way.

Indeed the Appearance module needs to know when the config changes and what is done there is that a onConfigurationChanged is defined on the Appearance class
https://github.com/facebook/react-native/blob/4076dbfc8651fcd193b886bf63b23728fad466d7/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/appearance/AppearanceModule.kt#L79-L85

and being called in ReactInstanceManager:
https://github.com/facebook/react-native/blob/4076dbfc8651fcd193b886bf63b23728fad466d7/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java#L918-L930

and ReactHostImpl:
https://github.com/facebook/react-native/blob/4076dbfc8651fcd193b886bf63b23728fad466d7/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/runtime/ReactHostImpl.java#L776-L788

so I cant do that for my native module

Can we make config changes accessible to modules?

[cortinico]

Have you considered asking users to edit the onConfigurationChanged in the Activity class as such?

override fun onConfigurationChanged(newConfig: Configuration) {
  super.onConfigurationChanged(newConfig)
  MyCustomLibrary.dispatchOnConfigurationChanged(newConfig)
}

That will allow to listen for config changes on the library.

Also you could use an expo config-plugin to achieve this same result without having to ask the user to manipulate their file at all.

[itsramiel]

Yes, I did consider editing the MainActivityas shown in the snippet of first comment( uses intents as an example but yeah invoking a method on the module is another). However I would have loved to make the lib integration as easy as possible without editing native code.

Yes expo config plugin is convenient for expo users, but not everyone uses expo.

From an architectural point of view, isnt it better to have a generic way to react to config changes compared to how it is done with the Appearance module?

Do you see it feasible to provide an api for library authors(including rn internals) to observe config changes without library users having to edit their code?

[cortinico]

From an architectural point of view, isnt it better to have a generic way to react to config changes compared to how it is done with the Appearance module?

Not really because this is Android specific, so we'll have to have a JS api that is un-implemented in iOS, win, mac etc.

I'd say the onConfigurationChanged way seems like the simplest approach to me.

[itsramiel]

Not really because this is Android specific

Exactly I was thinking an api within ReactAndroid not a js api

[cortinico]

I don't think we'll implement anything like that as it would mean also implementing similar APIs for any onXXX event of the Activity lifecycle, which are several.