Carlos - first off I'd like to apologize for not responding sooner. I just wanted to say thanks hugely for the offer to help out - it is much appreciated. Once I get a few things sorted out, I'll reach out to you so we can figure out how best to move forwards. In the meantime, if you have any thoughts on how you guys would like to contribute, please let me know.
Thanks! Tim ________________________________________ From: Carlos Santana [csantan...@gmail.com] Sent: Saturday, March 28, 2015 7:51 AM To: dev@cordova.apache.org Subject: Re: Simulating Cordova plugins and device capabilities IBM is behind this use case, there are customers that are novice or some reason are just getting started doing mobile. There is also those design developers that want to build a good prototype, before going to the next level of debugging (i.e. emulator, and real device) We currently have product named MBS [1] that offers help in this area. TIm, Julian We(IBM MobileFirst) would like to see an open solution, that then downstream distributions can built on top. Let us know know how can we help. [1]: https://www.ibm.com/developerworks/community/blogs/worklight/entry/hybrid_application_preview_in_the_mobile_browser_simulator On Thu, Mar 26, 2015 at 4:47 PM, Michal Mocny <mmo...@chromium.org> wrote: > 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 > > > -- Carlos Santana <csantan...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
