incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Neveu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-520) WP7 Certification and the Back Button
Date Mon, 23 Apr 2012 20:06:34 GMT

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

Alan Neveu commented on CB-520:
-------------------------------

Update... My app just passed Marketplace certification.  Here is a functional summary of what
I needed that the 1.6.1 build did not provide:

1) Because I use JQueryMobile, I needed the Back Button to be able to know if the previous
page in the history was just a hash tag navigation, and if so, just do a window.history.back.

2) There are some instances in which my app needed the page to then also be reloaded, and
so I had to put a parameter on the second page to indicate this, which is &_wpBackReload=1
.

3) The WP7 Marketplace requirements are very strict when it comes to hitting Back on the first
page of the app and that it must exit the app.  If you wind up deep in the history and the
tester thinks he is stuck in your app and no amount of hitting the Back button will exit the
app, your app will be failed. So the best thing is to be able to tell Cordova to clear the
stack whenever your app navigates to the Home page. That can be done using the historystackclear
action.

4) Sometimes my app needed to just do a simple historystackpop and remove whatever is the
top item in the stack. It is hard to explain why, other than perhaps a bug in WP7's embeddable
browser control.  So that is why I needed the action called historystackpop.

5) My standard Back buttons for other platforms that do not really go back but instead just
reload the home page needed to become "soft" back buttons if the running platform is WP7.
So that is why I needed the action called "softbackbutton". This way my navigation looks 100%
identical across WP7, iOS, Android, and BlackBerry, but the implementation is slightly different
in that WP7 calls the "softbackbutton" action whereas the others navigate (forward) to the
home page. The if statement for that lives in my javascript.

I hope this helps, it's kind of a mess I know.  Thanks for listening!
                
> 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: Minor
>
> 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