In PR #17, the package was changed to use SharedPreferences for managing the StoreManager instead of Hive. This causes a critical issue for users who rely on SharedPreferences to handle their app's configurations.
Consider the following lines of code:
|
Future<void> init() async { |
|
final sharedPrefs = await SharedPreferences.getInstance(); |
|
final keys = sharedPrefs.getKeys(); |
|
for (final key in keys) { |
|
final value = sharedPrefs.getString(key); |
|
if (value != null) _events[key] = value; |
|
} |
|
|
|
return super.init(); |
|
} |
The package loads all preferences instead of only those specific to the package, which can lead to misleading information. Additionally, it uses sharedPrefs.getString(key), which may cause the app to crash if any configuration is not a String.
I understand that we can change this using the storage parameter, but I don’t think it’s a good idea to have a default option with such critical issues.
My proposed solution is to continue using Hive, but switch from hive to hive_ce.
In PR #17, the package was changed to use
SharedPreferencesfor managing theStoreManagerinstead ofHive. This causes a critical issue for users who rely onSharedPreferencesto handle their app's configurations.Consider the following lines of code:
aptabase_flutter/lib/storage_manager_shared_prefs.dart
Lines 8 to 17 in 8aff3da
The package loads all preferences instead of only those specific to the package, which can lead to misleading information. Additionally, it uses
sharedPrefs.getString(key), which may cause the app to crash if any configuration is not aString.I understand that we can change this using the
storageparameter, but I don’t think it’s a good idea to have a default option with such critical issues.My proposed solution is to continue using Hive, but switch from
hivetohive_ce.