Oh, so does it refer to the location rather than the type of URI? That's fine with me, but if that is the case than we should still probably be sure that whatever is returned from the call is of a consistent type (i.e. always using content or always using file).
Richard -----Original Message----- From: Shazron [mailto:shaz...@gmail.com] Sent: Friday, November 6, 2015 5:52 PM To: dev@cordova.apache.org Subject: Re: Native vs. File URIs I always thought a native URI was if the image was retrieved from the ALAssetsLibrary (Photos Album). https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdeveloper.apple.com%2flibrary%2fios%2fdocumentation%2fAssetsLibrary%2fReference%2fALAssetsLibrary_Class%2f&data=01%7c01%7cRIKNOLL%40exchange.microsoft.com%7c326ecc41750b4739501e08d2e7161af7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=k5JGWbePhlj4jmLCekW9tZiBlU11sE5cUv%2fr%2bqPMYkU%3d and the file URI was the image we dumped into tmp. On Fri, Nov 6, 2015 at 11:43 AM, Richard Knoll <rikn...@microsoft.com> wrote: > Hey all, > > I was wondering if anybody could clarify for me what the difference between > FILE_URI and NATIVE_URI is in the camera plugin. Do we have a clear > definition of either? I assumed that FILE_URI would refer to an actual path > on the device (i.e. a URI using the "file" scheme) but the docs for the > camera plugin actually use a content URI as an example. This seems > counterintuitive, especially since the "content" scheme is specific to > Android. As it stands, FILE_URI and NATIVE_URI always return the same thing > in Android and can either give a content URI or a file URI depending on the > other camera options that are passed. I think we need to be clear when > returning URIs so that app developers can tell what they have to do with it > before they can use it in their app. Also, it's worth noting that the > FILE_URI and NATIVE_URI question is complicated by the fact that on Android > it is possible to pick photos using apps like Google Photos which can choose > files that have no local path. I also would love some clarification as to > where "cdvfile" fits into all of this and the type of support it has across > the plugins. This is in regards to CB-9548, for those interested. > > Thanks, > Richard --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org