Support Intent.ACTION_OPEN_DOCUMENT_TREE #303
Comments
AndyScherzinger
added
the
needs info
|
Hi @jcgruenhage and thanks for reporting this issue/idea! :) What would be the benefit of implementing this (just curious since I also haven't digged into the Storage Access Framework, so I have no idea what this could then be used for). At the moment we are very busy rewriting the instant upload mechanism to make it work again for Android 7 devices (and some OnePlus devices running the latest OS). No worries about Nextcloud App internal knowledge. If you want to work on this task (even when we are talking mid/end December) @tobiasKaminsky and I are here to help :) The original implementation of the document provider has been done by @przybylski. |
|
The benefit of the Subtree selection is that it allows apps to get access to a folder instead of a file only, so that the app has access to all files and subfolder of a folder, and not only to that single file. |
|
Is there any app which is used and also makes use of such DOCUMENT_TREE feature? |
|
See edit below. This for example is a music player, which supports selecting a different "SD-Card", which essentially is implemented by the subtree selection. That way I could play music from nextcloud directly, with a few seconds delay as the song is loading at the beginning. Alternatively I would need to download everything in advance instead. And I remember one or two times, where an app asked for storage permissions through this, I don't remember what they were though.. Edit: I was wrong, blackplayer only uses this to geht write access to the sdcard.. |
|
I have to admit that even Google Drive does not support this though, and no other cloud Provider that I have tried, which I can't understand, since the API has been around since Lollipop. |
|
Since still has the "need info" label, what information do you need? |
|
I think I fixed it (way less work than I thought, few minutes), but I can't test it right now because somehow webdav won't work, just so no one else has to take a look into this. |
|
Hi @jcgruenhage, my mistake. No open questions regarding the feature (as in to be clarified requirements). Just unclear how this can be implemented (needs research) but if I understand you correctly then you have solved it (locally). |
AndyScherzinger
added
approved
help wanted
and removed
needs info
|
Yes, I (think I) have solved it, just need to get my server fixed before I can test it, should anyone be interested sooner, I could create a fork and upload the untested code, but I'd rather test it first :D |
|
I haven't finished testing it yet (the application I use to test it is based on the JobScheduler, the background process exporting the files can take while to start), but Nextcloud now shows up as DocumentsProvider when selecting a folder. Edit: Looking through the implementation of the DocumentsProvider, it seems as though it is read only in general. @przybylski can you confirm this? (Edit: Nevermind, found that in the PR, it is read only) |
|
in case anyone is interested in the progress till now: https://gist.github.com/jcgruenhage/7de5065b5a9774e9fadb3670a953f669 |
|
@jcgruenhage would you like to have write access to the repo or fork+PR? Anything related to JobScheduler @tobiasKaminsky is our expert :) |
|
@AndyScherzinger i'd prefer fork+PR, this way I can break less :D Anything related to uploading/updating files should be done through the FileUploader, right? My idea would be to copy the files in the private app directory and then tell the FileUploader to do it's thing. What do you think should be done with failed uploads? Just retry until it works? And what about uploads failed due to things like a fully used quota or something like that? The SAF does not provide a way to inform apps that saving a file did not work the way they intended it to. One way could be to move the file to a publicly readable directory and tell the user about it. Does this way sound right to you (@ALL)? |
|
@jcgruenhage fork+PR sounds great, github lately added the ability to give others write access to a PR, so you could even add @tobiasKaminsky and me for any help/collaboration @tobiasKaminsky can you answer @jcgruenhage's questions, since I am not to familiar with the upload mechanisms and how the different scenarios should be handled. As for the retry/error issue in general, if the files are located where the app can access them, then having the upload entry with the failure reason sound fine, since the user can then restart the upload via the Nextcloud app's upload view. |
AndyScherzinger
added
the
needs info
|
I just read a bit more about this, if I understand this correctly, then these steps are still needed:
They are all implemented now, they just don't work as intended yet. This has nothing to do with this issue, but are there any plans of updating gradle, build tools, compileSdk and libraries? Maybe switching to JACK? |
Those will change if it is necessary.
Not planned currently. |
|
Okay, thanks for the info ^^ |
Which means yes, but there are some dependencies regarding Continuous Integration which block compile and lib updates at the moment. |
|
Ok, since I wrote DocumentProvider in nextcloud and owncloud I feel like I can answer this question. If you want to implement openDocument() you need to return a When I was implementing provider I thought of some potential solutions but none of those were perfect. But I can revisit and check what I can come up with this time :) |
|
And about |
|
Quote from the blog post linked above:
This listener is what we need, and you have to specify a handler from which the listener is called, so we can specify the context (using the handler) too. The point where I am stuck at the moment is how to create new files, and sync old ones that were changed. I think I need to call the UploadRequester, but these methods require two additional parameters, an Account and a createdBy int, which I don't know where to get from. |
|
those two parameters are easy to put. Account can be set while constructing and set |
|
@przybylski My problem is not how to put them into the new upload, my problem is where to get them from. I found that the storage manager has a reference to the account I can use, but where do I get the This is the method I am trying to use, from /**
* Call to upload a new single file
*/
public void uploadNewFile(Context context, Account account, String localPath, String remotePath, int
behaviour, String mimeType, boolean createRemoteFile, int createdBy)Is using this to create new files on the server even the right way? I can not find any documentation how to do this, and searching in the source code and using what I find, could be the right thing, or I could end up using some class that is not intended to be used directly or something.. About the ParcelFileDescriptor, I do not plan to extend it, I will just use the other TL;DR:What is the I have set that to 0 for now. |
|
I have committed what I have done until now to my repo: jcgruenhage@41bd045. I tried uploading something, and it got stuck in a loop while apparently trying to download a folder: Checking the path mentioned in the log, there is a text file, containing this: Without downloading the folder, getting it's local storage path returns null, which then prevents me from creating a subdirectory.
Any hints where I should look? |
|
Sorry for spamming this thread, I promise this is the last post for today :D if (mimeType.equals("vnd.android.document/directory")) {
String folderPath = parent.getRemotePath()
+ OCFile.PATH_SEPARATOR
+ displayName;
folderPath = folderPath.replace("//", "/");
new CreateFolderOperation(folderPath, true)
.execute(mCurrentStorageManager, getContext());
return "" + mCurrentStorageManager.getFileByPath(folderPath).getFileId();
}For the full source code, look here: jcgruenhage@aadcbc2 |
you should not download the entire directory, instead create a virtual structure which mimics the internally stored database and give it to the user. Download files if needed.
it depends, is the path valid? if it is not then storage manager will return null, thats why you are getting NPE. Make sure that storage manager is given a correct path. |
Ahh I thought createdBy is about which user created the file, in case there are multiple accounts, thanks :D Now that makes sense.
I meant to "download" the folder itself, not all elements contained in there, or to more specifically, have that the OCFile representing the folder, does not return null when
I would say, that the path that I just created, and that appears online is valid, yes. I first create the path synchronously using this: new CreateFolderOperation(folderPath, true).execute(mCurrentStorageManager, getContext());and then I try to access it using this, which throws the NPE: mCurrentStorageManager.getFileByPath(folderPath).getFileId();What am I doing wrong there, shouldn't it find that folder and it's ID? |
|
Let's move this discussion to IRC, i am using nickname aqu or przybylski on #nexcloud-mobile channel. |
|
I am on freenode, channel #nextcloud-mobile |
|
@AndyScherzinger If I may, I would like to express support for this feature... The GnuCash Android app (which I maintain) could really use the ACTION_OPEN_DOCUMENT_TREE intent. But unfortunately, I haven't found a sync app which supports it - not even Google Drive :( |
|
I am/was working on that, but I have had some problems and no time to work on it, but if there are other people than me, I might start working on it again now ^^ |
|
There are a few other PRs on other project that I need to finish first though, mainly because they are nearly finished :D |
|
Is this going somewhere? It's required for proper Orgzly integration orgzly/orgzly-android#25 (comment), unless Orgzly implements sync with Nextcloud itself via WebDAV or similar… which would be kind of sad. |
|
I know it is not a satisfying answer, but currently we lack on time and therefore this is postponed. |
|
How far along is the support for this? With the latest version from the Play Store, I can select a folder in Nextcloud with the |
|
It works for me with version 3.10. If you can select Nextcloud in |
|
@grote Which app are you testing Nextcloud's implementation of |
|
@alexbakker I am currently facing the same problem, did you guys manage to get this to work somehow? |
|
@flocke No, the issue is still present unfortunately. When using ACTION_OPEN_DOCUMENT_TREE to select a location on the device's storage, everything works fine, but when selecting a location on Nextcloud it fails. I haven't taken the time yet to debug this on the Nextcloud end. |
|
I debugged a little bit more and I get a |
|
The |
|
Should I create a new issue for my findings above, or is this feature known to not be ready for prime time yet? |
|
I think this can be closed as it is implemented and supported. I am currently fixing issues around this though. |
|
Still having the same issue with version 3.13.1. Is this being worked on? |
|
What exactly is the "same" issue? Please open a new issue and fill out template. |
Actual behaviour
In an App requesting access to a directory via the Storage Access Framework and Intent.ACTION_OPEN_DOCUMENT_TREE, the Nextcloud DocumentsProvider is not shown, since it does not support subtree selection.
Desired behaviour
The DocumentsProvider should be shown, and you should be able to select Nextcloud directories.
Android Dev Reference:
If you're implementing a DocumentsProvider and want to support subtree selection, implement isChildDocument() and include FLAG_SUPPORTS_IS_CHILD in your COLUMN_FLAGS.
I could maybe implement that, but it would need a lot of time (which I don't have until around christmas probably), since I know nearly nothing about the Storage Access Framework and how it works, and completely nothing about the internals of the Nextcloud App, so someone else would probably be able to do this faster (and better).
The text was updated successfully, but these errors were encountered: