[
https://issues.apache.org/jira/browse/CB-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse MacFadyen closed CB-520.
------------------------------
> WP7 Certification and the Back Button
> -------------------------------------
>
> Key: CB-520
> URL: https://issues.apache.org/jira/browse/CB-520
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP7
> Affects Versions: 1.6.1
> Environment: VS.NET 2010 and WP7.1 emulator
> Reporter: Alan Neveu
> Assignee: Jesse MacFadyen
> Priority: Critical
> Fix For: 1.8.0
>
>
> I tried submitting my PG 1.5 app to the Windows Marketplace and it was
> rejected due to WP7's requirements for the Back Button. I upgraded to PG
> 1.6.1 and I am inspecting how it works with the hardware back button. It
> seems to work much better, but my app is designed so that it has a soft back
> button in the app in various places, and on WP7 the user can always tap the
> hardware back button. I am trying to use navigator.app.historyBack and it
> appears to work, but it does something slightly different than actually
> tapping the hardware back button does. I have also tried using
> window.history.back and that works different yet. I am using JQueryMobile
> 1.1.0 and so I wind up doing quite a lot of $.mobile.changePage calls to
> #Page id's, and because I use multiple .html files I also need to do some
> rel="external" links or window.location.href= calls. I think my needs are
> similar or the same as those of other WP7 developers. Here is what currently
> happens with PG 1.6.1 in a simple Page1/Page2 JQueryMobile app when using the
> hardware back button versus using navigator.app.historyBack, vs.
> window.history.back:
> SCENARIO #1 - using hardware BackButton only
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
> BackButton tap - goes back to Page1 but page is requested again and reloaded
> from scratch which is slow and the user loses any form data they had entered.
> BackButton tap - exits app (great!)
> SCENARIO #2 - hardware BackButton and navigator.app.backHistory
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
> navigator.app.backHistory(); goes back to Page1 served from cache, which is
> fast and form data is preserved.
> BackButton tap: nothing happens
> BackButton tap: Page1 is reloaded from scratch
> BackButton tap: exits app
> SCENARIO #3 - hardware backButton and window.history.back
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
> window.history.back(); goes back to Page1 served from cache.
> BackButton tap: Page1 is reloaded from scratch (DOH!)
> BackButton tap: exits app
> My Observations:
> 1) The hardware back button does not use the cached page - it
> reloads/re-requests the page. This is kind of a drag but I think we have to
> just go with this because it is the behavior that the Marketplace testers
> will be expecting and validating.
> 2) window.history.back() is giving better results than
> navigator.app.backHistory, but still not the same as the hardware back
> button. I think apps will fail Marketplace certification if they use either
> of these approaches for soft back buttons.
> 3) When going back to an external page (as opposed to a JQueryMobile
> #pageID), window.history.back works but navigator.app.backHistory does not
> seem to do anything at all. I say window.history.back "works" but it is
> still the same result as in Scenario #3 above, which is not good.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
