Just to add my two cents here... I'm currently working on an app and set of plugins that use native chrome on iOS (and eventually Android) exclusively. I don't even show the webview, I just have it added as a view somewhere, yet hidden, so it still works.
Interestingly for my plugins, even though I use class variable singletons for some bookkeeping, my design would hardly even have to change to support multiple webview instances. I suspect this will be the case with most plugins as well. I think the real question is what state do plugins normally keep track of in global sorts of ways? Consider something like a selecting a photo from the library. The plugin likely keeps track of if the modal picker is currently showing. You'd probably want this shared across webview instances. I personally don't see any way of aiding plugins much in this refactor due to issues like this. TL;DR: +1 to Brian On Mon, Dec 12, 2011 at 4:07 PM, Brian LeRoux <[email protected]> wrote: > I think Patricks concern is less about oop basics and more about how > we plan to address shared state. He's right. Its a rats nest and could > cause big headaches. > > The basic use case here is for app developers that demanding native > chrome. (The usual reason here is for better performance. And yes, > that is debatable and especially so as browsers get better.) We saw a > trend w/ Twitter, Facebook and LinkedIn essentially using a > PhoneGap-like approache but w/ native chrome and wanted to look at > supporting it. > > Anyhow, the goal of having PhoneGap as a WebView replacement isnt for > PhoneGap applications but rather to fullfil a use case wherein ppl > want embedded webview in an application that has device access (and > possibly as jesse mentioned even multiple webviews for better > animations [which I find atrocious]). Plugins do not factor into that > use case, in my opinion, because the developer is no longer developing > a phonegap app. He is developing a native app w/ embedded webview(s). > > So should we worry about plugins when PhoneGap is being embedded? For > the first cut of this: no. In the future? Possibly, but as the browser > improves... likely it won't even be necessary. If it was at all. > Anyhow, from my perspective the work to get plugins sharing state > correctly across webviews is picking a losing battle for short term > gain. > > > On Sun, Dec 11, 2011 at 2:57 AM, Jesse <[email protected]> wrote: > > The control is storing/creating/managing it's own instances of the > > Commands/Plugins. > > This could potentially break plugin code in a multi-gap-view world, but I > > am considering making those decisions out of scope for this > > effort/iteration. > > The main use-case I am working to enable is having PhoneGap functionality > > in any app. Essentially the default PhoneGap app that users will build on > > iOS will be a simple application container with 1 PhoneGapView. > > > > After this iteration, we can then move on to define all kinds of things, > > like one view instantiating another, and communication between them. ( > sexy > > animations, ... ) > > General advice for plugin developers would be "don't assume that there > will > > only ever be one instance of your class", although in OOP this should be > > common sense. > > > > > > On Sun, Dec 11, 2011 at 1:17 AM, Patrick Mueller <[email protected]> > wrote: > > > >> On Sun, Dec 11, 2011 at 01:40, Jesse MacFadyen <[email protected] > >> >wrote: > >> > >> > I am working on a similar refactor of iOS code. Moving the majority of > >> > the code into the view controller and out of the application. > >> > This will allow the use of a phonegap view in any application, not > >> > just a PhoneGapApplication subclass. > >> > > >> > >> I wasn't quite sure what Joe was talking about in his post, but if I > read > >> Jesse's note correctly, this is a move from a "application-centered" > >> version of the Cordova runtime to a "control-centered" one. +1 on this. > >> > >> I'm curious as to the affects on plugins when we move to > "control-centered" > >> from "application-centered". > >> > >> 1) are plugin instances shared across multiple controls? Or does each > >> control get their own private instance of each plugin? Or - it it more > >> complicated than that? > >> > >> 2) even if plugin instances aren't shared across multiple controls, > >> presumably a plugin may be using "static" sorts of storage, which > basically > >> makes their plugin instances shared across multiple controls despite the > >> fact that they aren't designed to be. Meaning, you shouldn't be storing > >> any control-specific data in static-ish data areas in your plugin. > >> > >> I think there are issues here, w/r/t plugin design, that go along with > this > >> "control-centered" version of Cordova, and we need to get those spelled > >> out. It might just be a note on dangers of using static-ish storage. > >> > >> -- > >> Patrick Mueller > >> http://muellerware.org > >> >
