date:20121026

Okay, Simon, Bryce and I worked through the (final?) issue they were seeing
with CB-1745.

I've re-tagged the JS and Android again. Let's get this release rolling!


On Fri, Oct 26, 2012 at 1:37 PM, Gord Tanner  wrote:

> thanks :)
>
> Teach a man to fish!
>
> retagged blackberry
>
> On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve 
> wrote:
>
> > FYI - the problem I was facing was not knowing the git foo for pushing
> > tags. To re-tag:
> >
> > git fetch apache # Fetch tags
> > git tag --force 2.2.0rc2 # Re-tag locally
> > git push apache master --tag # Push tags
> >
> > I'll put this on the CuttingReleases wiki page.
> >
> >
> > On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner 
> wrote:
> >
> > > anyone have any objections of getting this fix into blackberry for 2.2?
> > >
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139
> > >
> > > also I fail at teh git so if there is no objections could someone retag
> > > blackberry for me?
> > >
> > > On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve  > > >wrote:
> > >
> > > > Sounds good. I've now re-tagged the JS and Android.
> > > >
> > > >
> > > > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald <
> > > > simon.macdon...@gmail.com
> > > > > wrote:
> > > >
> > > > > I'm still seeing the bug but I don't think it should hold up the
> > > tagging
> > > > of
> > > > > 2.2.0rc2 at this point. I created a small sync Plugin for testing
> and
> > > it
> > > > > runs fine in my mobile spec test case. Now the same plugin called
> in
> > > the
> > > > > downstream app which uses the same Android library project for
> > Cordova
> > > > and
> > > > > the same .js file returns the wrong value when I call the plugin.
> At
> > > this
> > > > > point I'm not convinced it is a Cordova issue.
> > > > >
> > > > > Simon Mac Donald
> > > > > http://hi.im/simonmacdonald
> > > > >
> > > > >
> > > > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve <
> agri...@chromium.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Joe - my thinking here is that it's fine to re-tag and re-tag
> until
> > > we
> > > > > > actually produce an RC with everything tagged. rc2 is still in
> the
> > > > > process
> > > > > > of being tagged, and until the tagging is all done, it just
> causes
> > > more
> > > > > > work to scratch it and have to re-tag all of the other repos.
> Once
> > we
> > > > > > create an rc2 archive though, no more adjusting.
> > > > > >
> > > > > > Marcel - yes, my intention is to retag the JS with the Android
> > > changes,
> > > > > and
> > > > > > to update the JS in android repo and then re-tag that as well.
> > Simon
> > > > was
> > > > > > still seeing a bug with one of his projects though, even after
> the
> > > fix,
> > > > > so
> > > > > > I'd like to wait for his verification before continuing.
> > > > > >
> > > > > >
> > > > > > On Thu, Oct 25, 2012 at 5:13 PM, Michael Brooks <
> > > > > mich...@michaelbrooks.ca
> > > > > > >wrote:
> > > > > >
> > > > > > > Sorry, just catching up on the conversations.
> > > > > > >
> > > > > > >
> > > > > > > > Ey Mr. Brooks do you have a script or something that we can
> use
> > > to
> > > > > > > > easily/quickly clone/create the behemoth "tag all the things"
> > > > parent
> > > > > > > issue
> > > > > > > > with subtasks in JIRA? This seems like a worthwhile pursuit.
> > > > > > >
> > > > > > >
> > > > > > > Just find go to the parent issue (e.g. Tag
> > > > > > > 2.2.0rc1),
> > > > > > > click "More Actions", and click "Clone." JIRA will do the rest
> by
> > > > > > spamming
> > > > > > > everyone.
> > > > > > >
> > > > > > > For the most part, I've worded each task in a generic manner,
> but
> > > you
> > > > > may
> > > > > > > need to edit the odd sub-tasks description if it mentions a
> > > version.
> > > > > > >
> > > > > > > Michael
> > > > > > >
> > > > > > > On Thu, Oct 25, 2012 at 2:08 PM, Marcel Kinard <
> > cmarc...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > I'm interested in the latest fix that Andrew put in the js
> > repo:
> > > > > > > >
> > https://git-wip-us.apache.org/**repos/asf?p=incubator-cordova-**
> > > > > > > >
> > > js.git;a=commitdiff;h=**97a05cb0f672ee1bfb7e9e14a0dfd4**52d7763ba9<
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commitdiff;h=97a05cb0f672ee1bfb7e9e14a0dfd452d7763ba9
> > > > > > > >
> > > > > > > > https://issues.apache.org/**jira/browse/CB-1745<
> > > > > > > https://issues.apache.org/jira/browse/CB-1745>
> > > > > > > >
> > > > > > > > When I browse the Apache repos, I see that:
> > > > > > > > 1) this fix was committed to the js repo after the rc2 tag.
> Is
> > > this
> > > > > > > thread
> > > > > > > > going to include this fix inside the rc2 tag?
> > > > > > > > 2) the corresponding js artifact in the android repo needs to
> > be
> > > > > > > re

[jira] [Reopened] (CB-1745) Android's exec() function no longer returns the payload of synchronous calls

2012-10-26 Thread Andrew Grieve (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Grieve reopened CB-1745:
---


Problem is still happening when recursive exec() calls are made.

> Android's exec() function no longer returns the payload of synchronous calls
> 
>
> Key: CB-1745
> URL: https://issues.apache.org/jira/browse/CB-1745
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: Master
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
> Fix For: 2.2.0
>
>
> This isn't supported cross-platform, but did work on Android before the 
> recent refactorings. We should deprecate it and remove support in 6 months.
> A a new Plugin class extends the org.apache.cordova.api.Plugin class and over 
> rides the isSync method. The method is setup to return "true" every time. 
> When the method is calls from the JavaScript side like this:
> var returnValue = cordova.exec(null, null, "PluginName", "method", [ 
> "property" ]);
> The value of "returnValue" is "undefined".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1745) Android's exec() function no longer returns the payload of synchronous calls

2012-10-26 Thread Andrew Grieve (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Grieve resolved CB-1745.
---

Resolution: Fixed

Fixed by re-working queue processing on the JS side:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commit;h=d819e1e60599c12ac831379b06bba9110e9f1790

And by disabling limiting of JS payloads:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a=commit;h=678ae2d684a39017bec3586883c3a528190d4d20

> Android's exec() function no longer returns the payload of synchronous calls
> 
>
> Key: CB-1745
> URL: https://issues.apache.org/jira/browse/CB-1745
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: Master
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
> Fix For: 2.2.0
>
>
> This isn't supported cross-platform, but did work on Android before the 
> recent refactorings. We should deprecate it and remove support in 6 months.
> A a new Plugin class extends the org.apache.cordova.api.Plugin class and over 
> rides the isSync method. The method is setup to return "true" every time. 
> When the method is calls from the JavaScript side like this:
> var returnValue = cordova.exec(null, null, "PluginName", "method", [ 
> "property" ]);
> The value of "returnValue" is "undefined".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1738) PhoneGap iOS 6 - network.connection.type issue during turning OFF airplane mode


 [ 
https://issues.apache.org/jira/browse/CB-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jasper updated CB-1738:
---

Summary: PhoneGap iOS 6 -  network.connection.type issue during turning OFF 
airplane mode  (was: PhoneGap iOS 6 - wrong network.connection.type during 
turning OFF airplane mode)

> PhoneGap iOS 6 -  network.connection.type issue during turning OFF airplane 
> mode
> 
>
> Key: CB-1738
> URL: https://issues.apache.org/jira/browse/CB-1738
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 1.5.0, 2.0.0
> Environment: i am testing on two iPhone4 one running OS5 ,and one on 
> OS6
>Reporter: Jasper
>Assignee: Shazron Abdullah
>Priority: Minor
>  Labels: ios, network.connection
> Fix For: 2.2.0
>
>
> update on 26Oct, 2012
> After more investigation I think this probably is an iOS6 issue
> The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the 
> radio status probably doesn't matter ) on banner
> My application will invoke an RPC , which will fail due to error "A server 
> with specified hostname could not be found" Code= 1003
> So I think the problem is iOS6 lies about the status, It says wifi is ready 
> while it is not entirely. From my observation error occurs within 15s after 
> wifi symbol shows up. After 15s almost for sure there will be no network 
> error. 
> This issue cannot be reproduced on iOS5. It could be a problem within a LAN 
> environment too ( I am hitting a server within company domain )
> PhoneGap probably got tricked by the iOS network status too. Maybe there is 
> something else PhoneGap can check, but not sure.
> Meanwhile I will lower the bug priority  and report an issue to Apple.
> 
> 24Oct 2012
> I have an app that talks to a server. Before making an RPC I use the PG API 
> to check for connectivity: 
> http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
>  code snippet:
> var networkState = navigator.network.connection.type
> if (networkState == "none" || networkState == "unknown")
> {
> //DO NOT make connection 
> }
> Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6) 
> 1. Turn ON airplane mode from setting. wait until the radio and wifi are 
> fully OFF 
> 2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on 
> the top left of the banner the connectivity status is showing "searching..."
> 3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns 
> "wifi" (iOS6)
> another minor observation - on iOS6 it takes double time to turn off the 
> airplane mode.
> iOS5 it takes like around 3 seconds to have the connectivity reestablished, 
> before i finish the following actions: toggle the mode button, close the 
> setting app. foreground my app, click on a button. 
> iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.
> -

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1738) PhoneGap iOS 6 - network.connection.type issue when turning OFF airplane mode


 [ 
https://issues.apache.org/jira/browse/CB-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jasper updated CB-1738:
---

Summary: PhoneGap iOS 6 -  network.connection.type issue when turning OFF 
airplane mode  (was: PhoneGap iOS 6 -  network.connection.type issue during 
turning OFF airplane mode)

> PhoneGap iOS 6 -  network.connection.type issue when turning OFF airplane mode
> --
>
> Key: CB-1738
> URL: https://issues.apache.org/jira/browse/CB-1738
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 1.5.0, 2.0.0
> Environment: i am testing on two iPhone4 one running OS5 ,and one on 
> OS6
>Reporter: Jasper
>Assignee: Shazron Abdullah
>Priority: Minor
>  Labels: ios, network.connection
> Fix For: 2.2.0
>
>
> update on 26Oct, 2012
> After more investigation I think this probably is an iOS6 issue
> The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the 
> radio status probably doesn't matter ) on banner
> My application will invoke an RPC , which will fail due to error "A server 
> with specified hostname could not be found" Code= 1003
> So I think the problem is iOS6 lies about the status, It says wifi is ready 
> while it is not entirely. From my observation error occurs within 15s after 
> wifi symbol shows up. After 15s almost for sure there will be no network 
> error. 
> This issue cannot be reproduced on iOS5. It could be a problem within a LAN 
> environment too ( I am hitting a server within company domain )
> PhoneGap probably got tricked by the iOS network status too. Maybe there is 
> something else PhoneGap can check, but not sure.
> Meanwhile I will lower the bug priority  and report an issue to Apple.
> 
> 24Oct 2012
> I have an app that talks to a server. Before making an RPC I use the PG API 
> to check for connectivity: 
> http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
>  code snippet:
> var networkState = navigator.network.connection.type
> if (networkState == "none" || networkState == "unknown")
> {
> //DO NOT make connection 
> }
> Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6) 
> 1. Turn ON airplane mode from setting. wait until the radio and wifi are 
> fully OFF 
> 2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on 
> the top left of the banner the connectivity status is showing "searching..."
> 3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns 
> "wifi" (iOS6)
> another minor observation - on iOS6 it takes double time to turn off the 
> airplane mode.
> iOS5 it takes like around 3 seconds to have the connectivity reestablished, 
> before i finish the following actions: toggle the mode button, close the 
> setting app. foreground my app, click on a button. 
> iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.
> -

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: FYI new convienance redirect on issues.cordova.io

2012-10-26 Thread Michal Mocny

+1. Big Time.

On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux  wrote:
> issues.cordova.io ---> https://issues.apache.org/jira/browse/CB
> issues.cordova.io/1234 ---> https://issues.apache.org/jira/browse/CB-1234

FYI new convienance redirect on issues.cordova.io

2012-10-26 Thread Brian LeRoux

issues.cordova.io ---> https://issues.apache.org/jira/browse/CB
issues.cordova.io/1234 ---> https://issues.apache.org/jira/browse/CB-1234

