4 ms·

This sounds like the user has to navigate to the file from the app’s file picker each time they want to open the file, instead of being able to open the file fr

by layer8 2y ago

This sounds like the user has to navigate to the file from the app’s file picker each time they want to open the file, instead of being able to open the file from the Files app. This would also mean that the app can’t maintain a “recent files” list (or bookmarks) for the user to be able to quickly reopen a previously opened file, because that wouldn’t be going through the file picker.

tadfisher 2y ago
That is not true; you can hang on to the content URI and metadata to present a Recent Files UI. You need to ask for a persisted write permission for the content URI. You can even use the ContentResolver to check the file's existence and update the metadata (including thumbnail).
- iggldiggl 2y ago
  Although AFAIK Android's implementation then means that you can end up with duplicate entries for the same file if you open it through differing means (like both through an external file manager as well as within the app's own UI), because those result in distinct content URIs and there are no official APIs that would allow you to confirm whether two separate content URIs are actually pointing to the same file (where that'd make sense, e.g. for files on the local file system at least [1]). [1] I think there are some hacks to work around that issue, but obviously they aren't guaranteed to work all of the time.