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

fileProvider - Any specific reason to use "root-path"? #129

Open
Mathbl opened this Issue Mar 23, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@Mathbl

Mathbl commented Mar 23, 2017

Hi,

I was in a situation where I had to use the fileProvider to get a file without NoNonsense-FilePicker (gallery image picker).

I realized that this library advise to use the nnf_provider_paths xml file, which uses the root-path tag. The Utils.getFileForUri() method also check for that tag specifically.

In the official documentation, the root-path tag doesn't seem to exist, so I am curious of the reason behind that usage. All of the examples of using fileProvider I found use file-path:

<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <files-path path="images/" name="myimages" />
</paths>

Wouldn't there be a way to use <files-path path="." name="root" />?

Thanks!

@spacecowboy

This comment has been minimized.

Show comment
Hide comment
@spacecowboy

spacecowboy Mar 23, 2017

Owner

As mentioned at
https://developer.android.com/reference/android/support/v4/content/FileProvider.html

specifying a <files-path path="something"/> will resolve that path as a subdirectory
if your app's internal storage area, which is kind of useless for a
general file picker.

root-path is not prominently mentioned in the docs but it is (was?) the only
way you get completely free access to the entire memory structure and
aren't locked inside some specific part of it.

Owner

spacecowboy commented Mar 23, 2017

As mentioned at
https://developer.android.com/reference/android/support/v4/content/FileProvider.html

specifying a <files-path path="something"/> will resolve that path as a subdirectory
if your app's internal storage area, which is kind of useless for a
general file picker.

root-path is not prominently mentioned in the docs but it is (was?) the only
way you get completely free access to the entire memory structure and
aren't locked inside some specific part of it.

@Mathbl

This comment has been minimized.

Show comment
Hide comment
@Mathbl

Mathbl Mar 23, 2017

Hey, thanks for the quick answer. I'm not sure if that is possible, but that would be nice if I could isolate and have a specific provider for the filePicker that uses root-path, and another more general for my app. If I can't, i'll live with that!

Mathbl commented Mar 23, 2017

Hey, thanks for the quick answer. I'm not sure if that is possible, but that would be nice if I could isolate and have a specific provider for the filePicker that uses root-path, and another more general for my app. If I can't, i'll live with that!

@spacecowboy

This comment has been minimized.

Show comment
Hide comment
@spacecowboy

spacecowboy Mar 24, 2017

Owner

of course you can. It all comes down to what you put in your manifest. You can specify multiple filepickers (if you want) that each use their own filepicker/metadata-xml.

The only limitation is that you can't use the built-in Utils.getFileForUri() since you noted but you can copy paste it change the relevant line to match your own use. A PR to generalize so it can be used in this more specific usecase would be welcomed.

This could probably be an interesting alternative to the existing way to override getRoot in the FilePickerFragment.

Owner

spacecowboy commented Mar 24, 2017

of course you can. It all comes down to what you put in your manifest. You can specify multiple filepickers (if you want) that each use their own filepicker/metadata-xml.

The only limitation is that you can't use the built-in Utils.getFileForUri() since you noted but you can copy paste it change the relevant line to match your own use. A PR to generalize so it can be used in this more specific usecase would be welcomed.

This could probably be an interesting alternative to the existing way to override getRoot in the FilePickerFragment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment