dotMorten / WinUIEx

WinUI Extensions
https://dotmorten.github.io/WinUIEx
MIT License
582 stars 37 forks source link

Support WindowEx Persistence in unpackaged apps #61

Closed mikebattista closed 1 year ago

mikebattista commented 2 years ago

Setting WindowEx.PersistenceId in an MSIX app preserves window size and position. This isn't currently supported for unpackaged apps, though.

Would be great if we could support this in unpackaged apps as well that don't use MSIX. I understand that the implementation of Persistence today relies on the ApplicationData API which is only available to packaged apps. How could we support unpackaged apps as well?

dotMorten commented 2 years ago

How could we support unpackaged apps as well?

According to https://github.com/microsoft/WindowsAppSDK/issues/1721#issuecomment-961265459, we are supposed to just use file storage in the AppData folder. However this folder is shared among all apps, and if WinUIEx need to "just work" it would have to somehow uniquely identify each app in a way where they won't overwrite each other - as well as somehow handle cleanup on uninstall. I don't think that is feasible.

If unpackaged apps needs to be supported, we'd need some sort of extension point where the developer can take over and save the settings somewhere, but then most of what WinUIEx does for you wrt this would go away.

ApplicationData is just one of a lot of benefit you get by packaging your apps.

mikebattista commented 2 years ago

We generally strive for parity between MSIX and non-MSIX apps. At least in Template Studio's case, we do provide an unpackaged implementation for local settings that writes to LocalAppData using configurable paths. Not providing settings storage at all because MSIX has a better way to do it is not really an option there, and LocalAppData has been the standard way to do it. Yes I understand the drawbacks compared to MSIX ApplicationData but developers have been dealing with this for years. I wouldn't expect the library to clean up on uninstall, I would expect the app to continue to manage its own LocalAppData.

If WinUIEx contained a similar supporting implementation, I guess one option would be to expose a PersistencePath property that the user could set to instruct the library where to save the settings. The value of the library would be that it's handling a good amount of code and P/Invokes vs. requiring apps to do all that themselves.

https://github.com/dotMorten/WinUIEx/blob/9e4beb4a4e664b68d52f0697f426b93dd211b677/src/WinUIEx/WindowManager.cs#L241-L328

Are there other ways we could allow apps to reuse your code here for saving and restoring window state? In Template Studio's case, the app will have its own local settings storage implementation already, what could a solution look like that didn't require you to implement your own unpackaged implementation for settings storage?

dotMorten commented 2 years ago

I could provide some sort of property bag interface on the window manager - something along the lines of:

public class WindowManager
{
    public static IDictionary<string,object>? PersistanceStorage { get; set; }

Would this work? On a packaged app it would just default to ApplicationData.Current?.LocalSettings.CreateContainer("WinUIEx", ApplicationDataCreateDisposition.Always)?.Values

So in your code you could just initialize it if it is null.

dotMorten commented 1 year ago

Fixed. See https://github.com/dotMorten/WinUIEx/blob/5e179c280788be8f32fa3c95401d741ebcd3c822/src/WinUIExSample/App.xaml.cs#L35 for example