incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: Wiping plugins on navigation
Date Thu, 06 Sep 2012 19:36:13 GMT
I like the approach where it is up to the plugin developer to handle
this event. We just push an Obj-C notification that a plugin can
listen for - in this case the base class CDVPlugin will automatically
listen for it on an empty function, and if a sub-class plugin wants to
handle it, it overrides this function.

We already do this with handleOpenUrl:

On Thu, Sep 6, 2012 at 12:24 PM, Anis KADRI <> wrote:
> Yeah It could be up to the plugin developer to decide what to do on page
> refreshes. There are indeed multiple cases where you'd want to keep native
> code running (audio/connection/download in the background etc...). In most
> cases though I think destroying and/or saving some state data is what will
> happen for most plugins. I agree with Jesse's simple solution, the one that
> notifies all plugins on page refreshes. Maybe we can add a method to the
> plugin interface that gets called on page refreshes. People are then free
> to override it to do whatever (keep running, save some data, ...) ? Is that
> feasible/reasonable ?
> On Thu, Sep 6, 2012 at 12:09 PM, Jesse <> 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.
>> 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

View raw message