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 dave.c.johnson@gmail.com
 designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAD0jhjGN5ahauodG_XSLCFLozvKXU_TzKKLTGKXtnEt08UXnDQ@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>
 <CADVgkyPH6CZ8otD9ZBYXLfXX1PSs+758LBb4ydJKrX_od=+2rQ@mail.gmail.com>
 <CAD0jhjGN5ahauodG_XSLCFLozvKXU_TzKKLTGKXtnEt08UXnDQ@mail.gmail.com>
From: Dave Johnson <dave.c.johnson@gmail.com>
Date: Mon, 12 Dec 2011 13:35:51 -0800
Message-ID: 
 <CADq=2H6RPn+jOh9jS2=8D-Eb8DKrud3Worafj2ecsFYKaLRaYw@mail.gmail.com>
Subject: Re: CordovaView?? - A proof of concept of making a custom Android
 View with Cordova Web APIs exposed
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 on this as well.

The thing that struck me when Joe mentioned that back button etc don't
work is that this makes it pretty clear what sort of functionality is
app functionality vs control functionality - in this case android
hardware buttons are clearly app functionality that should have
nothing to do with the control use case.

If that is true about the buttons not being in the view control on
android then I think there is still a need for a CordovaActivity /
CordovaDelegate sort of thing on Android / iOS that your main
application can inherit from. We would also want a CordovaView control
that could hook into the activity with no problems for the Cordova app
use case, however, you could also just write your app from scratch
(e.g. not inheriting CordovaActivity) and deal with hooking up intents
/ buttons / etc and use multiple CordovaViews in the app.

Make any sense?

On Mon, Dec 12, 2011 at 1:15 PM, Matthew Schulkind <mschulkind@gmail.com> w=
rote:
> 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 webvie=
w,
> 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 suppo=
rt
> 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 du=
e
> 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, bu=
t 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 functional=
ity
>> > 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 thing=
s,
>> > 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.c=
om
>> >> >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. =A0+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? =A0Or does e=
ach
>> >> control get their own private instance of each plugin? =A0Or - 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. =A0Meaning, you shouldn't be st=
oring
>> >> 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 wit=
h
>> this
>> >> "control-centered" version of Cordova, and we need to get those spell=
ed
>> >> out. =A0It might just be a note on dangers of using static-ish storag=
e.
>> >>
>> >> --
>> >> Patrick Mueller
>> >> http://muellerware.org
>> >>
>>