Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of braden@google.com designates
 209.85.210.175 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
In-Reply-To: 
 <CABiQX1XC6acFCSkNdxcW3i4MsQnytcv2PsLR74GmURmBo1A64A@mail.gmail.com>
References: 
 <CAKP6k2t4oW+OkvpCNQMuPi_UYq9J+WZ7Dmv7kVmLRROiOVVb1A@mail.gmail.com>
	<CC6E4DF1.CF31%fil@adobe.com>
	<CABiQX1XC6acFCSkNdxcW3i4MsQnytcv2PsLR74GmURmBo1A64A@mail.gmail.com>
Date: Thu, 6 Sep 2012 16:20:32 -0400
Message-ID: 
 <CAMk5LLmfeNnxDvByoavGmsC3OJMskgK72hjeGF9oeMP-b7SUDA@mail.gmail.com>
Subject: Re: Wiping plugins on navigation
From: Braden Shepherdson <braden@chromium.org>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9340e1d24abb904c90e3956

--14dae9340e1d24abb904c90e3956
Content-Type: text/plain; charset=ISO-8859-1

Alright, we seem to have a consensus. I'll start working on this tomorrow
for Android. I'll tackle iOS afterwards if no one else wants to look after
it; my progress there will require an expensive initialization step while I
learn enough Obj-C to do it.

I think this will manifest on Android as a reset() method on plugins called
in this situation.


On Thu, Sep 6, 2012 at 4:04 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Some good use-cases Jesse.
>
> Given that we'll just use a reset method, we should also seed the JS
> callback counter with a random value (as Jimmy originally suggested).
>
>
> On Thu, Sep 6, 2012 at 3:57 PM, Filip Maj <fil@adobe.com> wrote:
>
> > What Jesse said times a million.
> >
> > Notify plugin of changes. We already do this (on pause, on resume, on
> > message/postmessage). Plugin should handle this.
> >
> > On 9/6/12 12:09 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> >
> > >I don't think that plugins should be recreated, but I also don't think
> > >they should be destroyed during page changes.
> > >In my opinion, the best option is to simply notify the native portion
> > >that the page is changing, and place the responsibility in the hands
> > >of the plugin developer.
> > >
> > >In the case of platforms without a native portion, any persistence
> > >would need to be managed differently, via localStorage or something.
> > >Usually these platforms DO provide a way to play background sounds, or
> > >continue downloading a file across pages.
> > >
> > >Here are some use cases where it makes sense to have a persistent native
> > >piece.
> > >
> > >- an XMPP service, where establishing a connection can take 10
> > >seconds. It would not make sense to have to re-connect when changing
> > >'views' in the application.
> > >- a sound board app, where multiple sounds are loaded from disk ( once
> > >) and used by multiple views in the app
> > >- a game where background music can continue to play even when loading
> > >a new level ( page ), going to the leader-board(page) or the settings
> > >view (page )
> > >- any long running process that does not require continuous
> > >monitoring, like image processing happening in the background even
> > >while navigation views in the app.
> > >- background file transfers
> > >- any UI Extention plugins like a titlebar or a action bar are
> > >technically considered siblings to the webbrowser control anyway, it
> > >makes sense for them to persist between page loads.
> > >
> > >Personally, I consider multiple pages within an app to be multiple
> > >views, so I think it makes sense to continue to have some native
> > >services potentially running across views.
> > >
> > >[PROPOSAL]
> > >
> > >When the page reloads, the following events occur:
> > >
> > >1. All running plugins are notified, but not otherwise impacted
> > >2. the js callback stack is destroyed
> > >
> > >Some assumptions:
> > >- When the JS portion of a plugin in instantiated, it is responsible
> > >for calling it's native portion to re-establish any state.  This is
> > >beyond the scope of the frameworks responsibilities.
> > >- Calls from native to javascript with non-existent callbackIDs fail
> > >gracefully
> > >- Plugin developers write code that behaves well, a big assumption,
> > >but if we assume they are idiots then we have a lot more work to do. (
> > >this item speaks mainly to having adequate documentation so our
> > >developers can be educated. )
> > >
> > >Another, slightly more complex option :
> > >- provide an API whereby a plugin can choose to be destroyed
> > >(returning false from onPageChangeNotification for example), or
> > >request to be persistent somehow.
> > >
> > >--
> > >@purplecabbage
> > >risingj.com
> >
> >
>

--14dae9340e1d24abb904c90e3956--