[ 
https://issues.apache.org/jira/browse/CB-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147707#comment-15147707
 ] 

ASF GitHub Bot commented on CB-9548:
------------------------------------

GitHub user TanaseButcaru opened a pull request:

    https://github.com/apache/cordova-plugin-camera/pull/169

    separate FILE_URI and NATIVE_URI / take in account user defined destType

    Right now, on Android, ``FILE_URI`` and ``NATIVE_URI`` returns the path 
with ``content://`` scheme, excepting the case when the image has been modified.
    
    These changes take in account what is the user defined ``destType`` and 
returns the path as requested.
    
    I know there were discussions on JIRA 
([CB-9548](https://issues.apache.org/jira/browse/CB-9548)) about how 
``FILE_URI`` and ``NATIVE_URI`` should look, but I came to think that it should 
be like this:
    * FILE_URI should return the ``file://`` scheme;
    * NATIVE_URI should return the ``content://`` scheme;

You can merge this pull request into a Git repository by running:

    $ git pull 
https://github.com/TanaseButcaru/cordova-plugin-camera-unofficial 
fileuri-nativeuri

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cordova-plugin-camera/pull/169.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #169
    
----
commit 5e496f143c9b980ece203141204452bbf9178702
Author: TanaseButcaru <[email protected]>
Date:   2016-02-15T02:04:08Z

    separate FILE_URI and NATIVE_URI

----


> camera.getPicture() - invalid FILE_URI when returning original image from 
> device
> --------------------------------------------------------------------------------
>
>                 Key: CB-9548
>                 URL: https://issues.apache.org/jira/browse/CB-9548
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Plugin Camera
>         Environment: Archlinux OS
> Cordova CLI (5.2.0)
> Android platform (4.1.1)
> cordova-plugin-camera (1.2.0)
> ---------------------
> Android Simulator (4.4.4 & 5.0.1)
> Xperia Z3Compact (5.1.1)
> Xperia Sola (4.4.4)
>            Reporter: Tanase Butcaru
>            Assignee: Richard B Knoll
>              Labels: Android, reproduced, triaged
>
> Camera plugin returns a NATIVE_URI path when trying to get the original image 
> with +getPicture()+ method instead of returning the FILE_URI path (even 
> though the _destinationType_ is set to 
> _navigator.camera.DestinationType.FILE_URI_).
> Until now I was using the camera plugin to get modified images only (by 
> passing the _targetHeight_ & _targetWidth_ and/or _allowEdit_ arguments to 
> +getPicture()+ method), but when I tried to get the original image I found 
> this bug.
> Tested with devices mentioned in the Environment section for both Android & 
> iOS platforms, but only Android manifests this behaviour..
> _I've created a github repo where I intend to reproduce all cordova core 
> plugin bugs that I discover. I think this is the best way to test/reproduce 
> any issue._
>  *How to reproduce the bug*:
> {code}
> git clone https://github.com/TanaseButcaru/cdv.bugs.git
> cd cdv.bugs/bugs/getPictureFileURI
> cordova run/emulate android
> {code}
> When the app starts you have two options for the _getPictureFileURI_ bug: 
> * getPicture with edits (targetHeight/Width) - OK
> * getPicture without edits (original image) - *wrong FILE_URI*
> For the second option, where the bug appears, I have provided a external 
> (temporary) solution: I'm using the 
> [cordova-plugin-filepath|https://github.com/hiddentao/cordova-plugin-filepath]
>  plugin to get the FILE_URI from the NATIVE_URI and as you can see in the 
> sample app, it works well, but it would be better if the camera plugin would 
> do this by default when returning an unmodified image.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to