[Android] Essentials - preferences - prevent Application.Quit() from closing application before SharedPreferences in-memory changes are committed to disk.

[bricefriha]

Description of Change

Currently, if we use Application.Quit() after Preferences.Set(), the data is not saved.
The reason for this (as mentioned in the issue) is that we are using SharedPreferences.Editor.apply(), which write in memory asynchronously, therefore if we run Application.Quit() just after that. We run the issue of exiting the program before the data gets written in memory.

Using SharedPreferences.Editor.Commit()`, on the other hand, ensures the data is being fully saved before we quit.

Changes

Adding an commit argument to the Preferences.Set() API to allow the user to choose whether to use editor.commit() or editor.Apply() at the end of the process.

.

By default, it will trigger editor.Apply().
This argument is only offered on Android.

Issues Fixed

Fixes #27585

[NathanielJS1541]

Sorry, I know I'm not a maintainer but wanted to throw in my two cents. I'm not sure changing calls from Apply() to Commit() is the right call here, as it will have a performance impact since it blocks until the preference is written to disk. If apps write lots of preferences in a batch, blocking for each one could have a negative impact on app performance. Remember my repro sees the app go down before a single preference is written, so this degradation of performance could be pretty severe.

I think finding a way to modify Application.Quit() to properly ensure that the Android lifecycle events are serviced (which should take care of waiting for in-memory changes to be committed) would be preferable to changing the way the preferences are saved.

Alternatively, adding something to the MAUI Preferences API like Preferences.Commit() or Preferences.EnsureSaved() could be an option. Then you can keep the performance benefit of using Apply(), and just call Preferences.Commit() before quitting the application to ensure changes are on disk (or enforce a call from Application.Quit() itself).

Edit: Thinking about it, the Preferences.Commit() method doesn't need to be part of the public API if it's only going to be called from within Application.Quit()...

[bricefriha]

@NathanielJS1541 Thanks for your input.
You're right. I'll take a look.

[NathanielJS1541]

I'll take a look.

It's all good! Sorry to be a pain. I will say that I spent a long time looking for alternatives to Environment.Exit(0) used in Application.Quit() here, but couldn't find anything that seemed to fix #27585.

The only thing I managed to find was this (taken from #27585):

It's also worth noting that calling Application.Quit() doesn't cause the OnDestroy() delegate to be invoked either. Using something like Platform.CurrentActivity.FinishAffinity() does cause the OnDestroy() delegate to be invoked, but it still won't ensure that SharedPreferences edits are committed to disk before the app closes.

I'm not that experienced with android app lifecycles though, so it could be something obvious.

[bricefriha]

@NathanielJS1541, thanks for the details on that.

It's all good! Sorry to be a pain

Don't worry, I'm enjoying investigating this. So you're not a pain at all.😁

[MartyIX]

Just a note: Adding new public methods is allowed but such a change will most likely not be accepted for MAUI .NET 9. It can be merged in MAUI .NET 10. Just to warn if you want your PR to be merged in the .NET 9 branch.

[bricefriha]

I see. Even if these are just different signatures?

[MartyIX]

I'm not a part of the MAUI team, so they might tell you differently but if you want my honest opinion based on experience of reading many MAUI's PRs, then: Yes.

[bricefriha]

Thanks, I appreciate you're sharing your opinion.

Well, we'll see, I just can't see how we can solve this issue otherwise if I'm honest.

[bricefriha]

@dotnet-policy-service agree