cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Tue, 18 Nov 2014 21:03:58 GMT
Shouldn't ripple be able to emulate/monkey-patch any of the platforms?
If I am looking at and testing my cordova-ios app in ripple, I think I
would want the cordova-ios.js to be run, and not cordova-browser.js,
otherwise there could be latent issues that I would never see until I
actually ran it on the device, or emulator.  Hopefully the differences
between each platform's cordova.js is insignificant, but I don't think that
we know this for sure.

The code to inject/intercept ANY platform's cordova.exec is simple, really,
it is <10 lines.
In my mind, ripple should be responsible for hooking it's own way in, and
proxying, without extra specific built in support either by
cordova-browser, or cordova-js.


@purplecabbage
risingj.com

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

> Serge,
>
> That sounds like you disagree with Julian's earlier summary that Ripple
> should just intersect at the exec proxy level, and propose instead that
> Ripple should intersect by having "hooks" inside the cordova-browser plugin
> js-modules, correct?
>
> I think thats not impossible (plugin authors can do what they want), but
> perhaps should just happen on a case-by-case basis, as required.  If you
> have ideas about an architecture that we should advise developers to use by
> default, I'm curious what that would even look like.
>
> -Michal
>
> On Tue, Nov 18, 2014 at 1:01 PM, Lunev, Serge <serge.lunev@intel.com>
> wrote:
>
> > Let me add two pennies from my side also then :)
> >
> > From the community perspective, I have little hope that a random plugin
> > author will care about anything beyond browser target for his/her plugin
> > for testing/debug purposes. I do think though that putting a right
> > architecture in place for something better than a regular browser target
> > can provide is important. 'Something better' means here a way to hook up
> > browser developer tools (or Ripple / node-webkit combo in Intel XDK case)
> > to control plugin behavior so that input data could be controlled by
> > appropriate UI in browser/XDK.
> >
> > For us in XDK the alternative would be to fully separate a plugin from
> its
> > emulation. I.e. if we choose to support certain plugin emulation in the
> > XDK, that will be totally technically separate from its Cordova
> > implementation. While this is a viable alternative, this just doesn't
> smell
> > right.
> >
> > Best,
> > Serge Lunev
> > Intel XDK Engineering Manager
> > @lunarserge
> >
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
> Of
> > Brian LeRoux
> > Sent: Tuesday, November 18, 2014 9:26 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > 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
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>

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