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" <[email protected]> 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