[jira] [Updated] (CB-1738) PhoneGap iOS 6 - wrong network.connection.type during turning OFF airplane mode


 [ 
https://issues.apache.org/jira/browse/CB-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jasper updated CB-1738:
---

Priority: Minor  (was: Major)

> PhoneGap iOS 6 - wrong network.connection.type during turning OFF airplane 
> mode
> ---
>
> Key: CB-1738
> URL: https://issues.apache.org/jira/browse/CB-1738
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 1.5.0, 2.0.0
> Environment: i am testing on two iPhone4 one running OS5 ,and one on 
> OS6
>Reporter: Jasper
>Assignee: Shazron Abdullah
>Priority: Minor
>  Labels: ios, network.connection
> Fix For: 2.2.0
>
>
> update on 26Oct, 2012
> After more investigation I think this probably is an iOS6 issue
> The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the 
> radio status probably doesn't matter ) on banner
> My application will invoke an RPC , which will fail due to error "A server 
> with specified hostname could not be found" Code= 1003
> So I think the problem is iOS6 lies about the status, It says wifi is ready 
> while it is not entirely. From my observation error occurs within 15s after 
> wifi symbol shows up. After 15s almost for sure there will be no network 
> error. 
> This issue cannot be reproduced on iOS5. It could be a problem within a LAN 
> environment too ( I am hitting a server within company domain )
> PhoneGap probably got tricked by the iOS network status too. Maybe there is 
> something else PhoneGap can check, but not sure.
> Meanwhile I will lower the bug priority  and report an issue to Apple.
> 
> 24Oct 2012
> I have an app that talks to a server. Before making an RPC I use the PG API 
> to check for connectivity: 
> http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
>  code snippet:
> var networkState = navigator.network.connection.type
> if (networkState == "none" || networkState == "unknown")
> {
> //DO NOT make connection 
> }
> Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6) 
> 1. Turn ON airplane mode from setting. wait until the radio and wifi are 
> fully OFF 
> 2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on 
> the top left of the banner the connectivity status is showing "searching..."
> 3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns 
> "wifi" (iOS6)
> another minor observation - on iOS6 it takes double time to turn off the 
> airplane mode.
> iOS5 it takes like around 3 seconds to have the connectivity reestablished, 
> before i finish the following actions: toggle the mode button, close the 
> setting app. foreground my app, click on a button. 
> iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.
> -

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1738) PhoneGap iOS 6 - wrong network.connection.type during turning OFF airplane mode

[
https://issues.apache.org/jira/browse/CB-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jasper updated CB-1738:
---

Description:
update on 26Oct, 2012

After more investigation I think this probably is an iOS6 issue
The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the
radio status probably doesn't matter ) on banner
My application will invoke an RPC , which will fail due to error "A server with
specified hostname could not be found" Code= 1003

So I think the problem is iOS6 lies about the status, It says wifi is ready
while it is not entirely. From my observation error occurs within 15s after
wifi symbol shows up. After 15s almost for sure there will be no network error.

This issue cannot be reproduced on iOS5. It could be a problem within a LAN
environment too ( I am hitting a server within company domain )

PhoneGap probably got tricked by the iOS network status too. Maybe there is
something else PhoneGap can check, but not sure.
Meanwhile I will lower the bug priority and report an issue to Apple.

24Oct 2012
I have an app that talks to a server. Before making an RPC I use the PG API to
check for connectivity:
http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
code snippet:

var networkState = navigator.network.connection.type

if (networkState == "none" || networkState == "unknown")
{
//DO NOT make connection
}

Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6)

1. Turn ON airplane mode from setting. wait until the radio and wifi are fully
OFF

2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on
the top left of the banner the connectivity status is showing "searching..."

3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns
"wifi" (iOS6)

another minor observation - on iOS6 it takes double time to turn off the
airplane mode.
iOS5 it takes like around 3 seconds to have the connectivity reestablished,
before i finish the following actions: toggle the mode button, close the
setting app. foreground my app, click on a button.
iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.

was:

update on 26Oct, 2012

This issue cannot be reproduced on iOS5. It could be a problem within a LAN
environment too ( I am hitting a server within company domain )

PhoneGap probably got tricked by the iOS network status too. Maybe there is
something else PhoneGap can check, but not sure.
Meanwhile I will lower the bug priority and report an issue to Apple.

var networkState = navigator.network.connection.type

if (networkState == "none" || networkState == "unknown")
{
//DO NOT make connection
}

Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6)

1. Turn ON airplane mode from setting. wait until the radio and wifi are fully
OFF

2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on
the top left of the banner the connectivity status is showing "searching..."

3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns
"wifi" (iOS6)

> PhoneGap iOS 6 - wrong network.connection.type during turning OFF airplane
> mode
> -

[jira] [Updated] (CB-1738) PhoneGap iOS 6 - wrong network.connection.type during turning OFF airplane mode


 [ 
https://issues.apache.org/jira/browse/CB-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jasper updated CB-1738:
---

Description: 

update on 26Oct, 2012

After more investigation I think this probably is an iOS6 issue
The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the 
radio status probably doesn't matter ) on banner
My application will invoke an RPC , which will fail due to error "A server with 
specified hostname could not be found" Code= 1003

So I think the problem is iOS6 lies about the status, It says wifi is ready 
while it is not entirely. From my observation error occurs within 15s after 
wifi symbol shows up. After 15s almost for sure there will be no network error. 

This issue cannot be reproduced on iOS5. It could be a problem within a LAN 
environment too ( I am hitting a server within company domain )


PhoneGap probably got tricked by the iOS network status too. Maybe there is 
something else PhoneGap can check, but not sure.
Meanwhile I will lower the bug priority  and report an issue to Apple.




24Oct 2012
I have an app that talks to a server. Before making an RPC I use the PG API to 
check for connectivity: 
http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
 code snippet:

var networkState = navigator.network.connection.type

if (networkState == "none" || networkState == "unknown")
{
//DO NOT make connection 
}

Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6) 

1. Turn ON airplane mode from setting. wait until the radio and wifi are fully 
OFF 

2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on 
the top left of the banner the connectivity status is showing "searching..."

3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns 
"wifi" (iOS6)

another minor observation - on iOS6 it takes double time to turn off the 
airplane mode.
iOS5 it takes like around 3 seconds to have the connectivity reestablished, 
before i finish the following actions: toggle the mode button, close the 
setting app. foreground my app, click on a button. 
iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.


-




  was:
I have an app that talks to a server. Before making an RPC I use the PG API to 
check for connectivity: 
http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
 code snippet:

var networkState = navigator.network.connection.type

if (networkState == "none" || networkState == "unknown")
{
//DO NOT make connection 
}

Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6) 

1. Turn ON airplane mode from setting. wait until the radio and wifi are fully 
OFF 

2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on 
the top left of the banner the connectivity status is showing "searching..." 

3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns 
"wifi" (iOS6)

another minor observation - on iOS6 it takes double time to turn off the 
airplane mode.
iOS5 it takes like around 3 seconds to have the connectivity reestablished, 
before i finish the following actions: toggle the mode button, close the 
setting app. foreground my app, click on a button. 
iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.



> PhoneGap iOS 6 - wrong network.connection.type during turning OFF airplane 
> mode
> ---
>
> Key: CB-1738
> URL: https://issues.apache.org/jira/browse/CB-1738
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 1.5.0, 2.0.0
> Environment: i am testing on two iPhone4 one running OS5 ,and one on 
> OS6
>Reporter: Jasper
>Assignee: Shazron Abdullah
>  Labels: ios, network.connection
> Fix For: 2.2.0
>
>
> update on 26Oct, 2012
> After more investigation I think this probably is an iOS6 issue
> The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the 
> radio status probably doesn't matter ) on banner
> My application will invoke an RPC , which will fail due to error "A server 
> with specified hostname could not be found" Code= 1003
> So I think the problem is iOS6 lies about the status, It says wifi is ready 
> while it is not entirely. From my observation error occurs within 15s after 
> wifi symbol shows up. After 15s almost for sure there will be no network 
> error. 
> This issue cannot be reproduced on iOS5. It could be a problem within a LAN 
> environm

more benchmarking in mobile-spec

2012-10-26 Thread Brian LeRoux

eh folks, any thoughts on using
https://github.com/robohornet/robohornet for benching?

Re: 2.2.0rc2 Monday?

2012-10-26 Thread Gord Tanner

thanks :)

Teach a man to fish!

retagged blackberry

On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve  wrote:

> FYI - the problem I was facing was not knowing the git foo for pushing
> tags. To re-tag:
>
> git fetch apache # Fetch tags
> git tag --force 2.2.0rc2 # Re-tag locally
> git push apache master --tag # Push tags
>
> I'll put this on the CuttingReleases wiki page.
>
>
> On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner  wrote:
>
> > anyone have any objections of getting this fix into blackberry for 2.2?
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139
> >
> > also I fail at teh git so if there is no objections could someone retag
> > blackberry for me?
> >
> > On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve  > >wrote:
> >
> > > Sounds good. I've now re-tagged the JS and Android.
> > >
> > >
> > > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald <
> > > simon.macdon...@gmail.com
> > > > wrote:
> > >
> > > > I'm still seeing the bug but I don't think it should hold up the
> > tagging
> > > of
> > > > 2.2.0rc2 at this point. I created a small sync Plugin for testing and
> > it
> > > > runs fine in my mobile spec test case. Now the same plugin called in
> > the
> > > > downstream app which uses the same Android library project for
> Cordova
> > > and
> > > > the same .js file returns the wrong value when I call the plugin. At
> > this
> > > > point I'm not convinced it is a Cordova issue.
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > > >
> > > >
> > > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve  >
> > > > wrote:
> > > >
> > > > > Joe - my thinking here is that it's fine to re-tag and re-tag until
> > we
> > > > > actually produce an RC with everything tagged. rc2 is still in the
> > > > process
> > > > > of being tagged, and until the tagging is all done, it just causes
> > more
> > > > > work to scratch it and have to re-tag all of the other repos. Once
> we
> > > > > create an rc2 archive though, no more adjusting.
> > > > >
> > > > > Marcel - yes, my intention is to retag the JS with the Android
> > changes,
> > > > and
> > > > > to update the JS in android repo and then re-tag that as well.
> Simon
> > > was
> > > > > still seeing a bug with one of his projects though, even after the
> > fix,
> > > > so
> > > > > I'd like to wait for his verification before continuing.
> > > > >
> > > > >
> > > > > On Thu, Oct 25, 2012 at 5:13 PM, Michael Brooks <
> > > > mich...@michaelbrooks.ca
> > > > > >wrote:
> > > > >
> > > > > > Sorry, just catching up on the conversations.
> > > > > >
> > > > > >
> > > > > > > Ey Mr. Brooks do you have a script or something that we can use
> > to
> > > > > > > easily/quickly clone/create the behemoth "tag all the things"
> > > parent
> > > > > > issue
> > > > > > > with subtasks in JIRA? This seems like a worthwhile pursuit.
> > > > > >
> > > > > >
> > > > > > Just find go to the parent issue (e.g. Tag
> > > > > > 2.2.0rc1),
> > > > > > click "More Actions", and click "Clone." JIRA will do the rest by
> > > > > spamming
> > > > > > everyone.
> > > > > >
> > > > > > For the most part, I've worded each task in a generic manner, but
> > you
> > > > may
> > > > > > need to edit the odd sub-tasks description if it mentions a
> > version.
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > > On Thu, Oct 25, 2012 at 2:08 PM, Marcel Kinard <
> cmarc...@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > I'm interested in the latest fix that Andrew put in the js
> repo:
> > > > > > >
> https://git-wip-us.apache.org/**repos/asf?p=incubator-cordova-**
> > > > > > >
> > js.git;a=commitdiff;h=**97a05cb0f672ee1bfb7e9e14a0dfd4**52d7763ba9<
> > > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commitdiff;h=97a05cb0f672ee1bfb7e9e14a0dfd452d7763ba9
> > > > > > >
> > > > > > > https://issues.apache.org/**jira/browse/CB-1745<
> > > > > > https://issues.apache.org/jira/browse/CB-1745>
> > > > > > >
> > > > > > > When I browse the Apache repos, I see that:
> > > > > > > 1) this fix was committed to the js repo after the rc2 tag. Is
> > this
> > > > > > thread
> > > > > > > going to include this fix inside the rc2 tag?
> > > > > > > 2) the corresponding js artifact in the android repo needs to
> be
> > > > > > refreshed
> > > > > > > to pick up this fix, and I don't see that commit at all. Is
> > someone
> > > > > going
> > > > > > > to do that? And then will the rc2 tag on this repo include this
> > > > > refresh?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > -- Marcel Kinard
> > > > > > >
> > > > > > >
> > > > > > > On 10/25/2012 4:03 PM, Andrew Grieve wrote:
> > > > > > >
> > > > > > >> Okay. I'll co-ordinate with Simon on the re-tagging. He's
> still
> > > > > working
> > > > > > >> through one of the bugs.
> > > > > > >>
> > > > > > >>

[jira] [Created] (CB-1750) fileTransfer.upload not working - WP7

2012-10-26 Thread Emiliano Angelini (JIRA)

Emiliano Angelini created CB-1750:
-

 Summary: fileTransfer.upload not working  - WP7
 Key: CB-1750
 URL: https://issues.apache.org/jira/browse/CB-1750
 Project: Apache Cordova
  Issue Type: Bug
  Components: WP7
Affects Versions: 2.2.0
 Environment: Using Windows 7, VisualStudio 2010 express for windows 
Phone.
Testing on a device (Nokia Lumia 900 and emulator)
Reporter: Emiliano Angelini
Assignee: Jesse MacFadyen


Hi,

I've tryed to upload a File in an App that I'm developing and also tested the 
CordovaExample that comes inside incubator-cordova-wp7, and everytime I called  
FileTransfer.upload I got an error like this one:

options = 
["{\"filePath\":\"test.txt\",\"server\":\"http://posttestserver.com/post.php?dir=cordovaTest\",\"fileKey\":\"file\",\"fileName\":\"newFile.txt\",\"mimeType\":\"text/plain\",\"params\":\"key1=value1&key2=value2\"}";]
A first chance exception of type 'System.InvalidCastException' occurred in 
System.ServiceModel.Web.dll
A first chance exception of type 'System.InvalidCastException' occurred in 
System.ServiceModel.Web.dll
InvalidCastException
Failed to deserialize 
WP7CordovaClassLib.Cordova.Commands.FileTransfer+UploadOptions[] with JSON 
value :: 
["{\"filePath\":\"test.txt\",\"server\":\"http://posttestserver.com/post.php?dir=cordovaTest\",\"fileKey\":\"file\",\"fileName\":\"newFile.txt\",\"mimeType\":\"text/plain\",\"params\":\"key1=value1&key2=value2\"}";]
A first chance exception of type 'System.NullReferenceException' occurred in 
WP7CordovaClassLib.dll
GapBrowser_Navigated :: /app/www/file.html#


I also tryed modifying cordova-2.2.0.js to send the options parameter as an 
object instead of an Array (that solved the JSON deserialization) but ended up 
with an Invalid left hand side assignment error.

Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: PhoneGap interface on Android vs. addJavaScriptInterface

2012-10-26 Thread Fazekas László

Cool! :)

Kind regards,
  Laszlo

2012.10.26. 19:12 keltezéssel, Andrew Grieve írta:
> Hey Laszlo,
> 
> You'll be happy to know that with our next release, we've implemented a new
> Android bridge, which is even faster than using loadUrl! If you're
> interested in the details, have a look at this bug:
> 
> https://issues.apache.org/jira/browse/CB-638
> 
> Andrew
> 
> 
> On Fri, Oct 26, 2012 at 1:00 PM, Fazekas László wrote:
> 
>> Hi!
>>
>> About 1 month ago, I've developed a PhoneGap application to one of my
>> clients. He dropped it back to me, because the UI was slow and laggy on
>> a Vodafone SmartTab. After some debug, I've realized, the problem is the
> 
>> speed of the PhoneGap interface, and the XHR poll mechanism (I've found
>> some info about it here:
>> http://nullisnotanobject.com/phonegap-native-bridge). The final solution
> 
>> was creation of a new PhoneGap like interface through
>> addJavascriptInterface and loadUrl. This new interface is working like a
> 
>> charm without lag. I think, the perfect solution would be an optional
>> support of addJavascriptInterface/loadUrl way. If it is working on the
>> device without bugs, PhoneGap could use this faster way automatically
>> instead of the present solution, or developers could enable it
>> optionally. For example, in my case, the application will be used only
>> on Vodafone SmartTabs, where the standard addJavascriptInterface/loadUrl
> 
>> solution working fine and fast, so in this case I could enable it.
>>
>> Kind regards,
>>   Laszlo
>>
> 
> 
> 
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2441/5355 - Release Date: 10/26/12
>

Re: PhoneGap interface on Android vs. addJavaScriptInterface

2012-10-26 Thread Michal Mocny

To be clear, that means version 2.2 will have the changes.  2.2 is
already approaching its second release candidate so you could expect
it out in some short number of weeks.

On Fri, Oct 26, 2012 at 1:12 PM, Andrew Grieve  wrote:
> Hey Laszlo,
>
> You'll be happy to know that with our next release, we've implemented a new
> Android bridge, which is even faster than using loadUrl! If you're
> interested in the details, have a look at this bug:
>
> https://issues.apache.org/jira/browse/CB-638
>
> Andrew
>
>
> On Fri, Oct 26, 2012 at 1:00 PM, Fazekas László wrote:
>
>> Hi!
>>
>> About 1 month ago, I've developed a PhoneGap application to one of my
>> clients. He dropped it back to me, because the UI was slow and laggy on
>> a Vodafone SmartTab. After some debug, I've realized, the problem is the
>> speed of the PhoneGap interface, and the XHR poll mechanism (I've found
>> some info about it here:
>> http://nullisnotanobject.com/phonegap-native-bridge). The final solution
>> was creation of a new PhoneGap like interface through
>> addJavascriptInterface and loadUrl. This new interface is working like a
>> charm without lag. I think, the perfect solution would be an optional
>> support of addJavascriptInterface/loadUrl way. If it is working on the
>> device without bugs, PhoneGap could use this faster way automatically
>> instead of the present solution, or developers could enable it
>> optionally. For example, in my case, the application will be used only
>> on Vodafone SmartTabs, where the standard addJavascriptInterface/loadUrl
>> solution working fine and fast, so in this case I could enable it.
>>
>> Kind regards,
>>   Laszlo
>>

Re: 2.2.0rc2 Monday?

FYI - the problem I was facing was not knowing the git foo for pushing
tags. To re-tag:

git fetch apache # Fetch tags
git tag --force 2.2.0rc2 # Re-tag locally
git push apache master --tag # Push tags

I'll put this on the CuttingReleases wiki page.


On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner  wrote:

> anyone have any objections of getting this fix into blackberry for 2.2?
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139
>
> also I fail at teh git so if there is no objections could someone retag
> blackberry for me?
>
> On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve  >wrote:
>
> > Sounds good. I've now re-tagged the JS and Android.
> >
> >
> > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald <
> > simon.macdon...@gmail.com
> > > wrote:
> >
> > > I'm still seeing the bug but I don't think it should hold up the
> tagging
> > of
> > > 2.2.0rc2 at this point. I created a small sync Plugin for testing and
> it
> > > runs fine in my mobile spec test case. Now the same plugin called in
> the
> > > downstream app which uses the same Android library project for Cordova
> > and
> > > the same .js file returns the wrong value when I call the plugin. At
> this
> > > point I'm not convinced it is a Cordova issue.
> > >
> > > Simon Mac Donald
> > > http://hi.im/simonmacdonald
> > >
> > >
> > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve 
> > > wrote:
> > >
> > > > Joe - my thinking here is that it's fine to re-tag and re-tag until
> we
> > > > actually produce an RC with everything tagged. rc2 is still in the
> > > process
> > > > of being tagged, and until the tagging is all done, it just causes
> more
> > > > work to scratch it and have to re-tag all of the other repos. Once we
> > > > create an rc2 archive though, no more adjusting.
> > > >
> > > > Marcel - yes, my intention is to retag the JS with the Android
> changes,
> > > and
> > > > to update the JS in android repo and then re-tag that as well. Simon
> > was
> > > > still seeing a bug with one of his projects though, even after the
> fix,
> > > so
> > > > I'd like to wait for his verification before continuing.
> > > >
> > > >
> > > > On Thu, Oct 25, 2012 at 5:13 PM, Michael Brooks <
> > > mich...@michaelbrooks.ca
> > > > >wrote:
> > > >
> > > > > Sorry, just catching up on the conversations.
> > > > >
> > > > >
> > > > > > Ey Mr. Brooks do you have a script or something that we can use
> to
> > > > > > easily/quickly clone/create the behemoth "tag all the things"
> > parent
> > > > > issue
> > > > > > with subtasks in JIRA? This seems like a worthwhile pursuit.
> > > > >
> > > > >
> > > > > Just find go to the parent issue (e.g. Tag
> > > > > 2.2.0rc1),
> > > > > click "More Actions", and click "Clone." JIRA will do the rest by
> > > > spamming
> > > > > everyone.
> > > > >
> > > > > For the most part, I've worded each task in a generic manner, but
> you
> > > may
> > > > > need to edit the odd sub-tasks description if it mentions a
> version.
> > > > >
> > > > > Michael
> > > > >
> > > > > On Thu, Oct 25, 2012 at 2:08 PM, Marcel Kinard  >
> > > > wrote:
> > > > >
> > > > > > I'm interested in the latest fix that Andrew put in the js repo:
> > > > > > https://git-wip-us.apache.org/**repos/asf?p=incubator-cordova-**
> > > > > >
> js.git;a=commitdiff;h=**97a05cb0f672ee1bfb7e9e14a0dfd4**52d7763ba9<
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commitdiff;h=97a05cb0f672ee1bfb7e9e14a0dfd452d7763ba9
> > > > > >
> > > > > > https://issues.apache.org/**jira/browse/CB-1745<
> > > > > https://issues.apache.org/jira/browse/CB-1745>
> > > > > >
> > > > > > When I browse the Apache repos, I see that:
> > > > > > 1) this fix was committed to the js repo after the rc2 tag. Is
> this
> > > > > thread
> > > > > > going to include this fix inside the rc2 tag?
> > > > > > 2) the corresponding js artifact in the android repo needs to be
> > > > > refreshed
> > > > > > to pick up this fix, and I don't see that commit at all. Is
> someone
> > > > going
> > > > > > to do that? And then will the rc2 tag on this repo include this
> > > > refresh?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > -- Marcel Kinard
> > > > > >
> > > > > >
> > > > > > On 10/25/2012 4:03 PM, Andrew Grieve wrote:
> > > > > >
> > > > > >> Okay. I'll co-ordinate with Simon on the re-tagging. He's still
> > > > working
> > > > > >> through one of the bugs.
> > > > > >>
> > > > > >>
> > > > > >> On Thu, Oct 25, 2012 at 3:23 PM, Filip Maj 
> wrote:
> > > > > >>
> > > > > >>  You just need to delete the tag and re-add it. Then when you
> push
> > > > with
> > > > > >>> --tags it'll move the tag to the newer commit.
> > > > > >>>
> > > > > >>> And yeah retagging just android is fine.
> > > > > >>>
> > > > > >>> On 10/25/12 12:20 PM, "Andrew Grieve" 
> > > wrote:
> > > > > >>>
> > > > > >>>  What I think we w

Re: PhoneGap interface on Android vs. addJavaScriptInterface

Hey Laszlo,

You'll be happy to know that with our next release, we've implemented a new
Android bridge, which is even faster than using loadUrl! If you're
interested in the details, have a look at this bug:

https://issues.apache.org/jira/browse/CB-638

Andrew


On Fri, Oct 26, 2012 at 1:00 PM, Fazekas László wrote:

