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: Simulating Cordova plugins and device capabilities
Date Thu, 26 Mar 2015 20:04:19 GMT
I'll try to follow up on Tim's remark as eloquently as I can ;)

There are clearly advantages to building device simulation into the browser, but this strategy
does impose limitations.  A company like Microsoft or Google has complete control over the
browser and the debug tools, but this freedom does not exist for other vendors making their
own emulator.  This creates the feeling of a closed system.

Intel has a rich history of creating software development tools for new hardware as it being
designed.  We prize the ability to quickly support new devices of our choosing, so an open
architecture is better for our needs.

Beyond that I see some shortcomings in the way the emulation features in Chrome and Internet
Explorer work today.  The attributes of a device, once selected, cannot be modified by the
program under test (or even by the non-browser parts of the emulator).  This makes it impossible
to simulate any actions that change the size of the viewport.  For example, the show/hide
status bar APIs cannot be simulated under these conditions, nor can other popular plugins
such as AdMob that reduce the size of the viewport to allow room for advertisements. The device
sizes provided in Chrome and Internet Explorer all assume a “full screen” configuration,
that is, no status bar.  This is a reasonable choice if you are simulating a mobile browser.
 However, most packaged apps run with a status bar.  This means the device sizes provided
by browsers are in fact uniformly incorrect for most packaged apps.

In our experience, the photorealistic device skins are surprisingly effective in getting across
the feeling of what an app would look like running on a real device.  We heard from one customer
who develops apps for a living.  For less technical customers a prototype of an app he would
build running in the XDK Device Emulator to show what the app would feel like.  We lose this
capability if we entrust the device emulation problem to the browser.

   Julian

-----Original Message-----
From: Tim Barham [mailto:Tim.Barham@microsoft.com] 
Sent: Wednesday, March 25, 2015 1:50 AM
To: dev@cordova.apache.org
Subject: RE: Simulating Cordova plugins and device capabilities

Thanks Michal and Jesse!

Jesse, in response to your additional questions...

> What value does Ripple  if the basic functionality becomes part of a 
> generic simulation interface?
>
> Ripple currently will simulate screen sizes based on device choice. 
> Chrome dev tools support picking different device viewports also.  
> Where should something like this live?

Julian Horn (Intel) would be a good person to answer that question... He can speak more eloquently
than me to why Ripple is (and will continue to be, after this proposal is implemented) the
ideal platform for them. And I think there is definitely room for both approaches:

* Some basic simulation host provided by Cordova, which wouldn't provide any of the "device
choosing" capabilities and other functionality we get with Ripple, but would work well with
browser dev tools (and rely on them to provide that functionality).
* A richer environment like Ripple, which is also works well embedded in tools like the XDK.

Another interesting point is that Chrome device mode means you have the Chrome debugger open,
which means you can't use an external debugger. If your workflow is entirely Chrome, then
that works very well. If we're talking about using Chrome with external debuggers (like Intel
XDK or Visual Studio), then device mode becomes problematic and something like Ripple works
well.

> Is this feature valuable enough to warrant this lengthy discussion?

It's certainly valuable to certain groups :). But for me I think it's more a case that it
will involve a significant amount of effort and I want to get sign off from the community
now rather than spending a bunch of time going down a path that might get rejected down the
line.

Thanks again!

Tim

-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Wednesday, March 25, 2015 8:32 AM
To: dev
Subject: Re: Simulating Cordova plugins and device capabilities

This is exceptionally cool (and thanks for doing a video demonstration, great way to get the
point across)!

I also agree with all your points, and really support this approach.
Specifically:

+1 browser platform will be used for both prod and debugging, so cannot
have always-on emulation.
+1 to have emulation hooks inside cordova browser platform and cordova
plugins' browser versions, but have them no-op by default.
+1 to support any downstream emulation embedders, and perhaps have a 
+very
lightweight cordova project (though perhaps not necessary beyond a simple testing app).
+1 to suggest Ripple become an embedder.

I'll also note that Microsoft is one of the primary supporters of Ripple recently, so if they
think this is a good direction, that is a strong signal to me.  Intel is a second strong supporter
or ripple (anyone else?), and I think they were on board with this direction as well (to build
on top of browser platform).

-Michal



On Tue, Mar 24, 2015 at 3:55 PM, Jesse <purplecabbage@gmail.com> wrote:

