cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Summarizing thoughts on cordova-browser vs Ripple
Date Mon, 10 Nov 2014 14:48:50 GMT
On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C <>

> I'd like to introduce myself and put in my two cents here. My name is
> Julian Horn.  I work for Intel on the XDK, an integrated development
> environment for cross-platform HTML5 applications.  I am the team lead for
> the Device Emulator component, which is our Ripple derivative.  My
> background is mostly in software development tools: compilers, debuggers,
> simulators and analysis tools. I have been working with the Ripple code
> base for a couple of years now.
> If I'm understanding the cordova-browser concept, the implementation of a
> Cordova API for the browser platform should consist of code that bridges
> between the platform-independent Cordova API and whatever equivalent is
> available in the current browser session.  For example, the camera API
> getPicture function would invoke the getUserMedia API, which is the closest
> thing we have to a W3C standard way to take a picture.  If the browser
> doesn't implement this API or the host system doesn't have a camera, then
> the getPicture call fails with "camera unavailable".
> This seems like a fine way to gradually migrate from packaged apps that
> rely on native code plugins to pure web apps that rely on the browser to
> access mobile device resources.  This should work great when you have a
> browser-portable implementation.  It may be a challenge with some plugins,
> since of course Cordova/PhoneGap was designed to cover gaps in browser
> support.  But at least we don't have to wait for a real W3C standard to be
> agreed.
> The goal of our XDK product is to facilitate development of cross-platform
> mobile HTML5 applications.  We see the Device Emulator (our Ripple) as
> enabling developers to test an HTML5 mobile application on the host
> system.  While this is no substitute for testing on real hardware, the
> Device Emulator does offers some advantages that can accelerate the
> development process.  To summarize quickly:
>  * It’s really fast.
>  * You don't need an array of mobile devices.
>  * You can put off dealing with weird target system quirks until after you
> get your basic application logic debugged.
>  * You get full native JavaScript debugging, which is faster, simpler, and
> more available than remote debug.
>  * You can create testing situations that are difficult or impossible to
> create in real life, such as GPS timeout.
>  * It's a great teaching tool.
>  * It allows you to prototype quickly.
> Assuming the functionality delivered by Ripple has value (and we find it
> does), one needs a way to reconcile this with the cordova-browser effort.
> Here's how I see that working out.
> One idea is to rely on the browser developer tools to supply emulation
> support and just drop Ripple.  I don't like this much.  Today the developer
> tools emulation UI is fairly primitive, but of course, there is nothing
> stopping the browser vendors from building all the functionality in the
> Ripple Geolocation panel (or indeed all of Ripple) into the developer
> tools.  The bigger problem from my point of view is that this is a closed
> system.  There's no way for a non-browser-vendor to extend the browser to
> provide emulation support for new plugin APIs.
> The alternative is to do a "cordova prepare browser" and load the results
> into Ripple.

This would be my preference if at all possible.  Specifically, I think
ripple would move much faster and be better architected if it didn't have
to depend on making changes directly to cordova.  Though it should be
acceptable to create a ripple platform (cordova run ripple) if really need

>   Assuming the browser platform code follows the usual pattern, that is,
> that it goes through an exec/execProxy layer, it should be possible for
> Ripple to intercept at that level.  Ripple can delegate to the execProxy
> implementation if it has no emulation-time implementation of its own.  This
> means that unrecognized APIs run unaltered, in which case you get whatever
> behavior you get on the browser platform.  This is a really exciting
> prospect.  It's way better than that "we don't know what to do" dialog that
> Ripple puts up when an exec layer function it doesn't recognize is called.

Thats interesting.  I hadn't considered doing it this way, but it actually
sounds like a great solution.