> Hi!
>
> About 1 month ago, I've developed a PhoneGap application to one of my
> clients. He dropped it back to me, because the UI was slow and laggy on
> a Vodafone SmartTab. After some debug, I've realized, the problem is the
> speed of the PhoneGap interface, and the XHR poll mechanism (I've found
> some info about it here:
> http://nullisnotanobject.com/phonegap-native-bridge). The final solution
> was creation of a new PhoneGap like interface through
> addJavascriptInterface and loadUrl. This new interface is working like a
> charm without lag. I think, the perfect solution would be an optional
> support of addJavascriptInterface/loadUrl way. If it is working on the
> device without bugs, PhoneGap could use this faster way automatically
> instead of the present solution, or developers could enable it
> optionally. For example, in my case, the application will be used only
> on Vodafone SmartTabs, where the standard addJavascriptInterface/loadUrl
> solution working fine and fast, so in this case I could enable it.
>
> Kind regards,
>   Laszlo
>

Re: 2.2.0rc2 Monday?

2012-10-26 Thread Gord Tanner

anyone have any objections of getting this fix into blackberry for 2.2?

https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139

also I fail at teh git so if there is no objections could someone retag
blackberry for me?

On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve wrote:

> Sounds good. I've now re-tagged the JS and Android.
>
>
> On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald <
> simon.macdon...@gmail.com
> > wrote:
>
> > I'm still seeing the bug but I don't think it should hold up the tagging
> of
> > 2.2.0rc2 at this point. I created a small sync Plugin for testing and it
> > runs fine in my mobile spec test case. Now the same plugin called in the
> > downstream app which uses the same Android library project for Cordova
> and
> > the same .js file returns the wrong value when I call the plugin. At this
> > point I'm not convinced it is a Cordova issue.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve 
> > wrote:
> >
> > > Joe - my thinking here is that it's fine to re-tag and re-tag until we
> > > actually produce an RC with everything tagged. rc2 is still in the
> > process
> > > of being tagged, and until the tagging is all done, it just causes more
> > > work to scratch it and have to re-tag all of the other repos. Once we
> > > create an rc2 archive though, no more adjusting.
> > >
> > > Marcel - yes, my intention is to retag the JS with the Android changes,
> > and
> > > to update the JS in android repo and then re-tag that as well. Simon
> was
> > > still seeing a bug with one of his projects though, even after the fix,
> > so
> > > I'd like to wait for his verification before continuing.
> > >
> > >
> > > On Thu, Oct 25, 2012 at 5:13 PM, Michael Brooks <
> > mich...@michaelbrooks.ca
> > > >wrote:
> > >
> > > > Sorry, just catching up on the conversations.
> > > >
> > > >
> > > > > Ey Mr. Brooks do you have a script or something that we can use to
> > > > > easily/quickly clone/create the behemoth "tag all the things"
> parent
> > > > issue
> > > > > with subtasks in JIRA? This seems like a worthwhile pursuit.
> > > >
> > > >
> > > > Just find go to the parent issue (e.g. Tag
> > > > 2.2.0rc1),
> > > > click "More Actions", and click "Clone." JIRA will do the rest by
> > > spamming
> > > > everyone.
> > > >
> > > > For the most part, I've worded each task in a generic manner, but you
> > may
> > > > need to edit the odd sub-tasks description if it mentions a version.
> > > >
> > > > Michael
> > > >
> > > > On Thu, Oct 25, 2012 at 2:08 PM, Marcel Kinard 
> > > wrote:
> > > >
> > > > > I'm interested in the latest fix that Andrew put in the js repo:
> > > > > https://git-wip-us.apache.org/**repos/asf?p=incubator-cordova-**
> > > > > js.git;a=commitdiff;h=**97a05cb0f672ee1bfb7e9e14a0dfd4**52d7763ba9<
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commitdiff;h=97a05cb0f672ee1bfb7e9e14a0dfd452d7763ba9
> > > > >
> > > > > https://issues.apache.org/**jira/browse/CB-1745<
> > > > https://issues.apache.org/jira/browse/CB-1745>
> > > > >
> > > > > When I browse the Apache repos, I see that:
> > > > > 1) this fix was committed to the js repo after the rc2 tag. Is this
> > > > thread
> > > > > going to include this fix inside the rc2 tag?
> > > > > 2) the corresponding js artifact in the android repo needs to be
> > > > refreshed
> > > > > to pick up this fix, and I don't see that commit at all. Is someone
> > > going
> > > > > to do that? And then will the rc2 tag on this repo include this
> > > refresh?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > -- Marcel Kinard
> > > > >
> > > > >
> > > > > On 10/25/2012 4:03 PM, Andrew Grieve wrote:
> > > > >
> > > > >> Okay. I'll co-ordinate with Simon on the re-tagging. He's still
> > > working
> > > > >> through one of the bugs.
> > > > >>
> > > > >>
> > > > >> On Thu, Oct 25, 2012 at 3:23 PM, Filip Maj  wrote:
> > > > >>
> > > > >>  You just need to delete the tag and re-add it. Then when you push
> > > with
> > > > >>> --tags it'll move the tag to the newer commit.
> > > > >>>
> > > > >>> And yeah retagging just android is fine.
> > > > >>>
> > > > >>> On 10/25/12 12:20 PM, "Andrew Grieve" 
> > wrote:
> > > > >>>
> > > > >>>  What I think we want to do is just update the existing 2.2.0rc2
> > tag
> > > to
> > > >  point to HEAD, unless we want to call rc2 a fail and move to
> rc3.
> > I
> > > >  think
> > > >  it'll be fine to re-tag though since only android code changed.
> > > > 
> > > >  I don't know the git command for it though. git tag --foce
> > 2.2.0rc2.
> > > > but
> > > >  then how to push it?
> > > > 
> > > > 
> > > >  On Thu, Oct 25, 2012 at 3:14 PM, Filip Maj 
> wrote:
> > > > 
> > > >   To retag JS, change the value of the VERSION file, then run a
> > build
> > >

[jira] [Created] (CB-1749) Switch BlackBerry 10 Battery to use navigator.webkitBattery

Gord created CB-1749:


 Summary: Switch BlackBerry 10 Battery to use 
navigator.webkitBattery
 Key: CB-1749
 URL: https://issues.apache.org/jira/browse/CB-1749
 Project: Apache Cordova
  Issue Type: Bug
  Components: BlackBerry, CordovaJS
Reporter: Gord
Assignee: Gord
 Fix For: 2.3.0


The current way we handle battery events in cordova.js for BlackBerry 10 is 
going to be obsoleted in favour of navigator.webkitBattery support already in 
the browser.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CB-1748) Building for BlackBerry 10 doesn't work on Windows


 [ 
https://issues.apache.org/jira/browse/CB-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gord updated CB-1748:
-

Fix Version/s: (was: 2.2.0)
   2.3.0

> Building for BlackBerry 10 doesn't work on Windows
> --
>
> Key: CB-1748
> URL: https://issues.apache.org/jira/browse/CB-1748
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 2.1.0
>Reporter: Gord
>Assignee: Gord
>Priority: Minor
> Fix For: 2.3.0
>
>
> Complains that it can't find bbwp.exe:
> https://twitter.com/Gerii92/status/261847756186996738

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ios] Evaluating JS during onAppWillResignActive

