incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Wiping plugins on navigation
Date Thu, 06 Sep 2012 19:57:24 GMT
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" <> 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
>- 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
>- 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.

View raw message