> Thank you Tim for the brief explanation! ;)
>
> I agree with all your summary points.
>
> Some more questions:
>
> What value does Ripple  if the basic functionality becomes part of a 
> generic simulation interface?
>
> Ripple currently will simulate screen sizes based on device choice. 
> Chrome dev tools support picking different device viewports also.  
> Where should something like this live?
>
> Is this feature valuable enough to warrant this lengthy discussion?
> I have no idea how useful this will actually be. As someone who has 
> released apps for most of our supported platforms I have never needed 
> ripple of any other simulation, short of stubbing cordova-exec and 
> working out all my UI/UX in a browser.  Is there some way we can measure the need?
> Given that this does not appear to impact cordova, just supplement it, 
> you should probably just go for it.  Fixing cordova-serve and getting 
> cordova-browser to use it are already in discussions, so moving 
> forward with another module 'cordova-platform-sim'? sounds good to me.
>
> Cheers,
>   Jesse
>
>
>
> @purplecabbage
> risingj.com
>
> On Mon, Mar 23, 2015 at 7:08 AM, Tim Barham <Tim.Barham@microsoft.com>
> wrote:
>
> > Hey Jesse - thanks for the feedback!
> >
> > First I'd like to address why we think this belongs in Cordova 
> > rather
> than
> > Ripple:
> >
> > *. The functionality described is closely tied to how Cordova works, 
> > and we feel is a capability that should be built into Cordova - 
> > specifically, that Cordova provide the hooks necessary for any 
> > arbitrary "simulation host" to connect to.
> > *. We don't see this as being a Ripple replacement, per se. Rather, 
> > is this model, Ripple would become one of any number of "simulation hosts"
> > built on top of this.
> >
> > Cordova might include a very basic "simulation host" out of the box,
> while
> > Ripple would remain a much richer, but separate, project built on 
> > top of the same functionality.
> >
> > Why do we see the need for this when we already have Ripple? Reasons
> > include:
> >
> > * We want to make it easy to embed a "simulation host" in other 
> > environments. Ripple is just one example.. Also within an IDE, or 
> > within
> a
> > browser's dev tools, or whatever.
> > * As mentioned below, we want to separate the simulation UI from the 
> > app itself to simplify the debugging experience.
> > * We want to make it easily extensible - specifically allow plugins 
> > to define their simulation UI and have it work in any simulation host.
> >
> > Regarding the "browser vs Ripple" thread - yeah, I remember it :). 
> > We
> were
> > following it at the time, and it definitely influenced what we are 
> > proposing. Some points on this:
> >
> > * We don't think it should be "browser vs Ripple"... We think it 
> > should
> be
> > "Ripple on top of browser" :) ... but most importantly we don't 
> > limit
> this
> > to Ripple. May simulation hosts proliferate!
> > * If I recall there was also discussion about whether the browser
> platform
> > is primarily a debugging tool or a real production delivery 
> > platform. Our firm belief is that it is both. We can easily provide 
> > the hooks (the 'app host' and 'server' pieces) so a rich debugging 
> > environment like Ripple
> can
> > be built on top of it (and, of course, also open the door to other 
> > simulation hosts) without taking anything away from it being a real 
> > delivery platform.
> >
> > So, in summary, this is how I'm thinking about it:
> >
> > * The browser platform continues to be a production delivery 
> > platform. It doesn't provide any UI for simulating plugins. Plugins 
> > should always just do the "real thing", and never provide mock data or anything
like that.
> > * The browser platform, when run from the Cordova CLI, is modified 
> > to launch from a server. Something we'd want to do regardless.
> > * That server provides the hooks a simulation host needs to do its 
> > thing (but, most likely, those hooks would only be available if the 
> > application was launched in a mode to expect plugin simulation).
> > * The simulation host itself is completely separate from the browser 
> > platform. Completely separate from Cordova, in fact, though 
> > personally
> I'd
> > also love to see a basic simulation host available as part of 
> > Cordova
> (but
> > in its own module).
> >
> > Tim
> >
> > ________________________________________
> > From: Jesse [purplecabbage@gmail.com]
> > Sent: Thursday, March 19, 2015 2:44 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Simulating Cordova plugins and device capabilities
> >
> > Hi Tim,
> >
> > Nice work. I was going to point you towards Ripple[1], until I saw 
> > you
> have
> > the most recent commit.  Can you elaborate on why/how you feel this 
> > fits into cordova and not into the ripple project?
> >
> > Personally, I think it is a better fit in ripple, or at the minimum, 
> > as a separate module/repo in cordova that can function and be added 
> > independently.
> >
> > There is a lengthy discussion on browser vs ripple here [2]
> >
> > [1] https://github.com/apache/incubator-ripple
> > [2] http://callback.markmail.org/thread/mxwnjp4lnz7kfzrr
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Wed, Mar 18, 2015 at 2:04 AM, Tim Barham 
> > <Tim.Barham@microsoft.com>
> > wrote:
> >
> > > Hey everyone... I would like to introduce a proposal and
> proof-of-concept
> > > prototype that we have been working on. The proposal is to provide 
> > > a tool/feature that allows you to simulate Cordova plugins and 
> > > device capabilities when a Cordova app is launched in your desktop browser.
> > >
> > > The goals for this proposal were:
> > >
> > > 1. Keep the simulation UI out of the app's window.
> > > 2. Provide an extensible model for simulating plugins and device 
> > > capabilities.
> > >
> > > I've created some resources to introduce the proposal:
> > >
> > > * Document describing the proposal and the proof-of-concept prototype:
> > > http://goo.gl/XJ25vL
> > > * Short video demonstrating the prototype: http://goo.gl/Nf8UBp
> > > * Document describing how to install the prototype to try it for
> > yourself:
> > > http://goo.gl/MyiNas
> > >
> > > I'd like to emphasize that the prototype was developed purely as a 
> > > proof-of-concept, and is not intended to suggest the final
> > implementation.
> > >
> > > We'd greatly appreciate it if members of the Cordova community 
> > > could
> take
> > > a look and provide feedback - any and all feedback is welcome! But 
> > > as a starting point:
> > >
> > > * What do you think of the idea in general?
> > > * Where should it live? In cordova-browser (like the prototype)? A 
> > > separate Cordova module? Entirely external to Cordova?
> > > * What are the must-have features for an initial release? How 
> > > would we like to see it evolve in the future?
> > > * Any thoughts on implementation details?
> > >
> > > Thanks, and looking forward to your input!
> > >
> > > Tim
> > >
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Mime
View raw message