cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Neveu (Updated) (JIRA)" <>
Subject [jira] [Updated] (CB-520) WP7 Certification and the Back Button
Date Wed, 18 Apr 2012 20:34:40 GMT


Alan Neveu updated CB-520:

    Comment: was deleted

(was: I have spent time re-reading the certification requirements from Microsoft regarding
the (holy) back button. I have also spent time modifying the source for the WP7CordovaClassLib
C# project. I created an additional commandCallParams.Action called "softbackbutton". This
allows the javascript layer to perform a window.history.back while playing nicely with the
hardware back button stack that Cordova maintains.  It is called like this:

cordova.exec(null, null, "CoreEvents", "SoftBackButton", null);

Here is the modified code in CordovaView.xaml.cs that handles commandCallParams, beginning
in line 405 of CordovaWP7 1.6.1:

            if (commandCallParams == null)
                // ERROR
                Debug.WriteLine("ScriptNotify :: " + commandStr);
            else if (commandCallParams.Service == "CoreEvents")
                switch (commandCallParams.Action.ToLower())
                    case "overridebackbutton":
                        string args = commandCallParams.Args;
                        this.OverrideBackButton = (args != null && args.Length >
0 && args.ToLower() == "true");
                if (commandCallParams.Action.ToLower() == "softbackbutton")
                        CordovaBrowser.InvokeScript("eval", "window.history.back()");
                    catch (Exception ex)
                        //do nothing, must have been called from first page, not our fault
                //Debug.WriteLine("ProcessCommand :: " + commandStr);
> WP7 Certification and the Back Button
> -------------------------------------
>                 Key: CB-520
>                 URL:
>             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 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,
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
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
>; 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, 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 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:!default.jspa
For more information on JIRA, see:


View raw message