Navigation Menu

Skip to content
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

No Picture returned from the Camera Plugin #174

Closed
timkim opened this issue Jul 7, 2014 · 8 comments
Closed

No Picture returned from the Camera Plugin #174

timkim opened this issue Jul 7, 2014 · 8 comments
Labels

Comments

@timkim
Copy link
Contributor

timkim commented Jul 7, 2014

On all platforms, when launching the camera app via the camera plugin, a user is able to take a picture using the camera plugin but the picture is unaccessible to the app. This relates to the same origin policy error where we are attempting to access the file uri where the picture lives from a different origin.

@timkim timkim added the bug label Jul 7, 2014
@timkim
Copy link
Contributor Author

timkim commented Jul 7, 2014

And as mentioned from the the plugin update thread:
#145

iOS:

  • device mobile-spec: - does not work: getPicture never displays the camera
  • served mobile-spec: does not work: same error as above (note: native file picker works fine).

Android:

  • device mobile-spec: works
  • served mobile-spec: does not work: getPicture never displays the camera

WP:

  • device mobile-spec: works
  • served mobile-spec: does not work: displays a broken image unless DATA_URL used.

@mwbrooks mwbrooks added this to the Week #4 - Sync'r up milestone Aug 26, 2014
@tohagan
Copy link

tohagan commented Sep 1, 2014

I've also hit this issue with my stlive app that allows you to run both native and served JS from the one mobile app. stlive serves the same JS code that native device app is compiled from.

So far only tested on Android 4.4.2 Galaxy S5 (Geny Motion) with Touch 2.3.2 and PG 3.5.0

Android:

  • device: works - returns a file:// URL that displays
  • served: getPicture works but returns a content:// URL so it does not display.

I stepped through the JS code and it all looks ok so I'm assuming that the Java code is behaving differently based on Android permissions.

I used this code example: http://phonegap.com/blog/2013/11/20/SenchaPhoneGap/

@timkim timkim mentioned this issue Sep 9, 2014
@mwbrooks mwbrooks modified the milestone: Week #4 - Sync'r up Jun 23, 2015
@mwbrooks
Copy link
Collaborator

Closing since we haven't seen very much activity on this issue. Feel free to reopen.

@atuttle
Copy link

atuttle commented Apr 28, 2016

I'm not sure if what I'm experiencing is related to this or not...

I'm using the PG Developer app to test my app before jumping through the hoops of compiling it on its own. In both Android and iOS I'm able to choose photos from the camera roll and view them in my app.

Then I would like to upload them to my server. On Android this is working as expected. On iOS it appears that nothing is sent.

Via console.log I can see that the file uri (on ios) is file:///var/mobile/Containers/Data/Application/2D778ACD-42EA-43AE-A644-FAB48855DB19/tmp/cdv_photo_003.jpg

Here's my upload code:

var FT = new FileTransfer();
var uploadOptions = new FileUploadOptions();
var uploadPath = api.baseurl + '/photos.json';

uploadOptions.fileKey = 'photo';
uploadOptions.fileName = 'photo.jpg';
uploadOptions.chunkedMode = false;
uploadOptions.params = {
    deviceId: app.info.device_id
    ,latitude: lat
    ,longitude: lng
    ,caption: caption
};

var win = function(resp){ //resp is a FileUploadResult
    console.log(resp);
    $.mobile.loading('hide');
    return successCB(resp);
};
var lose = function(err){
    console.error(err);
    $.mobile.loading('hide');
    ui.fail_handler(err, 'photo upload');
    return failCB(err);
};

try {
    $.mobile.loading('show',{
        text: "Uploading photo, please wait...",
        textVisible: true,
        theme: "a"
    });
    FT.upload(fileURI, encodeURI(uploadPath), win, lose, uploadOptions);
}catch(e){
    ui.fail_handler(e, 'calling FT.upload');
}

If this is a known issue with the PGD app, and given that it works on Android, if I can expect it to work on iOS once compiled to my own app, then I can live with that. Is that the case?

@timkim
Copy link
Contributor Author

timkim commented Apr 28, 2016

Hi @atuttle

I don't believe this is a known issue within the PhoneGap Developer App. It should work once you switch over to your own compiled app. However I would look at the server logs first to see at least the app had tried to upload the image.

If you can see maybe a 404 or at least any status code that indicated that the app tried to reach the server, that'd be a good place to start. Otherwise, if there is no indication then we can dig into this issue further.

@atuttle
Copy link

atuttle commented Apr 29, 2016

Thinking it might be the size of the uploaded file I tried uploading a screen shot of my iPod instead of a photo, but the same thing happens.

I can see that the request from iOS is sent to my server, but the server is complaining that the file field from the upload is missing/blank; which is a bit odd as I can see it listed as a field when debugging and it has a nonzero length... What baffles me is that it's the same code running on both iOS and Android, and it works fine from Android. This leads me to believe it's not the server-side code but something with the app / permissions to send the file, maybe?

@atuttle
Copy link

atuttle commented Apr 29, 2016

To follow up, after I started building my app on its own, the problem went away. I don't know what plugins the phonegap developer app has installed, but I'm making use of FileTransfer and the File plugin. I could see how not having one or both of those could be problematic. At any rate, I'm on my feet. Thanks for your attention! 👍

@timkim
Copy link
Contributor Author

timkim commented Apr 29, 2016

Hi @atuttle

Well, glad to hear it's working for you!

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

No branches or pull requests

4 participants