[
https://issues.apache.org/jira/browse/CB-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Neveu updated CB-520:
--------------------------
Description:
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.
My recommendations:
2) Perhaps PhoneGap can enhance the WP7 implementation of
navigator.app.backHistory so that it works the same as the hardware back
button. It should go back a page and reload that page, and then pressing the
hardware back button on Page 1 should exit the app.
I mark this case as "blocker" priority because it is not possible to get a WP7
app certified for the Marketplace unless the back button works exactly the way
they want it to. It seems that for WP7 we have to design our apps so as to keep
the history as small as possible so that the number of paths through an app are
minimized. We need soft "back" buttons in iOS and BlackBerry, and they are
helpful for Android and WP7, and if we can get navigator.app.backHistory to
behave (on WP7) identical to the hardware back button, I think we will have
forever solved the WP7 back button issue.
was:
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.
> 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 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.
> My recommendations:
> 2) Perhaps PhoneGap can enhance the WP7 implementation of
> navigator.app.backHistory so that it works the same as the hardware back
> button. It should go back a page and reload that page, and then pressing the
> hardware back button on Page 1 should exit the app.
> I mark this case as "blocker" priority because it is not possible to get a
> WP7 app certified for the Marketplace unless the back button works exactly
> the way they want it to. It seems that for WP7 we have to design our apps so
> as to keep the history as small as possible so that the number of paths
> through an app are minimized. We need soft "back" buttons in iOS and
> BlackBerry, and they are helpful for Android and WP7, and if we can get
> navigator.app.backHistory to behave (on WP7) identical to the hardware back
> button, I think we will have forever solved the WP7 back button issue.
--
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
