Julian, I think with the current plan you can proceed to emulate with Ripple exactly as you explain, right? Is there a change you would like to see be made that would make this easier?
For me, device emulation inside the browser is preferable, and actually no-emulation-just-polyfills is usually even sufficient (I just use desktop Safari/Chrome as a proxy for mobile equivalents). If I want to truly emulate a device I grab it off the shelf. I understand the above workflow is not universal to everyone, its just my preference.. and I like that the current proposal gives us both the option we prefer, yet we can share as much common infrastructure as makes sense at the plugin-browser-implementation level. -Michal On Thu, Mar 26, 2015 at 4:04 PM, Horn, Julian C <julian.c.h...@intel.com> wrote: > 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.bar...@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: mmo...@google.com [mailto:mmo...@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 <purplecabb...@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.bar...@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 [purplecabb...@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.bar...@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-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
