-
Notifications
You must be signed in to change notification settings - Fork 81
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
WIP: Read-write ROSAF - to replace SAF #376
base: master
Are you sure you want to change the base?
Conversation
Ah, it is mainly about using In longer-term I would drop existing SAF code, keep "ROSAF" and call that one SAF. The only reason for calling it "ROSAF" as I could not find out back then how to implement wrting operations with "url based API". |
I see you had the same thought as I had 😄 |
OK, it seems that writing also works, creating new files/folders fails "only", I will check it when I have time, this seems to be sooo close to work. |
68eeb06
to
618a605
Compare
618a605
to
31adacf
Compare
Note the changes to SAF in commit d0a8dc8. That leads us to a situation where this PR would not be necessary anymore. For now I leave RoSAF. To have that code still available for reference. If sombody has used to gain read-only access that would still be possible. |
(I'm back. I was abroad and only the phone had with me.) So. I've made some test, digged into Android source, and sadly that SAF change to replace listFiles() doesn't have too much effect. :(
The only difference I've found, that new SAF queries all the columns, and it seems that Android caches the results, so new SAF is a tiny little bit faster. Test results (Camera folder with ~500 files):
So in my opinion to speed up SAF for folder listing, we have to cache the query's columns and don't use DocumentFile for the properties (size, etc.), only for delete(), createFile(), createDirectory(), renameTo() etc. It is quite hacky, and eg. renameTo() can only rename a file, can't move it, though it is possible (if I remember correctly) with the lower level API. In this case we have a code, that uses, let say 15% DocFile API and 85% DocContract API, and is 85% idetical with a refactored roSAF, so it doesn't look too great to me. :/ So I still prefer to refactor roSAF. |
ok, makes sense. |
Note: This is currently based on the previous ROSAF PR #373 just to not cause merge conflict, I will rebase as it is necessary.
fixes #178
So I've started to experiment with it:
non-workingfixCurrently:
Renaming fails, but executed in reality, after a refresh I can see the new name (somewhere something calls a getName() on the old filename Uri, my fix should have fixed it, it needs some investigation).My questions are:
Note for myself: