I like the approach where it is up to the plugin developer to handle this event. We just push an Obj-C notification that a plugin can listen for - in this case the base class CDVPlugin will automatically listen for it on an empty function, and if a sub-class plugin wants to handle it, it overrides this function.
We already do this with handleOpenUrl: https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Classes/CDVPlugin.m#L75 On Thu, Sep 6, 2012 at 12:24 PM, Anis KADRI <[email protected]> wrote: > Yeah It could be up to the plugin developer to decide what to do on page > refreshes. There are indeed multiple cases where you'd want to keep native > code running (audio/connection/download in the background etc...). In most > cases though I think destroying and/or saving some state data is what will > happen for most plugins. I agree with Jesse's simple solution, the one that > notifies all plugins on page refreshes. Maybe we can add a method to the > plugin interface that gets called on page refreshes. People are then free > to override it to do whatever (keep running, save some data, ...) ? Is that > feasible/reasonable ? > > 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 >>
