Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AndroidPreferences.flush() has no way to enforce synchronous saving #7351

Closed
1 task done
LobbyDivinus opened this issue Feb 26, 2024 · 2 comments
Closed
1 task done

Comments

@LobbyDivinus
Copy link

LobbyDivinus commented Feb 26, 2024

Issue details

Hi, in my game I used to call restart immediately after storing some settings using the Preferences.flush() method. According to its doc

Makes sure the preferences are persisted.

this should work. However, it resulted in the settings not being saved. The reason being that the underlying SharedPreferences.apply() used on Android does not guarantee actual file saving. Instead it only kicks off an asynchronous saving process.

Reproduction steps/code

val pref = Gdx.app.getPreferences("test")
pref.putString("hi", "mom")
pref.flush()
System.exit(0)

Solution

For now my fix is to simply add some waiting time in between flushing and app restart. However, a nicer solution would be to have a Preferences.flush(boolean sync) method that would call SharedPreferences.commit() in case of sync being true on Android.

Version of libGDX and/or relevant dependencies

1.12.1

Please select the affected platforms

  • Android
@obigu
Copy link
Contributor

obigu commented Mar 10, 2024

SharedPreferences handles android lifecycle phase changes automatically. The problem here is you're killing the process which ignores the Android lifecycle and can cause the kind of issues you describe.

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.

Without knowing the details of your use case, generally speaking, restarting an Android app due to a settings change is not a good practice.

On the other hand SharedPreferences has some limitations that are overcome by some more modern alternatives such as Jetpack DataStore. I think it'd be a nice contribution to add a new alternative (and optional) Android Preferences DataStore based implementation.

@LobbyDivinus
Copy link
Author

Thanks for the response. Well, I guess I have too much static state. At some point it makes sense to just restart the whole app instead of proper cleanup. Though I consider to do it it properly now.

@obigu obigu closed this as completed Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants