incubator-callback-dev mailing list archives

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


View raw message