Support file:// and library content:// files

[jrichardlai]

Not sure if that's the best way, but it allows reading file from library or filesystem.

[johanneslumpe]

@jrichardlai Thanks! I'm not an Android-person but I guess @cjdell has an opinion on this :)

[johanneslumpe]

@jrichardlai Are you using this in production? I'm inclined to merge this as @cjdell isn't responding. But I cannot test it on my own right now, so I want to make sure that you are positive that this works as expected. Is there anything you think we should add to the readme/docs for this?

[jrichardlai]

@johanneslumpe I'm using it in production didn't see any problems so far, but this feature is not used a lot. Also I added this change because it makes sense for us ( we use it when we want to retry an upload that fails, which can be from either a image from the library or a new photo ) but I don't know if it fits in this library if react-native-file-system is really about only the file system.

[jrichardlai]

And yeah a second opinion would be better :)

[mcorb]

Accepting a subset or URLs using existing entry points is confusing and could introduce correctness issues because this API is specified as accepting file paths.

(e.g. why don't the other functions in the API accept URLs, only this one? Why are only some kinds of URLs accepted? What if I really want to write a file that looks like a URL in some custom Android distribution, but this code prevents me from doing so?)

[jrichardlai]

@mcorb word. Maybe I should make another method for that readFileFromURL? Since this library is already handling download of urls, it still makes sense to be part of it.

[grokbot]

I'm attempting to open pdfs downloaded by using Linking.openUrl and it fails to open if I use a file://path_to_file

Would this PR make that function? I'll check it out, but if you can confirm that would be great.

Edit: I suppose my thought that it was some kind of permissions issue was not correct. For anyone else looking for reason why files cannot be opened, this PR didn't solve not being able to open local files downloaded with RNFS via Linking. Everyone else, sorry for cluttering!
Bonus Edit: turns out using ExternalDirectoryPath as the target directory worked for using Linking.openUrl

[bnns]

@grokbot Thanks for posting your finding about ExternalDirectoryPath - it just saved me a lot of time!

[Froelund]

This works for me. Thanks @jrichardlai
In my scenario I tried to read the output file from react-native-camera. It worked on ios, but failed on Android. This fixed the issue 👍

[matt-oakes]

This certainly fixes and issue with Android, but I agree that it should be implement on all methods so the support is consistent.

[jjzazuet]

Hi. Just pinging to check if any decision has been made on this PR. Thanks!

[itinance]

Can you add please again the File-Exists-check and throw an Exception, if the file does not exists? To not throw an exception would be compatibility break for all those that rely on this check in the thrown exception (instead of calling .exists() by themself in JS-layer)

[ItsNoHax]

I would also recommend not adding file:// without checking if the filepath already starts with file:// to avoid double file://file://

[wassgha]

It actually doesn't start with file:// since the uri scheme is null

[itinance]

Thanks for reaching out. Just one thing. Please consider my comment

[TomMahle]

@grokbot Could you elaborate on this? I'm using:
Linking.openURL('file://' + RNFS.ExternalDirectoryPath + '/' + fileName)
but the file is still not being opened even though Linking.canOpenURL is giving back true and PermissionsAndroid.PERMISSIONS.READ_EXTERNAL_STORAGE is giving granted. Any ideas what I might still be missing?

[Edit]: It looks like the issue I was running into was the "...exposed beyond app through Intent.getData()" issue. I haven't found a way to get around this using Linking, but am awaiting this PR to get fixed before using on react-native-fetch-blob to get merged in in order to use it: joltup/rn-fetch-blob#58

[grokbot]

@TomMahle in my case when I was working with this, I had previously downloaded the file and stored it in the default directory through the app, where I did run into some read problems when using Linking.openURL(). Changing the directory to ExternalDirectoryPath had cleared the initial problem of throwing errors of not having permission to open that file. If you're having permission issues, I think the app has to have same user as the target directory or more open permissions (which I think ExternalDirectoryPath is the latter)