This proposal is for adding support for the Settings API in Android.
Details
The Settings object is currently iOS only. It would be valuable to provide an Android interface to SharedPreferences ( similar in intents to NSUserDefaults, the backing store used on iOS ). Doing so would let developers use the platform appropriate non-secure KV storage object w/o having to involve a separate third party library for Android.
Discussion points
Is there value in adding this to React Native core? Currently Settings exists in core, but it could be inferred based on other portions of core that Settings might be eventually migrated to a @react-native-community project, in which case the effort of adding the code to core would likely be better spent creating a separate module.
Does SharedPreferences correctly match the intent of NSUserDefaults?
Does the semantics of Settings as it stands now correctly map to both NSUserDefaults and SharedPreferences, or is Settings truly intended as an iOS only mapping that should not map to Android?
Would promoting Settings to both Android and iOS cause other platforms ( web, Windows, et al ) to feel the need to provide a similar interface, and possibly create an unintentional requirement where a React Native platform must also have a user-local KV storage object? While I suspect each platform may have something that looks similar to NSUserDefaults and SharedPreferences, I would also find it believable that the semantics of each are different enough that implying a false uniformity could be dangerous to users.
Introduction
This proposal is for adding support for the
Settings
API in Android.Details
The
Settings
object is currently iOS only. It would be valuable to provide an Android interface toSharedPreferences
( similar in intents toNSUserDefaults
, the backing store used on iOS ). Doing so would let developers use the platform appropriate non-secure KV storage object w/o having to involve a separate third party library for Android.Discussion points
Settings
exists in core, but it could be inferred based on other portions of core thatSettings
might be eventually migrated to a@react-native-community
project, in which case the effort of adding the code to core would likely be better spent creating a separate module.SharedPreferences
correctly match the intent ofNSUserDefaults
?Settings
as it stands now correctly map to bothNSUserDefaults
andSharedPreferences
, or isSettings
truly intended as aniOS
only mapping that should not map to Android?Settings
to both Android andiOS
cause other platforms ( web, Windows, et al ) to feel the need to provide a similar interface, and possibly create an unintentional requirement where a React Native platform must also have a user-local KV storage object? While I suspect each platform may have something that looks similar toNSUserDefaults
andSharedPreferences
, I would also find it believable that the semantics of each are different enough that implying a false uniformity could be dangerous to users.