cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Horn, Julian C" <julian.c.h...@intel.com>
Subject RE: Summarizing thoughts on cordova-browser vs Ripple
Date Thu, 06 Nov 2014 23:52:58 GMT
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.  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.

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.

    Julian

-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panarasi@microsoft.com] 
Sent: Wednesday, November 05, 2014 2:25 PM
To: dev@cordova.apache.org
Subject: RE: Summarizing thoughts on cordova-browser vs Ripple

MSOpenTech is currently working on porting our ripple-platform prototype - https://github.com/MSOpenTech/cordova-ripple
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 [mailto:kirupac@microsoft.com]
Sent: Wednesday, November 5, 2014 11:04 AM
To: dev@cordova.apache.org
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: mikeywbrooks@gmail.com [mailto:mikeywbrooks@gmail.com] On Behalf Of Michael Brooks
Sent: Wednesday, November 5, 2014 9:22 AM
To: dev@cordova.apache.org
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 <mmocny@google.com> 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
>
Mime
View raw message