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 <[email protected]> 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 <[email protected]> > 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 >
