incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Schulkind <mschulk...@gmail.com>
Subject Re: CordovaView?? - A proof of concept of making a custom Android View with Cordova Web APIs exposed
Date Mon, 12 Dec 2011 21:15:40 GMT
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 <b@brian.io> 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 <purplecabbage@gmail.com> 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 <pmuellr@gmail.com>
> wrote:
> >
> >> On Sun, Dec 11, 2011 at 01:40, Jesse MacFadyen <purplecabbage@gmail.com
> >> >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
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message