Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Date: Thu, 3 May 2012 21:36:49 +0000 (UTC)
From: "Jesse MacFadyen (JIRA)" <jira@apache.org>
To: callback-dev@incubator.apache.org
Message-ID: 
 <1536253646.23973.1336081009419.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <700998911.29977.1334605097966.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (CB-520) WP7 Certification and the Back Button
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

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

    Resolution: Fixed

Commit is here:
https://git-wip-us.apache.org/repos/asf?p=3Dincubator-cordova-wp7.git;a=3Dc=
ommit;h=3D2fc1089ae5936ecaf627fad48dbfee9a2d5f3e08

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 hi=
story.back(), so the default implementation of exiting the app is performed=
.

OverrideBackButton is still available if you need greater control over hist=
ory management.


               =20
> 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 re=
jected 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 but=
ton in the app in various places, and on WP7 the user can always tap the ha=
rdware back button.  I am trying to use navigator.app.historyBack and it ap=
pears to work, but it does something slightly different than actually tappi=
ng the hardware back button does.  I have also tried using window.history.b=
ack and that works different yet.  I am using JQueryMobile 1.1.0 and so I w=
ind up doing quite a lot of $.mobile.changePage calls to #Page id's, and be=
cause I use multiple .html files I also need to do some rel=3D"external" li=
nks or window.location.href=3D 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 reloa=
ded from scratch which is slow and the user loses any form data they had en=
tered.
> 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 wi=
th this because it is the behavior that the Marketplace testers will be exp=
ecting and validating.
> 2) window.history.back() is giving better results than navigator.app.back=
History, but still not the same as the hardware back button. I think apps w=
ill fail Marketplace certification if they use either of these approaches f=
or soft back buttons.
> 3) When going back to an external page (as opposed to a JQueryMobile #pag=
eID), 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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira