incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Neveu (Commented) (JIRA)" <>
Subject [jira] [Commented] (CB-520) WP7 Certification and the Back Button
Date Tue, 17 Apr 2012 20:09:16 GMT


Alan Neveu commented on CB-520:

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.Service called "CustomHack" with an action of "historypop".
This allows javascript to do a simple window.history.back() and then also call:

cordova.exec(null, null, "CustomHack", "HistoryPop", null);

Which essentially tells the history stack that we have gone back one page.  Then when you
tap the hardware back button it only takes tapping it once, rather than twice (or even more
times depending on how many times you did a window.history.back).

I know this is ugly, but here is my code that adds the commandCallParams.Service for "CustomHack"

            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");
            else if (commandCallParams.Service == "CustomHack")
                if (commandCallParams.Action.ToLower() == "historypop")
                    if (history.Count > 1)
                //Debug.WriteLine("ProcessCommand :: " + commandStr);

I say this is "ugly" because I have intentionally used "CustomHack" for the commandCallParams.Service
string. Probably using commandCallParams is not the method that you would choose to implement
such a feature as this.  So that is why I named it intentionally ugly so that you can see
what I am recommending and implement as you see fit.  As long as we can call it easily from
javascript, that is really all we need.  So, in javascript we wind up using this as follows:

cordova.exec(null, null, "CustomHack", "HistoryPop", null);

If you want to pull the window.history.back() into the CordovaClass too, that would be a fine
idea, so that using this would just be one line of code from javascript.

I played around with doing things like replicating the operative code in page_BackKeyPress,
as follows:

Uri next = history.Peek();
IsBackButtonPressed = true;

and I even tried looping through page_BackKeyPress instead of copying/pasting those lines
of code. But it seems that the hardware back button is also doing something *special* in native/external
code even before the Silverlight project gets to do its magic and override it, and the result
was just not quite right.  So I think the best thing is to just use the simple window.history.back
and inform the history stack of our action.

Love to hear your thoughts!
> 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: 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 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.
> My recommendations:
> 2) Perhaps PhoneGap can enhance the WP7 implementation of 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
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:!default.jspa
For more information on JIRA, see:


View raw message