12-03-2013 01:29 PM - edited 12-03-2013 01:31 PM
I have a cordova 3.2.0 app that uses the Capture plugin. When I launch the image capture, I can take a photo, the response comes back with a fileURI (eg "file:///accounts/1000/shared/camera/IMG_00000004.j
The cordova documentation says that it adds elements to the config.xml:
Specifically it is supposed to do:
<param name="blackberry-package" value="org.apache.cordova.capture.MediaCapture"/>
<feature id="blackberry.system" required="true" version="184.108.40.206"/>
<feature id="blackberry.io.file" required="true" version="220.127.116.11"/>
However, when I extract the config.xml from the generated bar, none of those elements are there and the plugins.xml doesn't exist. Are they not needed anymore? Are the plugins incorrect?
I should also mention that I tried manually adding these properties to the config.xml, but that doesn't work as the file seems to be autogenerated at each build.
Solved! Go to Solution.
12-03-2013 02:00 PM
12-03-2013 02:03 PM
12-03-2013 02:10 PM
12-03-2013 02:17 PM
According to the docs:
Access to all domains, including file:// protocol:
<access origin="*" subdomains="true"/>
I added that, and no dice. I also tried:
<access origin="file://*" subdomains="true"/>
That didn't help either.
12-03-2013 02:25 PM
12-03-2013 04:06 PM
Hi Jeff, I just managed to get a sample of this working. Here is what I did.
From the command-line, here are the webworks commands I ran:
C:\webworks>webworks create capture C:\webworks>cd capture C:\webworks\capture>webworks plugin add org.apache.cordova.media-capture C:\webworks\capture>webworks run
Prior to executing the webworks run command, I madea few modifications. To config.xml, at the root www folder I added:
<access origin="file:///" subdomains="true" /> <rim:permissions> <rim:permit>access_shared</rim:permit> </rim:permissions>
Note that the <access> origin has three / characters.
In my config.xml, I added two HTML element for my testing, wrapped in a div:
<div> <img id="imgTarget" width="480" height="480" src="" /> <button onclick="captureImage();">Capture Image</button> <br> </div>
And I defined the captureImage function as follows:
Note that the app.initialize() call is from the auto-generated code. I left it in just to show where in the code I added the function.
With this, the <img> element successfully loads the image.
12-03-2013 05:34 PM
So, this got me a little closer, though it still isn't perfect.
First of all, I am using cordova, not webworks, so some of the workflow is different. For instance, I had to add the following to my cordova-app/www/config.xml
<rim:permissions> <rim:permit>access_shared</rim:permit> </rim:permissions>
It appears that the following was not needed:
<access origin="file:///" subdomains="true" />
If I tried adding it to my cordova-app/platforms/blackberry10/config.xml, it wouldn't work as each time I do a build that file is recreated from the common one. Having to add that to the common one feels wrong. Also, the build seems to automatically add the following:
So why doesn't it add the permission for the access_shared (which seems required by the capture plugin...no use taking a photo if the app can't access it, amiright)?
So anyway, I can now add the fileURI to an <image> tag to see it. But I still get the error code 5 when I try to resolveLocalFileSystemURI in order to get the FileEntry so that I can get the filePath to send to a FileTransfer.upload.
12-04-2013 11:29 AM
12-04-2013 01:52 PM
Is dropping "file://" safe? Couldn't the fileURI point to a virtual path which gets mapped to a completely different physical path once resolved? Isn't this why the resolveLocalFileSystemURI function exists? Also, on Android I get a content:// uri, which needs to get resolved to a physical path before I do the file transfer. Keep in mind that I am using cordova because I am targetting multiple platforms, and I don't really want to have to write special code just for BlackBerry (cordova is supposed to do this for us). Another bonus to resolveLocalFileSystemURI is that it gives me a FileEntry that makes it super easy to get the file name, instead of having to parse the file name out of the uri manually.
But I digress. Getting back to the issue...
I've stepped into window.resolveLocalFileSystemURI, and it goes to:
I put a breakpoint on line 40 where it does:
at this point (before it has executed fileUtils.isOutsideSandbox):
sandboxState = true
decodedURI = "file:///accounts/1000/shared/camera/IMG_00000012.
and the result of fileUtils.isOutsideSandbox seems to be false (which suggests that the file is inside the sandbox, in other words local), and therefore goes into the else and sets sandbox state to true.
it then does: