incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Wiping plugins on navigation
Date Wed, 05 Sep 2012 21:25:02 GMT
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
View raw message