incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Neveu (Commented) (JIRA)" <>
Subject [jira] [Commented] (CB-520) WP7 Certification and the Back Button
Date Mon, 16 Apr 2012 21:04:17 GMT


Alan Neveu commented on CB-520:

Upon further investigation, it seems that in Scenarios #2 and #3 the device does not know
that we went back in the history, and so when you tap the hardware back button it actually
reloads the page that is currently being shown. I could be wrong, but this is the way it appears
from my view.
> WP7 Certification and the Back Button
> -------------------------------------
>                 Key: CB-520
>                 URL:
>             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 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, 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
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
>; 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) 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:!default.jspa
For more information on JIRA, see:


View raw message