2012-10-26 Thread Michal Mocny

Local Notifications, especially on ios, are most useful when app is in
the background.  It would be handy to be able to schedule them during
the window of time allotted during onAppWillResignActive.

We even already have handlers for js document events 'resign' and
'pause' (this one is for a
onAppDidEnterBackground event).  (There are some issues with the
javascript here, seems the events aren't properly defined, will file
separately).

However, no matter how I try, I cannot get more then a trivial amount
of js to execute during the time window before app pauses -- far less
than the allowed 5 seconds.

According to the only (unreliable) source I've found on the subject,
its simply not possible to use the webview during
onAppWillResignActive:
http://stackoverflow.com/questions/4865742/iphone-webview-onbackground-event

Does anyone have a better answer here?

Thanks,
-Michal

[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple

2012-10-26 Thread Michal Mocny (JIRA)


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

Michal Mocny commented on CB-1561:
--

Sam, seems not officially yet, but close!  Either way you could also grab tip 
of tree to test, if you are already set up to do that.

Thanks.

> Using Storage API - rejected by Apple
> -
>
> Key: CB-1561
> URL: https://issues.apache.org/jira/browse/CB-1561
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
> Environment: - Cordova 2.0 on iOS
>Reporter: Clemens Wyss
>Assignee: Michal Mocny
>Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff
>
>
> our App uses the Sotrage-API to store data which is being loaded upon first 
> launch. 
> The app is rejected given the following reasoning:
> 'Your app does not follow the iOS Data Storage Guidelines, as required by the 
> App Store Review Guidelines.
> Please be sure to set the "Do not back up" attribute for all data which is 
> not generated or modified by the user. To check how much data your app is 
> storing:
> - Install and launch your app
> - Go to Settings > iCloud > Storage and Backup > Manage Storage
> - If necessary, select "Show all apps"
> - Check your app's storage
> The iOS Data Storage Guidelines indicate that only content that the user 
> creates using your app, (documents, new files, edits, etc.) may be stored in 
> the /Documents directory - and backed up to iCloud.
> Temporary files used by your app should only be stored in the /tmp directory. 
> Please remember to delete the files stored in this location when the user 
> exits the app.
> Data that can be recreated but must persist for proper functioning of your 
> app or because customers expect it to be available for offline use should be 
> appended with the "do not back up" attribute. For NSURL objects, add the 
> NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from 
> being backed up. For CFURLRef objects, use the corresponding 
> kCFURLIsExcludedFromBackupKey attribute.
> For more information, please see Technical Q&A 1719: How do I prevent files 
> from being backed up to iCloud and iTunes?.
> Please revise your app so that it adheres to the iOS Data Storage Guidelines.'
> Is there a possibility to set this flag for the WebSQL Database file(s)?
> At least for us this is a blocker ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple

2012-10-26 Thread Samuel Michelot (JIRA)


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

Samuel Michelot commented on CB-1561:
-

2.2 RC2 still not released? I can help to test...

> Using Storage API - rejected by Apple
> -
>
> Key: CB-1561
> URL: https://issues.apache.org/jira/browse/CB-1561
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
> Environment: - Cordova 2.0 on iOS
>Reporter: Clemens Wyss
>Assignee: Michal Mocny
>Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff
>
>
> our App uses the Sotrage-API to store data which is being loaded upon first 
> launch. 
> The app is rejected given the following reasoning:
> 'Your app does not follow the iOS Data Storage Guidelines, as required by the 
> App Store Review Guidelines.
> Please be sure to set the "Do not back up" attribute for all data which is 
> not generated or modified by the user. To check how much data your app is 
> storing:
> - Install and launch your app
> - Go to Settings > iCloud > Storage and Backup > Manage Storage
> - If necessary, select "Show all apps"
> - Check your app's storage
> The iOS Data Storage Guidelines indicate that only content that the user 
> creates using your app, (documents, new files, edits, etc.) may be stored in 
> the /Documents directory - and backed up to iCloud.
> Temporary files used by your app should only be stored in the /tmp directory. 
> Please remember to delete the files stored in this location when the user 
> exits the app.
> Data that can be recreated but must persist for proper functioning of your 
> app or because customers expect it to be available for offline use should be 
> appended with the "do not back up" attribute. For NSURL objects, add the 
> NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from 
> being backed up. For CFURLRef objects, use the corresponding 
> kCFURLIsExcludedFromBackupKey attribute.
> For more information, please see Technical Q&A 1719: How do I prevent files 
> from being backed up to iCloud and iTunes?.
> Please revise your app so that it adheres to the iOS Data Storage Guidelines.'
> Is there a possibility to set this flag for the WebSQL Database file(s)?
> At least for us this is a blocker ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1748) Building for BlackBerry 10 doesn't work on Windows


 [ 
https://issues.apache.org/jira/browse/CB-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gord resolved CB-1748.
--

Resolution: Fixed

fixed in:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139

Thanks to @Geril92

> Building for BlackBerry 10 doesn't work on Windows
> --
>
> Key: CB-1748
> URL: https://issues.apache.org/jira/browse/CB-1748
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 2.1.0
>Reporter: Gord
>Assignee: Gord
>Priority: Minor
> Fix For: 2.2.0
>
>
> Complains that it can't find bbwp.exe:
> https://twitter.com/Gerii92/status/261847756186996738

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1748) Building for BlackBerry 10 doesn't work on Windows

Gord created CB-1748:


 Summary: Building for BlackBerry 10 doesn't work on Windows
 Key: CB-1748
 URL: https://issues.apache.org/jira/browse/CB-1748
 Project: Apache Cordova
  Issue Type: Bug
  Components: BlackBerry
Affects Versions: 2.1.0
Reporter: Gord
Assignee: Gord
Priority: Minor
 Fix For: 2.2.0


Complains that it can't find bbwp.exe:

https://twitter.com/Gerii92/status/261847756186996738

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: 2.2.0rc2 Monday?