[jira] [Commented] (CB-520) WP7 Certification and the Back Button

["Alan Neveu (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CB-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255049#comment-13255049 ] 

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: 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