incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse MacFadyen (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CB-520) WP7 Certification and the Back Button
Date Thu, 03 May 2012 21:36:49 GMT

     [ https://issues.apache.org/jira/browse/CB-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jesse MacFadyen resolved CB-520.
--------------------------------

    Resolution: Fixed

Commit is here:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-wp7.git;a=commit;h=2fc1089ae5936ecaf627fad48dbfee9a2d5f3e08

Backbutton presses are passed to js, window.history.back()
If the page changes as a result of the js call, then the event is cancelled.
When the history stack is empty, the page does not change as a result of history.back(), so
the default implementation of exiting the app is performed.

OverrideBackButton is still available if you need greater control over history management.


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

       

Mime
View raw message