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
With the release of Flutter 3.24, the team also released a new version of the shared_preferences lib.
There's no migration required now, but if I quote the README: Consider migrating existing code to one of the new APIs.
We now have two APIs:
SharedPreferencesAsync: a fully async version of the preferences
SharedPreferencesWithCache : shared preferences that are loaded on memory
[SharedPreferences] and [SharedPreferencesWithCache] both use a local cache to store preferences. This allows for synchronous get calls after the initial setup call fetches the preferences from the platform.
[...]
[SharedPreferencesAsync] does not utilize a local cache which causes all calls to be asynchronous calls to the host platforms storage solution. This can be less performant, but should always provide the latest data stored on the native platform regardless of what process was used to store it.
I don't fully agree with the less performant statement, as the current implementation will copy all values on memory (even unimportant ones).
Currently, the code mainly relies on a cache-oriented version, as getters are not async (eg: String getImportance(final String attributeId)).
This is an opportunity to optimize the code and split important data that needs to be cached VS non-important one (eg: are crash reports enabled = only used at startup).
The text was updated successfully, but these errors were encountered:
Hi everyone!
With the release of Flutter 3.24, the team also released a new version of the
shared_preferences
lib.There's no migration required now, but if I quote the README:
Consider migrating existing code to one of the new APIs
.We now have two APIs:
SharedPreferencesAsync
: a fully async version of the preferencesSharedPreferencesWithCache
: shared preferences that are loaded on memoryI don't fully agree with the
less performant
statement, as the current implementation will copy all values on memory (even unimportant ones).Currently, the code mainly relies on a cache-oriented version, as getters are not async (eg:
String getImportance(final String attributeId)
).This is an opportunity to optimize the code and split important data that needs to be cached VS non-important one (eg: are crash reports enabled = only used at startup).
The text was updated successfully, but these errors were encountered: