Instead of using
edit.commit();, you should use
edit.apply();. Apply will update the preference object instantly and will save the new values asynchronously, so allowing you to read the latest values.
Commit your preferences changes back from this Editor to the
SharedPreferences object it is editing. This atomically performs the
requested modifications, replacing whatever is currently in the
Note that when two editors are modifying preferences at the same time,
the last one to call commit wins.
If you don’t care about the return value and you’re using this from
your application’s main thread, consider using apply() instead.
Unlike commit(), which writes its preferences out to persistent
storage synchronously, apply() commits its changes to the in-memory
SharedPreferences immediately but starts an asynchronous commit to
disk and you won’t be notified of any failures. If another editor on
this SharedPreferences does a regular commit() while a apply() is
still outstanding, the commit() will block until all async commits are
completed as well as the commit itself.
As SharedPreferences instances are singletons within a process, it’s
safe to replace any instance of commit() with apply() if you were
already ignoring the return value.
You don’t need to worry about Android component lifecycles and their
interaction with apply() writing to disk. The framework makes sure
in-flight disk writes from apply() complete before switching states.