Let's create a top-level issue in JIRA and add sub-issues for verification that / implementation of the plugin architecture follows this model for all platforms.
Would be nice to see some native tests for this too :O On 9/6/12 1:20 PM, "Braden Shepherdson" <[email protected]> wrote: >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 >> > >> > >>
