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
