incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: CordovaView?? - A proof of concept of making a custom Android View with Cordova Web APIs exposed
Date Mon, 12 Dec 2011 23:01:52 GMT
On Mon, Dec 12, 2011 at 16:15, Matthew Schulkind <>wrote:

> 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.

Which completely invalidates Brian's assumption: "Plugins do not factor
into that
use case".  IIUC.

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?

Seems like there would be some obvious patterns that would arise, once we
define the semantics, which we could describe in a "How to develop plugins"

> On Mon, Dec 12, 2011 at 4:07 PM, Brian LeRoux <> 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.

Right.  At least on Android and iOS, plugins are instances of classes, and
so we just need to tell people how often instances are created, shared, etc.

> 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).

Again, I think Matthew's code invalidates this claim.  And what benefit is
there of using a "CordovaView" over the native WebView anyway?  I would
have expected the primary benefit being that you HAVE plugins.  I'm not
sure what other benefits there might be.  Or maybe you aren't considering
the current "base" plugins to be "plugins" (I do).

My preference here is to give each CordovaView a new instance of a plugin.
 For folks that need app-wide sharing in their plugin, they have statics.
 At least, that'd be the story for a typical OO language like Java or ObjC.
 That's as far as I'd go.  We provide no thread protection, etc.

The problem with sharing plugin instances across views is that your
"instance variables" in the plugin are really mor like "static variables",
forcing you to come up with other was of managing instance-specific data,
when you need it.  This is a pain-in-the-ass in J2EE Servlets, which work
that way.  J2EE retrofitted a declarative way of doing per-request servlets
in later releases (yay!  more XML configuration!!).

The downside of creating new instances for each view is the memory/time to
do this.  But we can teach people, by example, how to pool slow/large
shareable resources, etc (eg, the "How to develop plugins" document alluded
to earlier).

Patrick Mueller

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