WP7 Certification and the Back Button
-------------------------------------
Key: CB-520
URL: https://issues.apache.org/jira/browse/CB-520
Project: Apache Callback
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: Blocker
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 there are situations in my app in which I need to do a programmatic
version of 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, and because I use multiple .html files I also need to do some
rel="external" links or window.location.href= calls. 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. VERY NICE!!
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 (NICE!)
BackButton tap: Page1 is reloaded from scratch (DOH!)
BackButton tap: exits app
My recommendations:
1) Using the hardware backbutton should serve the history from cache rather
than re-loading the page.
2) navigator.app.backhistory should be modified so that it does exactly the
same thing as the hardware back button. It would be great if there was an
option of whether to serve the page from cache or to re-load it.
I mark this case as "blocker" because it is not possible to get a WP7 app into
the Marketplace unless the back button works exactly the way they want it to.
It seems that keeping the history as thin as possible is the best way so that
the number of paths through an app are minimized.
--
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