> In fact there are some Cordova APIs that Ripple implements by mostly
> delegating to a Chrome-specific API.  For example, the simulation of the
> Cordova File API is based on webkitRequestFileSystem.  (Unfortunately no
> other browser vendors have seen fit to support this API.)  In those cases I
> think the Ripple implementation of the API is likely to coincide nicely
> with the browser platform implementation.
> Unlike ripple-as-a-platform, this model doesn't allow plugin authors to
> provide their own emulation-time solutions.  I was always skeptical that
> many plugin authors would really do this (others disagree).  But if they at
> least provide a browser implementation then Ripple has something to fall
> back on.  And if there's something better that can be done, we can always
> extend Ripple.

Given that the biggest benefit of Ripple is to provide UI to dig into and
manually adjust the plugin behaviour, I share your sentiment.  I did voice
that I thought plugin authors would provide implementations -- but that is
for what we know are classifying as cordova-browser implementations (even
if just stubs / no-ops).

>     Julian
> -----Original Message-----
> From: Parashuram Narasimhan (MS OPEN TECH) []
> Sent: Wednesday, November 05, 2014 2:25 PM
> To:
> Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> MSOpenTech is currently working on porting our ripple-platform prototype -
> to work on top of
> cordova-browser. The question on how each plugin exposes a UI to provide
> mock data is still up for discussion, but Intel has a lot of context on
> that area.
> -----Original Message-----
> From: Kirupa Chinnathambi []
> Sent: Wednesday, November 5, 2014 11:04 AM
> To:
> Subject: RE: Summarizing thoughts on cordova-browser vs Ripple
> +1 to what you’ve both stated.
> Cordova-browser shouldn't be responsible for providing mock data, UI, or
> any additional functionality for simulating a plug-in. It’s primary goal is
> to (as you both mention) be responsible for getting apps to run in the
> browser. Simulating plug-in behavior would be external to that in some form
> or fashion.
> Cheers,
> Kirupa
> -----Original Message-----
> From: [] On Behalf Of
> Michael Brooks
> Sent: Wednesday, November 5, 2014 9:22 AM
> To:
> Subject: Re: Summarizing thoughts on cordova-browser vs Ripple
> >
> > In my view, ripple should be built on top of the browser platform
> > work, and ideally also decouple the UI from the plugin
> > instrumentation, but thats up to the folks running that effort.
> > With all this in mind, I think the cordova-browser effort should
> > proceed with current direction, but keep in mind that more advanced
> > plugin instrumentation doesn't belong there.
> This echo's my views on the Browser Platform and Ripple as well.
> Ideally, the Browser Platform is a production deployment environment for
> the web, while Ripple is debugging instrumentation that runs on the Browser
> Platform.
> On Wed, Nov 5, 2014 at 8:04 AM, Michal Mocny <> wrote:
> > We debated a bit about browser vs ripple at phonegap day (especially
> > Intel folks who have done lots of work here), and the my personal
> > tldr; is that there is in fact a home for both.
> >
> > Basically, browser-platform is for getting apps running in a browser
> > (duh) with as much working functionality as possible.  Its supposed to
> > simplify the 'if cordova then dialog else alert' problem, so you can
> > build even more of your app with just local development.  Seemingly
> > this could be used to make targeting both web and app even easier.
> >
> > Ripple is for instrumenting/debugging apps by manipulating plugins.
> > Its about having a UI that reaches into geolocation or camera and
> > controls what the plugin returns to the app.  Its about re-running the
> > same device events over and over for tracking application logic changes.
> >
> > Some of the work ripple has done traditionally can now in fact just be
> > done via browser DevTools, but their are still some cases where custom
> > hooks into plugins are the best way to provide a good local
> > "simulator".  (Chrome DevTools at least now provide mobile emulation,
> unsure about others).
> >
> > In my view, ripple should be built on top of the browser platform
> > work, and ideally also decouple the UI from the plugin
> > instrumentation, but thats up to the folks running that effort.
> >
> > With all this in mind, I think the cordova-browser effort should
> > proceed with current direction, but keep in mind that more advanced
> > plugin instrumentation doesn't belong there.
> >
> > -Michal
> >

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