incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Wiping plugins on navigation
Date Thu, 06 Sep 2012 19:23:48 GMT
+1

On Thu, Sep 6, 2012 at 12:09 PM, Jesse <purplecabbage@gmail.com> 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

Mime
View raw message