Skip to content
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

Enhancement: Use Android 4.4 Document Provider API #296

Closed
pulser opened this issue Nov 2, 2013 · 30 comments
Closed

Enhancement: Use Android 4.4 Document Provider API #296

pulser opened this issue Nov 2, 2013 · 30 comments
Assignees
Milestone

Comments

@pulser
Copy link

pulser commented Nov 2, 2013

The document provider API in Android 4.4 (Kitkat) offers a framework for storage providers, such as OwnCloud, Google Docs, Box etc.

http://developer.android.com/about/versions/kitkat.html#44-storage-access

This looks like a useful way to permit users to access their OwnCloud files quickly, and make use of OwnCloud as their default storage location, throughout the OS, and permits the provider to be written once, but used by any client application that uses this API.

Implementation documentation is available at http://developer.android.com/reference/android/provider/DocumentsProvider.html

@erickrasmussen
Copy link

Looking forward to this as well.

@davivel
Copy link
Contributor

davivel commented Nov 14, 2013

We'll have a look to it. Thanks for the reference.

@vitoller
Copy link

vitoller commented Jul 8, 2014

any updates on the "Storage Access Framework"?

I still could not find a webdav implementation to be used with Android & Owncloud.
(Boxcryptor might work, but it is closed source) - this would be such a good feature for Android.

@davivel
Copy link
Contributor

davivel commented Jul 10, 2014

No update yet, sorry.

@alerque
Copy link

alerque commented Aug 1, 2014

👍 This should be given very high priority as far as development time goes. The lack of using this API on Android makes interfacing with other apps prohibitively confusing. For non-filesystem-savy users that are used to the Android ecosystem where data operations that require it are presented relative to data providers, not having ownCloud as an option is a huge blow to usability.

It's tricky enough that I've struggled to walk people through the process. For an open operation for example one must first leave the app currently in use, use the ownCloud app to mark objects for sync, then go back to the app you were in and use a 3rd party file manager that wraps the file system in a document provider to select the right object to open (assuming the app doesn't have local storage permissions. If it does tho only part of that routine that is left off is the 3rd party navigator, but you still have to switch apps manually a couple times!)

@davivel
Copy link
Contributor

davivel commented Aug 6, 2014

We do know this is very important, but it is only something available only in Android 4.4. Now it's near the 20% of registered devices according to Google, but there is still an 80% of devices that know nothing about this API.

We need to deal with this, but we need more to deal with other pending features. So, please, let's all be patient with this one.

Or still better. What about a contribution :) ?

@alerque
Copy link

alerque commented Aug 7, 2014

I think you're underestimating this. It's a blocker-bug as far as a number of groups I'm trying to migrate from Dropbox. Most other feature requests look like things that are cool to have, but aren't critical to the basic function of storing and retrieving files. Besides at this point 4.4 is rolling out faster than the ownCloud app is being developed. I'd hate to see adoption cut off at the knees because it's falling behind the torrential pace that Android moves at.

I'm sorry my programming expertise is not in Android app development. I have, however, started a bounty on this issue and encourage others interested in seeing this happen sooner rather than later to pitch in and until some developer somewhere is motivated to scratch the itch.

@davivel
Copy link
Contributor

davivel commented Aug 11, 2014

OK, we will have a look to push it higher.

@strugee
Copy link

strugee commented Mar 9, 2015

@davivel did you ever look into this? I share @alerque's concerns.

@davivel
Copy link
Contributor

davivel commented Apr 30, 2015

@strugee , sure we looked into it. Unfortunately, looking does not produce any result similar to writing code.

This will be done when we can book the time for it. There are several reasons why it's very interesting to have it, but we are a small team an have to address many top priorities.

Code contributions in this and related issues are very welcome.

@strugee
Copy link

strugee commented May 4, 2015

@davivel should have been clearer. By 'it', I meant this issue's priority, not the issue itself. Sorry for the confusion (and thanks, as always, for your hard work).

@haseebeqx
Copy link

ok i am working on it. but when i used the existing content provider it shows permission denied since the android:exported is false and android:grantUriPermissions is not set. what should i do now. set android:exported to true or granturipermission or any other options ?.

currently i managed to implement this feature with exported content provider and it is working fine

@dschuermann
Copy link

Maybe it helps that there is a fully working example for Document Providers here: https://android.googlesource.com/platform/development/+/master/samples/Vault/

@haseebeqx
Copy link

i already have a working model .

but the problem is in kitkat the document provider works from another app called documents inside system. so there are issues with current content provider and localbroadcasts. i can not use the current file access provider to look at data since it is not exported and android:grantUriPermissions not set.

@karliwalti
Copy link

May I additionally support the integration of this. Microsoft office is now supporting "Other cloud storage" and all major service providers are supported (tested with Drive, Box, Dropbox, and OneDrive ). To work on the go from the cloud it would be essential

@AndyScherzinger
Copy link
Contributor

Setting exported and android:grantUriPermissions to be able to implement this seems fine to me, what do you think @masensio @tobiasKaminsky @davivel ?

@davitol
Copy link

davitol commented Nov 17, 2015

@davivel 🎅

@codinguser
Copy link

According to http://developer.android.com/about/dashboards/index.html
devices with Android KitKat (4.4) and above now represent over 63% of the total Android install base.
Will this warrant a revisiting of the priority of this issue?

@tobiasKaminsky
Copy link
Contributor

@haseebeqx I think it is not a problem to change these settings.
It would be great if you can provide a pull request which we can merge into our beta app and see how it is working.

@przybylski
Copy link
Member

Since there is no response from previous developer for over a month, I wrote it last night.

przybylski added a commit that referenced this issue Dec 19, 2015
@alerque
Copy link

alerque commented Jan 2, 2016

Thanks @przybylski for working on this. I'm looking forward to having it merged and being able to approve the bounty. For reference since it's not cross linked yet, it looks like PR #1368 is related to this.

@przybylski
Copy link
Member

@alerque I encourage you to test it on latests beta version

@alerque
Copy link

alerque commented Jan 2, 2016

Is there a beta channel on the Play store to facilitate the testing process? Or at least pre-built apk's somewhere?

@przybylski
Copy link
Member

Beta is available on f-droid and pre-built apks are available here https://github.com/owncloud/android/tree/beta/apks

@AndyScherzinger
Copy link
Contributor

@alerque Could you give it a try?

@alerque
Copy link

alerque commented Jan 8, 2016

@AndyScherzinger I've been using the beta since I was pointed to it 6 days ago and it hasn't given me any trouble. On the other hand I've only had a chance to give it pretty light use this week.

@tobiasKaminsky
Copy link
Contributor

@alerque I think @AndyScherzinger is specifically talking about the document provider?
Is this working for you as expected?

@AndyScherzinger
Copy link
Contributor

Thanks for the clarification @tobiasKaminsky that is what I was asking about :)

@ilmaisin
Copy link

The beta client seems to support opening via SAF, but not saving.

przybylski added a commit that referenced this issue Feb 4, 2016
przybylski added a commit that referenced this issue Jun 21, 2016
jabarros pushed a commit that referenced this issue Jun 22, 2016
jabarros pushed a commit that referenced this issue Jun 24, 2016
jabarros pushed a commit that referenced this issue Jun 27, 2016
jabarros pushed a commit that referenced this issue Jun 29, 2016
jabarros added a commit that referenced this issue Jun 29, 2016
@przybylski
Copy link
Member

document provider merged, closing

@davivel davivel added this to the 2.1.0 milestone Jul 4, 2016
hannesa2 pushed a commit that referenced this issue Oct 9, 2023
Update Copyright year to 2020 (library)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests