Conversion from FileSystemDialog family to IStorageProvider family headaches

[trippsc2]

I'm working on converting an app written using Avalonia 10 to using the new IStorageProvider family for handling files. The order of operations that the app is following currently is the following.

1. An OpenFolderDialog is shown and the user provides a folder that may or may not contain existing data.
2. The sub-folder structure is created, if needed.
3. A manifest file is read, if it exists and created if it doesn't.
4. The title of Window is adjusted to include the new folder path.

In trying to convert this workflow to use IStorageProvider, I ran into issues with steps 2 through 4. I don't see a way to create a sub-folder or file inside a folder using an IStorageFolder object directly and the full path is abstracted away, so I can't pass it to the File, Path, or Directory static methods to create folders and files or reference it in the Window title (not critical, but still a downside).

Am I missing an intended way to get this functionality or is this still to be implemented in v11?

[robloo]

Yes, it looks like IStorageFolder is missing a way to retrieve the full path. IStorageItem has TryGetUri() but that won't work unless your folder is always guaranteed to have at least one item. It does look like certain concrete types such as BclStorageFolder have this information though. You might be able to cast to it on the platforms you need (Unstable API though and won't work on all platforms).

Avalonia's API was based somewhat on UWP/WinUI -- which was necessary to work across all platforms in an abstract way. However, WinUI has a lot more properties even on the StorageFolder class: https://learn.microsoft.com/en-us/uwp/api/windows.storage.storagefolder.path?view=winrt-22621 including Path.

@maxkatz6

1. Why did you decide to use Uri instead of a path string?
2. It seems like a good idea to have Path properties in both IStorageItem and IStorageFolder for platforms that have this information.
3. I think we need to add TryGetUri() to IStorageFolder .

[maxkatz6]

Yes, it looks like IStorageFolder is missing a way to retrieve the full path.

There is, a Uri. It might not be a full path though.

It does look like certain concrete types such as BclStorageFolder

Not recommended, it most likely be made private. Instead, new method should be added like "TryOpenFromFullPath" returning folder or file.

Avalonia's API was based somewhat on UWP/WinUI -- which was necessary to work across all platforms in an abstract way.

It's a mix of UWP and Browser APIs. Since UWP one is not compatible with browser sandbox and would have issues with Android.

Why did you decide to use Uri instead of a path string?

AFAIK, that's the best way to tell that file path is relative or absolute. It can be relative on Browser and iOS environments.
Also, that's the best way to tell file scheme. It can be "file://" (like, a normal file in the file system), but also it can be a virtual file - "content://" (by default, android will always return "content" file from the picker, unless you have full access to the system). TryGetUri documentation explains that as well.

It seems like a good idea to have Path properties in both IStorageItem and IStorageFolder for platforms that have this information.

Unfortunately, it's not, see above why.

I think we need to add TryGetUri() to IStorageFolder .

TryGetUri is defined on IStorageItem and IStorageFolder inherits it. So this method should be available on every platform.

[maxkatz6]

I don't see a way to create a sub-folder or file inside a folder using an IStorageFolder

Creation of subfolders and files can be added to the API. As folder pickers gives full temporary access to the folder content on all platforms. On some platforms you might need to sandbox this folder if you want to read it later (browser, ios and android depending on the version).

[trippsc2]

@maxkatz6 Thanks for clarifying this. Is there any documentation I can refer to on sandboxing the filesystem on those platforms?

Does adding mobile/browser support present any changes in implementation for data persistence or can it still be implemented as documented on this page? https://docs.avaloniaui.net/guides/deep-dives/reactiveui/data-persistence

[maxkatz6]

Is there any documentation I can refer to on sandboxing the filesystem on those platforms?

I believe it's OS specific and you need to see documentation per platform.

We only have macOS specific, which is slightly out of dated as doesn't mention net6-macos packaging:
https://docs.avaloniaui.net/docs/distribution-publishing/macos#app-store-packaging
Or in general:
https://developer.apple.com/documentation/security/app_sandbox

For mobile or browser platform you don't need to do anything special. It will force app to be sandboxed.

[maxkatz6]

Does adding mobile/browser support present any changes in implementation for data persistence or can it still be implemented as documented on this page? https://docs.avaloniaui.net/guides/deep-dives/reactiveui/data-persistence

It's not really related to Avalonia, instead ReactiveUI specific. But in the end, it's all just about implementation of ISuspensionDriver.
Ideally, I believe it's not affected by IStorageProvider at all, as app usually doesn't ask where to store its own state. Instead dedicated directories with write access are used. I.e.:

• For Windows it's %LocalAppData%/app-identifier
• For macOS (and I believe for iOS) it's usually ~/Library/Application Support/app-identifier
• For android it's /data/data/your.package/files (ContextWrapper.getFilesDir() native API)
• For linux not sure, but I suppose you still will have access to the app folder.
• localStorage for Browser (technically more like a key-value storage and not a file system)

Saving state in the current app folder not always is the best choice. As it will be shared across users and app might not have write access there, if it's sandboxed (in case of Windows modern MSIX packages).