You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)]
pubstructConfigurationRef{
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.
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.android-activity/android-activity/src/config.rs
Lines 9 to 19 in 0d29930
@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 ofndk::configuration::Configuration
which exactly defeats the purpose of initially making this "cheap to copy".By having this an updatable
RwLock
rather than a simpleArc
it is no longer possible to compare for configuration differences and prevent possibly expensive reconfiguration/updates in the users' loops. If this was "just anArc
" 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 existingAConfiguration
. But the docs at https://developer.android.com/ndk/reference/group/configuration#aconfiguration_fromassetmanager are incredibly vague by mentioningCreate 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)
The text was updated successfully, but these errors were encountered: