+1
On Thu, Sep 6, 2012 at 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
