incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Wiping plugins on navigation
Date Thu, 06 Sep 2012 20:04:01 GMT
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 <fil@adobe.com> 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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message