incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Wiping plugins on navigation
Date Thu, 06 Sep 2012 20:35:32 GMT
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" <braden@chromium.org> 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 <agrieve@chromium.org>
>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 <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
View raw message