incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Neveu (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CB-520) WP7 Certification and the Back Button
Date Mon, 16 Apr 2012 19:38:17 GMT
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

        

Mime
View raw message