cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Camden <>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Tue, 18 Nov 2014 14:57:48 GMT

>> On 11/15/14, 2:17 PM, "Michal Mocny" <> wrote:

>>Not at all.  What is it you think we are proposing?  I'm merely
>that the cordova-browser camera plugin implementation shouldn't *also*
>with a DOM component that sits over top of your application to manipulate
>the camera.  The existing BAAP camera implementation is great as currently
>implemented, and wouldn't change.
>Another example would better illustrate the difference: BAAP geolocation
>shim I believe should just use the browser geolocation api, or return a
>single fixed location if that isn't available.  It needn't support
>programmatically / UI for manipulating custom location, which Ripple
>geolocation does.

I’m with you on that - but I think that is an example that works well w/o
UI and other plugins may not. Let’s consider contacts, specifically
pickContact. I *would* be ok with a UI of some sort, perhaps just 3 simple
contacts in a list, that that user can select. In theory it could also
just automatically fire contactSuccess, but my point is that I’m not
opposed to it providing a bit of UI as well.

>>As an example, I¹ve got an app now which uses barcode scanning for one
>> small part. By adding the Browser platform to the plugin, I am able to
>> all of my work in the browser now and fake a barcode when I need it.
>> is a problem that - imo - is much more valuable than supporting browser
>> a destination of my app.
>If you just want to return a single fixed barcode, I agree BAAP should do
>this.  If you want to be able to customize the barcode at runtime, with a
>simple UI that is automatically injected into your page as part of the
>runtime, then I think that is a task for Ripple (or other emulators).

So I think this is the crux of our disagreement then. :) Right now the
plugin (and I wrote this, so I may be biased ;) uses a prompt so you can
enter a code. My thinking there was if you didn’t care, you would type 1
and hit enter, but if you were passing the bar code to some service, you
could paste something in. To me, that’s more useful then just using a hard
coded value you can’t tweak. I think that usefulness outweighs the
potential ‘loss’ of being able to run this as a real web app.

View raw message