Closed ioantsaf closed 6 years ago
Do you have an example of a use-case where this is necessary? And more importantly, who will actually call these methods? There is no guarantee that the rest of your application will be running at the same time as the provider, so you cannot rely on a service to set these values, for example. The only code that could reliably call these methods is the provider itself. Or am I missing something?
An example would be an Xposed module, that accesses different preference files. The files could be determined e.g. from the package name the module hooks. If the functions are called from the module, on the hooked app's context, the provider's preference files are modified and can be accessed from the module.
I'm confused, you want to call the methods you have added from your Xposed module? The provider is not running in the same process as your module, it is running in the process of your own app. You wouldn't even be able to obtain a reference to the provider. If the provider is running in the same process as your module, then RemotePreferences is not even necessary, just used SharedPreferences.
Edit: Also, the utility of that seems dubious. I would just stuff everything into one preference file and use putStringSet("prefs_for_" + packageName, <key value pairs>)
to hold your settings. Access control for that is well supported already.
When you initialize a RemotePreferences object (new RemotePreferences(context, providerAuthority, prefName");
) for the first time in the handleHookedMethod
of an Xposed module, the Provider is initialized in the context of the module (the original app that created the preferences). That way, you can access preferences created by the module's main app, in Context.MODE_PRIVATE.
I have tried the added methods, and they successfully add preference files to the provider, when called from the handleHookedMethod
of an Xposed module.
Still, if you find it useless to be able to dynamically choose which preference files to access, you can close the pull request, and I'll use my fork for my modules.
Can you provide some sample code that demonstrates what you are doing? I'm still confused as to how you managed to obtain a reference to the provider object from your module.
In the example I have done, I am changing the preference files from within the RemotePreferenceProvider
, using the created functions, by using the onSharedPreferenceChanged
function. That way, I don't directly access the provider from the module, so I think you are right this doesn't apply to the general use case of the library.
Some apps determine the preference files they use on runtime, and their names could also be determined on runtime and be dependent on the environment.
For that reason, it would be good to have functions that can modify the preference names RemotePreferenceProvider allows access to, after the provider initialization.
The purpose of this pull request is to provide public functions able to modify the preference names on runtime.
Added are the functions setPrefNames, getPrefNames, addPrefName, removePrefName, which set, return, add and remove the provider's accessible preference file names.