cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Tue, 18 Nov 2014 17:26:29 GMT
I'm less interested in copying work being done faster/better in the browser
devtools. Certainly some UI abstractions are helpful (map controls,
acceleromter scrubbing widget, etc) but the returns for dev time are
diminishing for the effort to author/maintain. Esp bad considering we'd
have to pick UI paradigms and enforce them somehow.

For my two pennies, providing an abstraction that allows authoring time
convenience of using browser with an eventual goal for open web publishing
would be the best architecture (and strategy) for Cordova to pursue.

On Tue, Nov 18, 2014 at 9:12 AM, Michal Mocny <mmocny@chromium.org> wrote:

> On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <raycamde@adobe.com> wrote:
>
> >
> > >>
> > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mmocny@chromium.org> wrote:
> > >>
> >
> > >>Not at all.  What is it you think we are proposing?  I'm merely
> > >>suggesting
> > >that the cordova-browser camera plugin implementation shouldn't *also*
> > >come
> > >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
> > >>do
> > >> all of my work in the browser now and fake a barcode when I need it.
> > >>That
> > >> is a problem that - imo - is much more valuable than supporting
> browser
> > >>as
> > >> 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.
> >
>
> Fair enough.  Sounds like you want some of what I've proposed Ripple could
> offer, but are concerned that Ripple won't be a viable/sustainable choice
> for you.  To be honest, I share that concern.
>
> For the barcode scanning example, I think a popup with an input box is
> fine, even for prod, so long as the popup is presented as if to a user and
> not as if to a developer.  Hopefully we can improve it to also offer an
> input type=image, or to use the webcam (I haven't looked, not sure if it
> does this yet).
>
> If we really want separate dev mode and prod mode for a given plugin,
> perhaps we can just add an api for toggle this.  I just hope to set the
> precedent that the default isn't *just* for developer debugging.
>
> -Michal
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message