Return-Path: X-Original-To: apmail-cordova-issues-archive@minotaur.apache.org Delivered-To: apmail-cordova-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6395510B2A for ; Wed, 3 Jul 2013 14:15:21 +0000 (UTC) Received: (qmail 94889 invoked by uid 500); 3 Jul 2013 14:15:21 -0000 Delivered-To: apmail-cordova-issues-archive@cordova.apache.org Received: (qmail 94872 invoked by uid 500); 3 Jul 2013 14:15:21 -0000 Mailing-List: contact issues-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list issues@cordova.apache.org Received: (qmail 94771 invoked by uid 99); 3 Jul 2013 14:15:20 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jul 2013 14:15:20 +0000 Date: Wed, 3 Jul 2013 14:15:20 +0000 (UTC) From: "Jonathan Bond-Caron (JIRA)" To: issues@cordova.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CB-4071) Capture error callback (should be an object) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CB-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Bond-Caron updated CB-4071: ------------------------------------ Description: When using camera.getPicture(), the cameraError is documented as a string but on Android & iOS, it's actually an object. On the native side in 2.7: Android: private static final int CAPTURE_INTERNAL_ERR = 0; // private static final int CAPTURE_APPLICATION_BUSY = 1; // private static final int CAPTURE_INVALID_ARGUMENT = 2; private static final int CAPTURE_NO_MEDIA_FILES = 3; iOS: enum CDVCaptureError { CAPTURE_INTERNAL_ERR = 0, CAPTURE_APPLICATION_BUSY = 1, CAPTURE_INVALID_ARGUMENT = 2, CAPTURE_NO_MEDIA_FILES = 3, CAPTURE_NOT_SUPPORTED = 20 }; Windows 8: only string errors Android and iOS have the same looking api on the native side, error callback Android returns JSON: {message: '', code: int}, iOS returns JSON: {message: '', status: int}, Looking at the javascript api, it looks like it should return a 'new CaptureError()' on the errorCallback, is that the direction for 3.0? Windows only sends a string as the callback error, it's difficult to know if the user just cancelled taking a picture or what kind of specific error occurred. Should I look into creating a patch? This probably affects other apis, overall I'd like to see the CaptureError() returned more consistently instead of strings. It would make sense to improve this in 3.0 and possibly break BC for those expecting strings. CaptureError() could implemented a 'toString()' to mitigate potential issues. was: When using camera.getPicture(), the cameraError is documented as a string but on Android & iOS, it's actually an object. On the native side in 2.7: Android: private static final int CAPTURE_INTERNAL_ERR = 0; // private static final int CAPTURE_APPLICATION_BUSY = 1; // private static final int CAPTURE_INVALID_ARGUMENT = 2; private static final int CAPTURE_NO_MEDIA_FILES = 3; iOS: enum CDVCaptureError { CAPTURE_INTERNAL_ERR = 0, CAPTURE_APPLICATION_BUSY = 1, CAPTURE_INVALID_ARGUMENT = 2, CAPTURE_NO_MEDIA_FILES = 3, CAPTURE_NOT_SUPPORTED = 20 }; Windows 8: only string errors Android and iOS have the same looking api on the native side, error callback Android returns JSON: {message: '', code: int}, iOS returns JSON: {message: '', status: int}, Looking at the javascript api, it looks like it should return a 'new CaptureError()' on the errorCallback, is that the direction for 3.0? Windows only sends a string as the callback error, it's difficult to know if the user just cancelled taking a picture or what kind of specific error occurred. Should I look into creating a patch? This probably affects other apis, overall I'd like to see the CaptureError() returned more consistently instead of strings. It must sense to improve this in 3.0 and possibly break BC for those expecting strings. CaptureError() could implemented a 'toString()' to mitigate potential issues. > Capture error callback (should be an object) > -------------------------------------------- > > Key: CB-4071 > URL: https://issues.apache.org/jira/browse/CB-4071 > Project: Apache Cordova > Issue Type: Bug > Components: Android, iOS, Windows 8 > Affects Versions: 2.9.0 > Environment: All > Reporter: Jonathan Bond-Caron > Assignee: Joe Bowser > Priority: Critical > > When using camera.getPicture(), the cameraError is documented as a string but on Android & iOS, it's actually an object. > On the native side in 2.7: > Android: > private static final int CAPTURE_INTERNAL_ERR = 0; > // private static final int CAPTURE_APPLICATION_BUSY = 1; > // private static final int CAPTURE_INVALID_ARGUMENT = 2; > > private static final int CAPTURE_NO_MEDIA_FILES = 3; > iOS: > enum CDVCaptureError { > > CAPTURE_INTERNAL_ERR = 0, > > CAPTURE_APPLICATION_BUSY = 1, > > CAPTURE_INVALID_ARGUMENT = 2, > > CAPTURE_NO_MEDIA_FILES = 3, > > CAPTURE_NOT_SUPPORTED = 20 > }; > Windows 8: > only string errors > Android and iOS have the same looking api on the native side, error callback Android returns JSON: {message: '', code: int}, iOS returns JSON: {message: '', status: int}, > Looking at the javascript api, it looks like it should return a 'new CaptureError()' on the errorCallback, is that the direction for 3.0? > Windows only sends a string as the callback error, it's difficult to know if the user just cancelled taking a picture or what kind of specific error occurred. > Should I look into creating a patch? > This probably affects other apis, overall I'd like to see the CaptureError() returned more consistently instead of strings. > It would make sense to improve this in 3.0 and possibly break BC for those expecting strings. > CaptureError() could implemented a 'toString()' to mitigate potential issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira