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.ler...@gmail.com [mailto:brian.ler...@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 <mmo...@chromium.org> wrote: > On Tue, Nov 18, 2014 at 9:57 AM, Ray Camden <rayca...@adobe.com> wrote: > > > > > >> > > >> On 11/15/14, 2:17 PM, "Michal Mocny" <mmo...@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-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
