Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.210.175 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAKP6k2vpACyuNNuEFAJ_iiQsJWP+vNYPvqzzMLDcvsE4Cr_XNQ@mail.gmail.com>
References: 
 <CAOBL_k7cihtsd-dLgx0qGZbes7Foguz=zh3g1MJyWbsBPjYBMA@mail.gmail.com>
	<-4848153779676846049@unknownmsgid>
	<CACAoQH0X7nkDRVwMo=xisp6JxxTZ7mtCps3+PDg2C98KxF52VA@mail.gmail.com>
	<CAKP6k2vpACyuNNuEFAJ_iiQsJWP+vNYPvqzzMLDcvsE4Cr_XNQ@mail.gmail.com>
Date: Mon, 12 Dec 2011 13:07:04 -0800
Message-ID: 
 <CADVgkyPH6CZ8otD9ZBYXLfXX1PSs+758LBb4ydJKrX_od=+2rQ@mail.gmail.com>
Subject: Re: CordovaView?? - A proof of concept of making a custom Android
 View with Cordova Web APIs exposed
From: Brian LeRoux <b@brian.io>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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. ( se=
xy
> animations, ... )
> General advice for plugin developers would be "don't assume that there wi=
ll
> 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> wrot=
e:
>
>> 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 rea=
d
>> Jesse's note correctly, this is a move from a "application-centered"
>> version of the Cordova runtime to a "control-centered" one. =A0+1 on thi=
s.
>>
>> I'm curious as to the affects on plugins when we move to "control-center=
ed"
>> from "application-centered".
>>
>> 1) are plugin instances shared across multiple controls? =A0Or does each
>> control get their own private instance of each plugin? =A0Or - it it mor=
e
>> 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 basica=
lly
>> makes their plugin instances shared across multiple controls despite the
>> fact that they aren't designed to be. =A0Meaning, you shouldn't be stori=
ng
>> 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 t=
his
>> "control-centered" version of Cordova, and we need to get those spelled
>> out. =A0It might just be a note on dangers of using static-ish storage.
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>