incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Wiping plugins on navigation
Date Thu, 06 Sep 2012 19:24:44 GMT
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 <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
>

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