Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove uncomparable ConfigurationRef wrapper #180

Open
MarijnS95 opened this issue Jan 27, 2025 · 0 comments
Open

Remove uncomparable ConfigurationRef wrapper #180

MarijnS95 opened this issue Jan 27, 2025 · 0 comments

Comments

@MarijnS95
Copy link
Member

This is a comment placed on the strange definition of ConfigurationRef which disables pretty much the only useful feature of it being an owned object rather than a global singleton: being able to compare instances of it.

/// A (cheaply clonable) reference to this application's [`ndk::configuration::Configuration`]
///
/// This provides a thread-safe way to access the latest configuration state for
/// an application without deeply copying the large [`ndk::configuration::Configuration`] struct.
///
/// If the application is notified of configuration changes then those changes
/// will become visible via pre-existing configuration references.
#[derive(Clone)]
pub struct ConfigurationRef {
config: Arc<RwLock<Configuration>>,
}


@rib I don't have any alternative to propose to users to compare configurations besides calling the expensive fn copy() to make a deep-clone of ndk::configuration::Configuration which exactly defeats the purpose of initially making this "cheap to copy".

By having this an updatable RwLock rather than a simple Arc it is no longer possible to compare for configuration differences and prevent possibly expensive reconfiguration/updates in the users' loops. If this was "just an Arc" users could do exactly that while still "cloning" the configuration around cheaply.

In any case, every time the callback fires a new AConfiguration is allocated and filled anyway, rather than "reading into" the existing AConfiguration. But the docs at https://developer.android.com/ndk/reference/group/configuration#aconfiguration_fromassetmanager are incredibly vague by mentioning Create and return a new AConfiguration while it has to take an existing allocated (but possibly new/empty?) AConfiguration.

Originally posted by @MarijnS95 in #164 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant