incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Wiping plugins on navigation
Date Wed, 05 Sep 2012 21:40:36 GMT
Sure, and I'm a fan of single-page apps (I do work for Google, after
all...), but this causes very chaotic, hard-to-track bugs, so it makes
sense to be robust over a refresh/navigation.


On Wed, Sep 5, 2012 at 5:25 PM, Brian LeRoux <b@brian.io> wrote:

> One thing to note, we tend to advise ppl author single page web apps
> which makes state visibility change an app logic concern (and avoid
> this issue from manifesting). Generally, we can say a page refresh is
> not a great user experience in apps.
>
> On Wed, Sep 5, 2012 at 1:15 PM, Braden Shepherdson <braden@chromium.org>
> wrote:
> > This is intended as a continuation of the discussion started in
> > https://issues.apache.org/jira/browse/CB-1318 .
> >
> > The bug in question is one where one page starts a long native side
> action
> > such as a network call. Then the user navigates the app to another page.
> > When the long action completes, the call returns and the appropriate
> > Javascript callback is looked up and called.
> >
> > However when the page is navigated, the counter that provides supposedly
> > unique names for callbacks is reset, allowing a callback on the new page
> to
> > have the same name as the callback from the old page. It then gets called
> > incorrectly, potentially introducing weird and transient bugs.
> >
> > The proposed solution is to do the following on navigation:
> > - Call a destroy() call on all plugins, which by default does nothing.
> This
> > allows the plugins a chance to cancel any outstanding network requests or
> > do any other cleanup work.
> > - Delete the plugin instance and recreate it.
> >
> > In the bug I also said one step would be to wipe the callback table in
> the
> > Javascript, but that isn't necessary since it would have been wiped by
> the
> > navigation anyway.
> >
> > This issue is cross-platform-ish. It (probably) doesn't apply to
> web-based
> > platforms like WebOS or Bada, because the plugins are Javascript shims
> > rather than native code, and are wiped on navigation like any other
> > Javascript. However this issue does exist on at least Android and iOS,
> and
> > probably a few others as well.
> >
> > I'm proposing to implement the solution outlined above on Android and
> iOS.
> > I don't have the devices or environment to do any other platforms, nor
> am I
> > sure which are necessary. The maintainers of other platforms will have to
> > consider this problem for their platform. I would also update the core
> > plugins to define a destroy() method if they have relevant cleanups to
> make.
> >
> > Thoughts on the approach, things I'm missing?
> >
> > Braden
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message