Proposal: Align API with shared_preferences for Hot-Swap Compatibility

[sionzee]

Overview

The encrypted-shared-preferences package offers similar functionality to Flutter's shared_preferences but lacks full API compatibility, making it challenging to swap them seamlessly. Aligning encrypted-shared-preferences with the shared_preferences API would allow developers to use it as a direct replacement without breaking changes.

API Inconsistencies Identified:

1. Missing Methods:

   • containsKey
   • getAll
   • getKeys
   • getStringList
   • setStringList

2. Method Signature Differences:

   • clear: Should accept {Set<String>? allowList}
   • getBoolean: Should be renamed to getBool and return a Future
   • getDouble: Should return a Future
   • getInt: Should return a Future
   • getString: Should return a Future
   • setBoolean: Should be renamed to setBool

Proposal

1. API Compatibility:

   • Implement the missing methods and adapt existing ones to ensure API consistency with shared_preferences.
   • Ensure the methods return the same data types (Future) where applicable.

2. Adopt SharedPreferencesAsync and SharedPreferencesWithCache Approach:

   • Implement both SharedPreferencesAsync and SharedPreferencesWithCache patterns to provide caching and asynchronous behavior, similar to shared_preferences.
   • Consider deprecating any synchronous methods to maintain consistency with SharedPreferencesAsync.

3. Default Values:

   • Instead of providing default values, methods should return null, allowing users to handle them with the null-aware operator (??). This approach aligns with modern Dart practices and simplifies integration.

4. Consistent Asynchronous Behavior:

   • Currently, get methods are synchronous, while set methods are asynchronous. It is preferable for all methods to be asynchronous (Future) for consistency and to handle encrypted operations correctly.

Why This Is Important

• This alignment would enable developers to use encrypted-shared-preferences as a drop-in, encrypted alternative to shared_preferences without requiring additional wrappers or significant code changes.
• By offering a similar API and adopting the SharedPreferencesAsync approach, this package would become a highly valuable, secure storage solution in the Flutter ecosystem.

Side Note

At the moment, we're forced to write a wrapper around encrypted-shared-preferences to implement SharedPreferencesAsync ourselves. This change would eliminate the need for custom wrappers and simplify secure data management in Flutter applications.

Thank you for considering this request!

[xaldarof]

Hi, thank you for your contribution! I didn’t know about the new shared_preferences APIs. I will work on them soon.