Some good use-cases Jesse. Given that we'll just use a reset method, we should also seed the JS callback counter with a random value (as Jimmy originally suggested).
On Thu, Sep 6, 2012 at 3:57 PM, Filip Maj <[email protected]> wrote: > 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 > >
