Alright, we seem to have a consensus. I'll start working on this tomorrow for Android. I'll tackle iOS afterwards if no one else wants to look after it; my progress there will require an expensive initialization step while I learn enough Obj-C to do it.
I think this will manifest on Android as a reset() method on plugins called in this situation. On Thu, Sep 6, 2012 at 4:04 PM, Andrew Grieve <[email protected]> wrote: > 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 > > > > >
