date:20121114

Remzi Cavdar created CB-1846:


 Summary: Offline event doesn't work
 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


The offline event doesn't work and I had said this before release, but you guys 
wanted to release PhoneGap 2.2.0 

This is my code:


document.addEventListener(deviceready, onDeviceReady, false);

function onDeviceReady() {
document.addEventListener(offline, function() {
alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
}, false);
}

/* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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] [Comment Edited] (CB-1846) Offline event doesn't work


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497105#comment-13497105
 ] 

Remzi Cavdar edited comment on CB-1846 at 11/14/12 1:57 PM:


It also doesn't work if I use the example code:


script type=text/javascript charset=utf-8

// Call onDeviceReady when Cordova is loaded.
//
// At this point, the document has loaded but cordova-2.2.0.js has not.
// When Cordova is loaded and talking with the native device,
// it will call the event `deviceready`.
//
function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
}

// Cordova is loaded and it is now safe to make calls Cordova methods
//
function onDeviceReady() {
document.addEventListener(offline, onOffline, false);
}

// Handle the offline event
//
function onOffline() {
 alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
}

/script


http://docs.phonegap.com/en/2.2.0/cordova_events_events.md.html#offline

  was (Author: remzicavdar):
It also doesn't work if I use the example code:


script type=text/javascript charset=utf-8

// Call onDeviceReady when Cordova is loaded.
//
// At this point, the document has loaded but cordova-2.2.0.js has not.
// When Cordova is loaded and talking with the native device,
// it will call the event `deviceready`.
//
function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
}

// Cordova is loaded and it is now safe to make calls Cordova methods
//
function onDeviceReady() {
document.addEventListener(offline, onOffline, false);
}

// Handle the offline event
//
function onOffline() {
}

/script


http://docs.phonegap.com/en/2.2.0/cordova_events_events.md.html#offline
  
 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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] [Comment Edited] (CB-1846) Offline event doesn't work


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497105#comment-13497105
 ] 

Remzi Cavdar edited comment on CB-1846 at 11/14/12 1:58 PM:


It also doesn't work if I use the example code:


script type=text/javascript charset=utf-8

// Call onDeviceReady when Cordova is loaded.
//
// At this point, the document has loaded but cordova-2.2.0.js has not.
// When Cordova is loaded and talking with the native device,
// it will call the event `deviceready`.
//
function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
}

// Cordova is loaded and it is now safe to make calls Cordova methods
//
function onDeviceReady() {
document.addEventListener(offline, onOffline, false);
}

// Handle the offline event
//
function onOffline() {
 
  alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
}

/script


http://docs.phonegap.com/en/2.2.0/cordova_events_events.md.html#offline

  was (Author: remzicavdar):
It also doesn't work if I use the example code:


script type=text/javascript charset=utf-8

// Call onDeviceReady when Cordova is loaded.
//
// At this point, the document has loaded but cordova-2.2.0.js has not.
// When Cordova is loaded and talking with the native device,
// it will call the event `deviceready`.
//
function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
}

// Cordova is loaded and it is now safe to make calls Cordova methods
//
function onDeviceReady() {
document.addEventListener(offline, onOffline, false);
}

// Handle the offline event
//
function onOffline() {
 alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
}

/script


http://docs.phonegap.com/en/2.2.0/cordova_events_events.md.html#offline
  
 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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-1846) Offline event doesn't work

2012-11-14 Thread Simon MacDonald (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497128#comment-13497128
 ] 

Simon MacDonald commented on CB-1846:
-

Quick question, is this on the first page of your app or on a secondary page? 
The reason I ask is I just fixed a bug similar to this for all subsequent pages 
in the app.

 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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: online/offline Events

Well that's not the way it works on Android. From the Java side we return
constants like none, 3g, wifi, etc. so the comparison will work
properly. As well the constant Connection.NONE evaluates to none so even
if you were using the constant for comparison purposes it should still work.

Simon Mac Donald
http://hi.im/simonmacdonald


On Wed, Nov 14, 2012 at 6:33 AM, Leutwyler, Markus
markus.leutwy...@hp.comwrote:

 In lib/common/plugin/network.js on Line 49

 if (info === none) {

 Am I wrong or will this statement never be true since the plugins return
 the connection as Connection.NONE?

 What I'm seeing is that the event online is fired as Connection.NONE is
 passed in

 Markus

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Dienstag, 13. November 2012 18:41
 To: dev
 Subject: Re: online/offline Events

 The spec says to fire an online event whenever the connection type
 changes, and to fire an offline event only when you lose your connection.
 It's not the most obvious, but probably your multiple event firing is
 working as intended.

 To answer your second question, I think what you're looking for is
 navigator.onLine. It's derived from the connection type here:

 https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blob;f=lib/common/plugin/network.js;h=63736a954762b17d4383239a8afa46a81ce88a3a;hb=HEAD#l31



 On Tue, Nov 13, 2012 at 9:00 AM, Leutwyler, Markus
 markus.leutwy...@hp.comwrote:

  I'm able to successfully setup  a webOS specific service call in the
  initialize() function in platform.js ... this will keep track of any
  connection changes but fires multiple events in case Wifi is turned on
  (and not connected to an AP) and then again if connected with an AP. I
  convert those events to offline/online document events (via
  cordova.fireDocumentEvent). Is there a way to add a global
  online/offline status/variable somewhere and only fire document events
  if there's an actual change from offline to online?
 
  Markus
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
  Andrew Grieve
  Sent: Mittwoch, 7. November 2012 16:27
  To: dev
  Subject: Re: online/offline Events
 
  Here's the Android impl:
 
  https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.gi
  t;a=blob;f=framework/src/org/apache/cordova/NetworkManager.java;h=5d87
  91809227877d604c98cf029c26242d9642b8;hb=HEAD
 
  The JS performs a Connection.getConnectionInfo(), and then the native
  plugin returns the connection status but sets keepCallback to true.
  Then, whenever the connection type changes, it sends another plugin
  result and always sets keepCallback to true.
 
 
  On Wed, Nov 7, 2012 at 9:57 AM, Leutwyler, Markus
  markus.leutwy...@hp.comwrote:
 
   I saw that ... but how is that handled by the platform specific
 plugins?
  
   Markus
  
   -Original Message-
   From: Simon MacDonald [mailto:simon.macdon...@gmail.com]
   Sent: Mittwoch, 7. November 2012 15:56
   To: dev@cordova.apache.org
   Subject: Re: online/offline Events
  
   lolz I didn't read what list this was on. The src for network.js is at:
  
  
   https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a
   =b
   lob;f=lib/common/plugin/network.js;h=adaba5ae8b6ec825986712d8b99e660
   10
   5e56ae9;hb=HEAD
  
   The way we have it setup is the native side sends the JS side an
   update whenever the network connection changes. If the type == 'none'
   then we fire an offline event. Otherwise you fire the online event.
  
   Simon Mac Donald
   http://hi.im/simonmacdonald
  
  
   On Wed, Nov 7, 2012 at 9:47 AM, Leutwyler, Markus
   markus.leutwy...@hp.comwrote:
  
I was actually looking for a code example (in cordova-js) of a
platform that sends out those events (because I'm investigating
how to add support for those to webOS)
   
Markus
   
-Original Message-
From: Simon MacDonald [mailto:simon.macdon...@gmail.com]
Sent: Mittwoch, 7. November 2012 15:39
To: dev@cordova.apache.org
Subject: Re: online/offline Events
   
http://docs.phonegap.com/en/2.2.0/cordova_events_events.md.html#on
li
ne
http://docs.phonegap.com/en/2.2.0/cordova_events_events.md.html#of
fl
in
e
   
Simon Mac Donald
http://hi.im/simonmacdonald
   
   
On Wed, Nov 7, 2012 at 9:36 AM, Leutwyler, Markus
markus.leutwy...@hp.comwrote:
   
 Is there a platform that sends out online/offline event to the
 document when the connection status changes? I didn't find any
 examples

 Thanks

 Markus

[jira] [Commented] (CB-1846) Offline event doesn't work


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497134#comment-13497134
 ] 

Remzi Cavdar commented on CB-1846:
--

Both

 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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-1846) Offline event doesn't work


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497135#comment-13497135
 ] 

Remzi Cavdar commented on CB-1846:
--

I use this for every html page of my app :P

 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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-1846) Offline event doesn't work


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497137#comment-13497137
 ] 

Remzi Cavdar commented on CB-1846:
--

But this was my reason to not release an unstable PhoneGap to devlopers 

 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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: [Android] Can everyone run the tests?

2012-11-14 Thread Marlin Mixon

This isn't totally related but I can describe my experience creating a
new project in Eclipse for Android 2.2 FroYo using Cordova 2.2 (I'm in
Linux, Ubuntu 10.04):

I got it to work but I had to be a little creative.  It works pretty
much out of the box for making 4.0 Android, but the
AndroidManifest.xml file was a problem for 2.2.  I solved it by
borrowing a manifest from Cordova 2.0 and after that it compiled and
ran. A simple solution, I think, would be to use a flag or argument on
the create script and setting up two or more more manifests in the
templates directory.

Cheers all.  (Love the script idea, makes setting up a new project a
lot quicker)

Marlin


On Tue, Nov 13, 2012 at 12:38 PM, Joe Bowser bows...@gmail.com wrote:
 BUMP! Can everyone run these tests?  I need to know about failures ASAP

 On Mon, Nov 5, 2012 at 9:44 AM, Joe Bowser bows...@gmail.com wrote:
 Sorry, wrong thread.  Obviously.

 The command line version of the unit tests is on the Wiki.


 On Mon, Nov 5, 2012 at 9:43 AM, Joe Bowser bows...@gmail.com wrote:

 I did send an e-mail about the cleaning of the tests with the wiki
 article.  Did everyone get it?


 On Mon, Nov 5, 2012 at 9:21 AM, Andrew Grieve agri...@chromium.org
 wrote:

 Yes, thanks Joe for pushing on this. Testing will only make things
 better!

 Do you think it'd be feasible to create a script that would launch the
 tests? Eclipse is great when they fail, but to ensure they pass, command
 line is often nicer. The instructions on the wiki seem like they may be
 out
 of date? They reference phonegap, and they don't say what cordova target
 to
 build.


 On Fri, Nov 2, 2012 at 9:25 PM, Joe Bowser bows...@gmail.com wrote:

  If we still have JAR issues, that should be a blocker for the release.
   Having these tests should be required now, since we have too many Java
  bits that we can't break. I removed the old Selenium JAR a while ago.
 
  I would love it if we could get Selenium to work with CordovaWebView so
  that we could click on HTML elements, but we should be able to automate
  the
  Back Button and Menu Button bindings, as well as random key bindings.
  That
  being said, we should be able to execute Javascript to do what we need
  instead of testing touch and click events, which in theory should have
  been
  tested as part of Android's CTS.  (No idea if this ever happens).
 
 
  On Fri, Nov 2, 2012 at 5:58 PM, Simon MacDonald
  simon.macdon...@gmail.comwrote:
 
   That's great Joe. I was under the impression that the Android repo
   tests
   were still dependent on a jar we didn't have access to. I'll make
   sure
   running the tests is part of my regular process and gasp I will
   even
   write a few.
  
   Simon Mac Donald
   http://hi.im/simonmacdonald
  
  
   On Fri, Nov 2, 2012 at 4:38 PM, Joe Bowser bows...@gmail.com wrote:
  
Hey
   
After the last scare with CordovaWebView, I want to know if
everyone
  who
commits on Android can run the tests that are currently committed
with
Android? You have to be able to do both things with the tests in
  Eclipse:
   
1. Run the test as an Android Application
2. Run the Android JUnit Tests
   
There is a command-line method to do this, but honestly if you're
  finding
failures here, you'll probably need Eclipse anyway to debug the
Java
   code.
 If you're super hardcore, I believe that this command is still in
the
   wiki
here:
   
http://wiki.apache.org/cordova/RunningTests
   
Also, are other platforms doing testing outside of mobile-spec
Jasmine
tests? What impact would this have on CI work?  I'm pretty sure
that
  the
Android tests should be relatively simple.
   
Joe

[jira] [Created] (CB-1847) weinre: client c-2: weinre: invocation exception on WeinreClientEventsImpl.connectionCreated(): TypeError: Cannot call method 'indexOf' of undefined

2012-11-14 Thread Emanuele Ricci (JIRA)

Emanuele Ricci created CB-1847:
--

 Summary: weinre: client c-2: weinre: invocation exception on 
WeinreClientEventsImpl.connectionCreated(): TypeError: Cannot call method 
'indexOf' of undefined
 Key: CB-1847
 URL: https://issues.apache.org/jira/browse/CB-1847
 Project: Apache Cordova
  Issue Type: Bug
  Components: weinre
Affects Versions: 2.2.0, 2.1.0, 2.0.0
 Environment: tried both on linux/osx.
Phone to test webview: Samsung Galaxy Nexus with Android 4.1.2
Reporter: Emanuele Ricci
Assignee: Patrick Mueller


This is the error we get when we try to click on the link of the client on our 
admin dashboard: 2012-11-14T14:37:38.568Z weinre: client c-2: weinre: 
invocation exception on WeinreClientEventsImpl.connectionCreated(): TypeError: 
Cannot call method 'indexOf' of undefined


We tried this: http://debug.phonegap.com/client/#mxmtest and it's working fine 
(but slow because on the internet).

Can you fix this? 
We used weinre from npm install

--
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-1845) WebSettings.setNavDump() has been removed from API 17


[ 
https://issues.apache.org/jira/browse/CB-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497215#comment-13497215
 ] 

Joe Bowser commented on CB-1845:


OK, how many people out there have an HTC Incredible, HTC Desire HD or some 
other HTC device that is on Android 2.3.x that has HTC Sense? I'm guessing it's 
still quite a lot based on the old pie chart of Android versions.  Given that 
the WebSettings.setNavDump() setting is literally there just for these people 
so they can have a hope in hell of debugging it, I'd lean towards reflection.

 WebSettings.setNavDump() has been removed from API 17
 -

 Key: CB-1845
 URL: https://issues.apache.org/jira/browse/CB-1845
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.3.0
Reporter: Simon MacDonald
Assignee: Joe Bowser

 We've known that WebSettings.setNavDump() has been deprecated for awhile now. 
 In API level 17 (Android 4.2) the code has been removed so you cannot compile 
 Cordova with API level 17. The class CordovaWebView will throw an error due 
 to out call to setNavDump.
 Not sure if we want to just out and out remove it, my preference, or use some 
 funky reflection to see if the method is available then call it.

--
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-1843) Echo plugin doesn't work in iOS

2012-11-14 Thread Aaron Moman (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497220#comment-13497220
 ] 

Aaron Moman commented on CB-1843:
-

The same broken behavior.  Here's a link to the 
[project|http://arkmobile.fusionmedia.com/Apps/app-aaron/c22-echo-plugin.zip]. 
I included all the build files in case there's something in the way it's 
getting built that's different/wrong.  FYI - I see the same behavior with both 
the cordova debug/emulate scripts and Xcode.

Also, I just tried this with 4.3, 5.0 and 5.1 in the simulator.  All versions 
exhibit the same bug.  I do see the same behavior on device (iPad 2, iPhone 4) 
as well, both of those are iOS 6.

Thanks,
Aaron

 Echo plugin doesn't work in iOS
 ---

 Key: CB-1843
 URL: https://issues.apache.org/jira/browse/CB-1843
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.2.0
 Environment: iPad2, iOS Simulator, iOS 6, XCode 4.5.2
Reporter: Aaron Moman
Assignee: Andrew Grieve

 I'm using the base application for iOS created with the create script.  That 
 works correctly.  I add the Echo plugin example Objective-C code and 
 everything compiles.  Then I add the JS to call it and that's when things get 
 weird.
 In index.js, after the var app = { ... }; statement I add:
 window.echo = function(str, callback) {
 cordova.exec(callback, function(err) {
 callback('Nothing to echo.');
 }, Echo, echo, [str]);
 };
 Then in onDeviceReady I add the following after the receivedEvent call:
 window.echo(echome, function(echoValue) { alert(echoValue == echome); 
 });
 I run the app and I get the green glowing Device is ready message.  So 
 we're getting into onDeviceReady successfully.  But the true alert never 
 pops up.
 Until I double-click on the home button.  Then when the running apps show at 
 the bottom of the screen, then the alert pops up.  I tap back into the app 
 and I can click to dismiss the alert.
 What's going on here?  It seems like the example plug-in should work a little 
 better than this.
 The reason I'm doing this at all is that I'm seeing similar behavior in my 
 app that I'm currently failing to upgrade from 2.1 to 2.2.
 Worse: If I single-click the home button and then go back to the app, I get 
 the alert pop-up, but after I click on it the screen goes black.
 Any help would be greatly appreciated.
 Thanks,
 Aaron

--
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: [Android] Feedback requested on our camera

You need to check out the branch, and make sure that your example
project has the activity declared:

 activity android:name=org.apache.cordova.camera.CameraActivity
  android:label=@string/app_name
  android:screenOrientation=landscape
/activity

Sadly, there's no way around this step, which is why I tried fixing
the state issue first. :\

On Wed, Nov 14, 2012 at 8:12 AM, Andrew Grieve agri...@chromium.org wrote:
 Could you re-post how to try it? I checked it out and ran mobile spec but
 get an ActivityNotFoundException when I try to take a picture.


 On Tue, Nov 13, 2012 at 6:31 PM, Joe Bowser bows...@gmail.com wrote:

 Hey

 I'm going to resurrect this thread. What do people think of our
 pre-built camera so far? I still have updated on this branch here:

 https://github.com/infil00p/cordova-android/tree/camera

 It'd be good to get more feedback before continuing down this road.
 The downside so far is having to pass around assets.  I wish there was
 a way around this.  Also, feedback on the UI elements would also help.

 There's still work to be done, but should we hav this as a built-in
 option for 2.3.0, or should we delay to 2.4.0?  It'd be good to get
 feedback on this now before we continue to move with this.

 Joe

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode


[ 
https://issues.apache.org/jira/browse/CB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497306#comment-13497306
 ] 

Shazron Abdullah commented on CB-1404:
--

Possible issue according to this GG post: 
https://groups.google.com/d/topic/phonegap/TEJHy1942t8/discussion

 EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
 ---

 Key: CB-1404
 URL: https://issues.apache.org/jira/browse/CB-1404
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0
 Environment: iPad 2, iOS 5.1.1
Reporter: Tom Clarkson
Assignee: Andrew Grieve
 Fix For: 2.2.0


 When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
 WebCore::DocumentThreadableLoader::cancel.
 This appears to be some sort of timing issue, as it does not happen on every 
 call - I am seeing it in an autosave function which makes lots of calls to 
 PGSQLitePlugin. 
 The error did not appear before upgrading to 2.1, and setting the bridge mode 
 to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
 functionality).
 Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
 removing the payload actually does anything different or just makes it fast 
 enough that the timing condition does not come up in normal app usage.
   

--
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

test

2012-11-14 Thread Matthias Wessendorf

... please ignore...

-M

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

[jira] [Commented] (CB-1845) WebSettings.setNavDump() has been removed from API 17


[ 
https://issues.apache.org/jira/browse/CB-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497334#comment-13497334
 ] 

Joe Bowser commented on CB-1845:


OK, I've added the reflection code, but I need to get access to the test device 
that has this issue (my old HTC Desire HD) to test this.  I'll close this once 
I get this tested again.

 WebSettings.setNavDump() has been removed from API 17
 -

 Key: CB-1845
 URL: https://issues.apache.org/jira/browse/CB-1845
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.3.0
Reporter: Simon MacDonald
Assignee: Joe Bowser

 We've known that WebSettings.setNavDump() has been deprecated for awhile now. 
 In API level 17 (Android 4.2) the code has been removed so you cannot compile 
 Cordova with API level 17. The class CordovaWebView will throw an error due 
 to out call to setNavDump.
 Not sure if we want to just out and out remove it, my preference, or use some 
 funky reflection to see if the method is available then call it.

--
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-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode


[ 
https://issues.apache.org/jira/browse/CB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497348#comment-13497348
 ] 

Andrew Grieve commented on CB-1404:
---

Hmm, yeah, not sure what's going on. If it's reproducible, might be worth 
putting a try/catch in there to see if a JS exception is happening.

Of note:
-XHR_WITH_PAYLOAD is not used in 2.2 by default. It's always NO_PAYLOAD.
-This CL makes it even less likely to attempt an XHR when there is already one 
in progress: 
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=blobdiff;f=lib/ios/exec.js;h=7ce52d94da0e834104e0ee5cc1ceb70e8cbe8104;hp=c6b8edd7f9518c0a1ca726db2216f64a45a0e0a7;hb=86411246aba4292734b9bb46dc9128e28391e424;hpb=c3517e7703ab9a1335db8a3d0974b045ae3107e5

 EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
 ---

 Key: CB-1404
 URL: https://issues.apache.org/jira/browse/CB-1404
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0
 Environment: iPad 2, iOS 5.1.1
Reporter: Tom Clarkson
Assignee: Andrew Grieve
 Fix For: 2.2.0


 When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
 WebCore::DocumentThreadableLoader::cancel.
 This appears to be some sort of timing issue, as it does not happen on every 
 call - I am seeing it in an autosave function which makes lots of calls to 
 PGSQLitePlugin. 
 The error did not appear before upgrading to 2.1, and setting the bridge mode 
 to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
 functionality).
 Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
 removing the payload actually does anything different or just makes it fast 
 enough that the timing condition does not come up in normal app usage.
   

--
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: iOS' device API

Resurrecting this one.

BlackBerry has the same issue sorta.

I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx. When I
ask for device.version, I get BlackBerry Playbook OS for both.

Device.name also returns weird stuff for the play books, seem like
arbitrary numbers: 100669958.

Also, device.platform returns playbook. Shouldn't this be BlackBerry ?

/cc anyone from RIM

On 11/12/12 7:27 PM, Brian LeRoux b...@brian.io wrote:

thanks shaz


On Tue, Nov 13, 2012 at 6:39 AM, Shazron shaz...@gmail.com wrote:

 Added:

 http://issues.cordova.io/1836
 http://issues.cordova.io/1837
 http://issues.cordova.io/1838
 http://issues.cordova.io/1839
 http://issues.cordova.io/1840



 On Mon, Nov 12, 2012 at 11:14 AM, Shazron shaz...@gmail.com wrote:

  Adding jira tasks as per Brian's last comment.
 
 
  On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
 
  +1 sounds like a plan
 
 
  On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj f...@adobe.com wrote:
 
  +1
 
  On 11/8/12 4:01 AM, Brian LeRoux b...@brian.io wrote:
 
  I think would it make sense to:
  
  1. align apis as orig msg from fil suggests
  2. drop in deprecation notice for sync usage and add to deprec page
  3. add async equiv and get it out of startup path as andrew
suggests
  
  
  
  
  On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj f...@adobe.com wrote:
  
   Although I think we're close to being able to author
cross-platform
  apps
   sans UA detection , I think people still have valid use cases to
use
  it.
  
   On 11/7/12 6:18 PM, Andrew Grieve agri...@chromium.org wrote:
  
   I like the idea of at least removing this from the start-up
path.
 If
  users
   want to know about the device, they could always call exec()
  themselves.
   
   
   On Wed, Nov 7, 2012 at 4:57 PM, Shazron shaz...@gmail.com
wrote:
   
Also, if we remove the device API like Brian suggested, it
would
 be
   good in
the sense that we won't have to call the CDVDevice plugin to
  populate
   some
js variables before deviceready can fire -- eliminating a
  dependency.
   
   
On Wed, Nov 7, 2012 at 11:00 AM, Shazron shaz...@gmail.com
  wrote:
   
 Agree with Fil to make it consistent - in essence this is an
 iOS
  bug
   :)

 Brian, there is one case I can think of -- detecting the
iPad
  mini's
 features using js - Max Firt investigated trying to do it

   
   
  
  
 
 
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
   tthe only kludgy way right now using PG would be
device.platform
 to
 detect iPad2,5 and iPad2,6. I suppose ppl would need to
detect
  this to
 enlarge certain UI elements for the mini (since the physical
 area
   will be
 smaller than a reg sized iPad)


 On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj f...@adobe.com
  wrote:

 CI implementation is what I am gunning for here (and can
  actually
  use
it).

 I don't like it either but reality is for people building
   cross-platform
 apps at some point you have to do:

 if (device.platform == 'android') // do some stuff

 For example, knowing when to attach to a back button vs
  rendering
   some
ui
 to handle that.

 IMO we should set up deprecation for name and move to
 model
  as
   it's
 clearer (and probably was the reason why iOS went for
device's
  custom
name
 in the first place - semantic confusion :P )

 On 11/7/12 7:35 AM, Brian LeRoux b...@brian.io wrote:

 This may get some rotton tomatoes thrown at me but I
would be
  in
   favor
of
 axing these apis altogether. I think they are more
dangerous
  than
useful
 /
 developers should favor browser feature detection for
their
 UI
  work.
 
 There is no programmatic reason to want these properties
  otherwise
that I
 can think of?
 
 (But agree at least should be consistent as Fil suggests.)
 
 
 On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj f...@adobe.com
  wrote:
 
  Currently if you ask for device.platform you will get
 several
different
  responses on iOS. You'll get iPhone, iPad, iPod Touch,
etc.
  This
seems
  backwards. IMO all of these should return 'iOS'.
 
  Related, device.name returns the custom device name as
the
  user
 defines
 it
  in iTunes. IMO it should return the model name, I.e.
What
 device.platform
  returns now.
 
  This would line it up with our docs + other platforms.

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-14 Thread Greg (JIRA)

[
https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497358#comment-13497358
]

Greg commented on CB-1185:
--

@Joe - This is WITHOUT a USB cable. If you have this plugged in, it won't
replicated. Just by it's self and on Wifi - this works. Stock 4.1.2.

Thanks,
Greg

When Application is placed in background and resumed, the UI is frozen
--

Key: CB-1185
URL: https://issues.apache.org/jira/browse/CB-1185
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.0.0
Environment: Jelly Bean 4.1, ICS 4.0.x
Reporter: Greg
Assignee: Filip Maj
Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip

When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up
after you set the app to the background or turn of the screen. After around
3-7 seconds, the application unfreezes and pretty much causes a panic and
usually crashes. No error reports have been submitted.
Here is how you re-produce the issue:
1. Download Untappd -
V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app)
2. After logging in stay on the Friends tab
3. Turn the the screen off and wait about 3-7 minutes
4. Turn the screen back on, and the interface should be frozen.
Another possible path to re-producing the issue:
1. Download Untappd -
V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app)
2. After logging in stay on the Friends tab
3. Go back to the home screen then use other apps for about 3-7 minutes.
4. Go back into Untappd, and the interface should be frozen.
When the app is frozen, native menu buttons will not nor any options in the
UI.
Would love to see if anyone can replicate this. I've tested this on Jelly
Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem
majority on ICS (4.0.x)
Thanks,
Greg

--
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: iOS' device API

Thx duder

On 11/14/12 11:20 AM, Gord Tanner gtan...@gmail.com wrote:

+1 that this is suspect.

I know it just returns what webworks is telling us, we probably need to
read the userAgent or go to native.

Assign the jira to me and I can get this cleaned up for this version.

Sent from my iPhone

On 2012-11-14, at 2:14 PM, Filip Maj f...@adobe.com wrote:

 Resurrecting this one.
 
 BlackBerry has the same issue sorta.
 
 I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
When I
 ask for device.version, I get BlackBerry Playbook OS for both.
 
 Device.name also returns weird stuff for the play books, seem like
 arbitrary numbers: 100669958.
 
 Also, device.platform returns playbook. Shouldn't this be
BlackBerry ?
 
 /cc anyone from RIM
 
 On 11/12/12 7:27 PM, Brian LeRoux b...@brian.io wrote:
 
 thanks shaz
 
 
 On Tue, Nov 13, 2012 at 6:39 AM, Shazron shaz...@gmail.com wrote:
 
 Added:
 
 http://issues.cordova.io/1836
 http://issues.cordova.io/1837
 http://issues.cordova.io/1838
 http://issues.cordova.io/1839
 http://issues.cordova.io/1840
 
 
 
 On Mon, Nov 12, 2012 at 11:14 AM, Shazron shaz...@gmail.com wrote:
 
 Adding jira tasks as per Brian's last comment.
 
 
 On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
 
 +1 sounds like a plan
 
 
 On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj f...@adobe.com wrote:
 
 +1
 
 On 11/8/12 4:01 AM, Brian LeRoux b...@brian.io wrote:
 
 I think would it make sense to:
 
 1. align apis as orig msg from fil suggests
 2. drop in deprecation notice for sync usage and add to deprec
page
 3. add async equiv and get it out of startup path as andrew
 suggests
 
 
 
 
 On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj f...@adobe.com wrote:
 
 Although I think we're close to being able to author
 cross-platform
 apps
 sans UA detection , I think people still have valid use cases to
 use
 it.
 
 On 11/7/12 6:18 PM, Andrew Grieve agri...@chromium.org wrote:
 
 I like the idea of at least removing this from the start-up
 path.
 If
 users
 want to know about the device, they could always call exec()
 themselves.
 
 
 On Wed, Nov 7, 2012 at 4:57 PM, Shazron shaz...@gmail.com
 wrote:
 
 Also, if we remove the device API like Brian suggested, it
 would
 be
 good in
 the sense that we won't have to call the CDVDevice plugin to
 populate
 some
 js variables before deviceready can fire -- eliminating a
 dependency.
 
 
 On Wed, Nov 7, 2012 at 11:00 AM, Shazron shaz...@gmail.com
 wrote:
 
 Agree with Fil to make it consistent - in essence this is an
 iOS
 bug
 :)
 
 Brian, there is one case I can think of -- detecting the
 iPad
 mini's
 features using js - Max Firt investigated trying to do it
 
 
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
bu
 tthe only kludgy way right now using PG would be
 device.platform
 to
 detect iPad2,5 and iPad2,6. I suppose ppl would need to
 detect
 this to
 enlarge certain UI elements for the mini (since the physical
 area
 will be
 smaller than a reg sized iPad)
 
 
 On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj f...@adobe.com
 wrote:
 
 CI implementation is what I am gunning for here (and can
 actually
 use
 it).
 
 I don't like it either but reality is for people building
 cross-platform
 apps at some point you have to do:
 
 if (device.platform == 'android') // do some stuff
 
 For example, knowing when to attach to a back button vs
 rendering
 some
 ui
 to handle that.
 
 IMO we should set up deprecation for name and move to
 model
 as
 it's
 clearer (and probably was the reason why iOS went for
 device's
 custom
 name
 in the first place - semantic confusion :P )
 
 On 11/7/12 7:35 AM, Brian LeRoux b...@brian.io wrote:
 
 This may get some rotton tomatoes thrown at me but I
 would be
 in
 favor
 of
 axing these apis altogether. I think they are more
 dangerous
 than
 useful
 /
 developers should favor browser feature detection for
 their
 UI
 work.
 
 There is no programmatic reason to want these properties
 otherwise
 that I
 can think of?
 
 (But agree at least should be consistent as Fil suggests.)
 
 
 On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj f...@adobe.com
 wrote:
 
 Currently if you ask for device.platform you will get
 several
 different
 responses on iOS. You'll get iPhone, iPad, iPod Touch,
 etc.
 This
 seems
 backwards. IMO all of these should return 'iOS'.
 
 Related, device.name returns the custom device name as
 the
 user
 defines
 it
 in iTunes. IMO it should return the model name, I.e.
 What
 device.platform
 returns now.
 
 This would line it up with our docs + other platforms.

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[
https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497368#comment-13497368
]

Joe Bowser commented on CB-1185:

No, I'm still not able to reproduce this issue. I'll try on another Galaxy
Nexus and see if it's just my device.

When Application is placed in background and resumed, the UI is frozen
--

Re: iOS' device API

2012-11-14 Thread Shazron

I have somewhat similar concern for iOS:
https://issues.apache.org/jira/browse/CB-1837

Wonder whether we should output the model number instead eg iPad2,5
This might solve the comical procedure to detect an iPad Mini (at least for
Cordova):
http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5


On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj f...@adobe.com wrote:

 Resurrecting this one.

 BlackBerry has the same issue sorta.

 I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx. When I
 ask for device.version, I get BlackBerry Playbook OS for both.

 Device.name also returns weird stuff for the play books, seem like
 arbitrary numbers: 100669958.

 Also, device.platform returns playbook. Shouldn't this be BlackBerry ?

 /cc anyone from RIM

 On 11/12/12 7:27 PM, Brian LeRoux b...@brian.io wrote:

 thanks shaz
 
 
 On Tue, Nov 13, 2012 at 6:39 AM, Shazron shaz...@gmail.com wrote:
 
  Added:
 
  http://issues.cordova.io/1836
  http://issues.cordova.io/1837
  http://issues.cordova.io/1838
  http://issues.cordova.io/1839
  http://issues.cordova.io/1840
 
 
 
  On Mon, Nov 12, 2012 at 11:14 AM, Shazron shaz...@gmail.com wrote:
 
   Adding jira tasks as per Brian's last comment.
  
  
   On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
  
   +1 sounds like a plan
  
  
   On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj f...@adobe.com wrote:
  
   +1
  
   On 11/8/12 4:01 AM, Brian LeRoux b...@brian.io wrote:
  
   I think would it make sense to:
   
   1. align apis as orig msg from fil suggests
   2. drop in deprecation notice for sync usage and add to deprec page
   3. add async equiv and get it out of startup path as andrew
 suggests
   
   
   
   
   On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj f...@adobe.com wrote:
   
Although I think we're close to being able to author
 cross-platform
   apps
sans UA detection , I think people still have valid use cases to
 use
   it.
   
On 11/7/12 6:18 PM, Andrew Grieve agri...@chromium.org
 wrote:
   
I like the idea of at least removing this from the start-up
 path.
  If
   users
want to know about the device, they could always call exec()
   themselves.


On Wed, Nov 7, 2012 at 4:57 PM, Shazron shaz...@gmail.com
 wrote:

 Also, if we remove the device API like Brian suggested, it
 would
  be
good in
 the sense that we won't have to call the CDVDevice plugin to
   populate
some
 js variables before deviceready can fire -- eliminating a
   dependency.


 On Wed, Nov 7, 2012 at 11:00 AM, Shazron shaz...@gmail.com
   wrote:

  Agree with Fil to make it consistent - in essence this is an
  iOS
   bug
:)
 
  Brian, there is one case I can think of -- detecting the
 iPad
   mini's
  features using js - Max Firt investigated trying to do it
 


   
   
  
 
 
 http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
tthe only kludgy way right now using PG would be
 device.platform
  to
  detect iPad2,5 and iPad2,6. I suppose ppl would need to
 detect
   this to
  enlarge certain UI elements for the mini (since the physical
  area
will be
  smaller than a reg sized iPad)
 
 
  On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj f...@adobe.com
   wrote:
 
  CI implementation is what I am gunning for here (and can
   actually
   use
 it).
 
  I don't like it either but reality is for people building
cross-platform
  apps at some point you have to do:
 
  if (device.platform == 'android') // do some stuff
 
  For example, knowing when to attach to a back button vs
   rendering
some
 ui
  to handle that.
 
  IMO we should set up deprecation for name and move to
  model
   as
it's
  clearer (and probably was the reason why iOS went for
 device's
   custom
 name
  in the first place - semantic confusion :P )
 
  On 11/7/12 7:35 AM, Brian LeRoux b...@brian.io wrote:
 
  This may get some rotton tomatoes thrown at me but I
 would be
   in
favor
 of
  axing these apis altogether. I think they are more
 dangerous
   than
 useful
  /
  developers should favor browser feature detection for
 their
  UI
   work.
  
  There is no programmatic reason to want these properties
   otherwise
 that I
  can think of?
  
  (But agree at least should be consistent as Fil suggests.)
  
  
  On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj f...@adobe.com
   wrote:
  
   Currently if you ask for device.platform you will get
  several
 different
   responses on iOS. You'll get iPhone, iPad, iPod Touch,
 etc.
   This
 seems
   backwards. IMO all of these should return 'iOS'.
  
   Related, device.name returns the custom device name as
 the
   user
  defines
  it
   in iTunes. IMO it should return the model name, I.e.
 What

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-14 Thread Greg (JIRA)

[
https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497372#comment-13497372
]

Greg commented on CB-1185:
--

@Joe Did you try a fresh-install and reboot - just to make sure? That's what I
did, but figured it was not needed.

When Application is placed in background and resumed, the UI is frozen
--

[jira] [Created] (CB-1849) Remove iOS 4/5 conditional code block, put in main block

Shazron Abdullah created CB-1849:


 Summary: Remove iOS 4/5 conditional code block, put in main block
 Key: CB-1849
 URL: https://issues.apache.org/jira/browse/CB-1849
 Project: Apache Cordova
  Issue Type: Task
  Components: iOS
Reporter: Shazron Abdullah
Assignee: Shazron Abdullah
Priority: Minor


For example search for:
IsAtLeastiOSVersion(4.0) or 5.0

--
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: iOS' device API

Yeah. Device.name is an ambiguous-sounding API. Thus my original
recommendation to deprecate device.name and add device.model or
device.hardware.

Basically, this API should return a string that makes it clear what
hardware or model of device it is.

On 11/14/12 11:28 AM, Shazron shaz...@gmail.com wrote:

I have somewhat similar concern for iOS:
https://issues.apache.org/jira/browse/CB-1837

Wonder whether we should output the model number instead eg iPad2,5
This might solve the comical procedure to detect an iPad Mini (at least
for
Cordova):
http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5


On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj f...@adobe.com wrote:

 Resurrecting this one.

 BlackBerry has the same issue sorta.

 I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
When I
 ask for device.version, I get BlackBerry Playbook OS for both.

 Device.name also returns weird stuff for the play books, seem like
 arbitrary numbers: 100669958.

 Also, device.platform returns playbook. Shouldn't this be
BlackBerry ?

 /cc anyone from RIM

 On 11/12/12 7:27 PM, Brian LeRoux b...@brian.io wrote:

 thanks shaz
 
 
 On Tue, Nov 13, 2012 at 6:39 AM, Shazron shaz...@gmail.com wrote:
 
  Added:
 
  http://issues.cordova.io/1836
  http://issues.cordova.io/1837
  http://issues.cordova.io/1838
  http://issues.cordova.io/1839
  http://issues.cordova.io/1840
 
 
 
  On Mon, Nov 12, 2012 at 11:14 AM, Shazron shaz...@gmail.com wrote:
 
   Adding jira tasks as per Brian's last comment.
  
  
   On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
  
   +1 sounds like a plan
  
  
   On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj f...@adobe.com wrote:
  
   +1
  
   On 11/8/12 4:01 AM, Brian LeRoux b...@brian.io wrote:
  
   I think would it make sense to:
   
   1. align apis as orig msg from fil suggests
   2. drop in deprecation notice for sync usage and add to deprec
page
   3. add async equiv and get it out of startup path as andrew
 suggests
   
   
   
   
   On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj f...@adobe.com wrote:
   
Although I think we're close to being able to author
 cross-platform
   apps
sans UA detection , I think people still have valid use cases
to
 use
   it.
   
On 11/7/12 6:18 PM, Andrew Grieve agri...@chromium.org
 wrote:
   
I like the idea of at least removing this from the start-up
 path.
  If
   users
want to know about the device, they could always call exec()
   themselves.


On Wed, Nov 7, 2012 at 4:57 PM, Shazron shaz...@gmail.com
 wrote:

 Also, if we remove the device API like Brian suggested, it
 would
  be
good in
 the sense that we won't have to call the CDVDevice plugin
to
   populate
some
 js variables before deviceready can fire -- eliminating a
   dependency.


 On Wed, Nov 7, 2012 at 11:00 AM, Shazron
shaz...@gmail.com
   wrote:

  Agree with Fil to make it consistent - in essence this
is an
  iOS
   bug
:)
 
  Brian, there is one case I can think of -- detecting the
 iPad
   mini's
  features using js - Max Firt investigated trying to do it
 


   
   
  
 
 
 
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
tthe only kludgy way right now using PG would be
 device.platform
  to
  detect iPad2,5 and iPad2,6. I suppose ppl would need to
 detect
   this to
  enlarge certain UI elements for the mini (since the
physical
  area
will be
  smaller than a reg sized iPad)
 
 
  On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj
f...@adobe.com
   wrote:
 
  CI implementation is what I am gunning for here (and can
   actually
   use
 it).
 
  I don't like it either but reality is for people
building
cross-platform
  apps at some point you have to do:
 
  if (device.platform == 'android') // do some stuff
 
  For example, knowing when to attach to a back button vs
   rendering
some
 ui
  to handle that.
 
  IMO we should set up deprecation for name and move to
  model
   as
it's
  clearer (and probably was the reason why iOS went for
 device's
   custom
 name
  in the first place - semantic confusion :P )
 
  On 11/7/12 7:35 AM, Brian LeRoux b...@brian.io wrote:
 
  This may get some rotton tomatoes thrown at me but I
 would be
   in
favor
 of
  axing these apis altogether. I think they are more
 dangerous
   than
 useful
  /
  developers should favor browser feature detection for
 their
  UI
   work.
  
  There is no programmatic reason to want these
properties
   otherwise
 that I
  can think of?
  
  (But agree at least should be consistent as Fil
suggests.)
  
  
  On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj
f...@adobe.com
   wrote:
  
   Currently if you ask for device.platform you will get
  several
 different
   responses

Re: iOS' device API

Gord I added https://issues.apache.org/jira/browse/CB-1848

On 11/14/12 11:20 AM, Gord Tanner gtan...@gmail.com wrote:

+1 that this is suspect.

I know it just returns what webworks is telling us, we probably need to
read the userAgent or go to native.

Assign the jira to me and I can get this cleaned up for this version.

Sent from my iPhone

On 2012-11-14, at 2:14 PM, Filip Maj f...@adobe.com wrote:

 Resurrecting this one.
 
 BlackBerry has the same issue sorta.
 
 I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
When I
 ask for device.version, I get BlackBerry Playbook OS for both.
 
 Device.name also returns weird stuff for the play books, seem like
 arbitrary numbers: 100669958.
 
 Also, device.platform returns playbook. Shouldn't this be
BlackBerry ?
 
 /cc anyone from RIM
 
 On 11/12/12 7:27 PM, Brian LeRoux b...@brian.io wrote:
 
 thanks shaz
 
 
 On Tue, Nov 13, 2012 at 6:39 AM, Shazron shaz...@gmail.com wrote:
 
 Added:
 
 http://issues.cordova.io/1836
 http://issues.cordova.io/1837
 http://issues.cordova.io/1838
 http://issues.cordova.io/1839
 http://issues.cordova.io/1840
 
 
 
 On Mon, Nov 12, 2012 at 11:14 AM, Shazron shaz...@gmail.com wrote:
 
 Adding jira tasks as per Brian's last comment.
 
 
 On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
 
 +1 sounds like a plan
 
 
 On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj f...@adobe.com wrote:
 
 +1
 
 On 11/8/12 4:01 AM, Brian LeRoux b...@brian.io wrote:
 
 I think would it make sense to:
 
 1. align apis as orig msg from fil suggests
 2. drop in deprecation notice for sync usage and add to deprec
page
 3. add async equiv and get it out of startup path as andrew
 suggests
 
 
 
 
 On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj f...@adobe.com wrote:
 
 Although I think we're close to being able to author
 cross-platform
 apps
 sans UA detection , I think people still have valid use cases to
 use
 it.
 
 On 11/7/12 6:18 PM, Andrew Grieve agri...@chromium.org wrote:
 
 I like the idea of at least removing this from the start-up
 path.
 If
 users
 want to know about the device, they could always call exec()
 themselves.
 
 
 On Wed, Nov 7, 2012 at 4:57 PM, Shazron shaz...@gmail.com
 wrote:
 
 Also, if we remove the device API like Brian suggested, it
 would
 be
 good in
 the sense that we won't have to call the CDVDevice plugin to
 populate
 some
 js variables before deviceready can fire -- eliminating a
 dependency.
 
 
 On Wed, Nov 7, 2012 at 11:00 AM, Shazron shaz...@gmail.com
 wrote:
 
 Agree with Fil to make it consistent - in essence this is an
 iOS
 bug
 :)
 
 Brian, there is one case I can think of -- detecting the
 iPad
 mini's
 features using js - Max Firt investigated trying to do it
 
 
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
bu
 tthe only kludgy way right now using PG would be
 device.platform
 to
 detect iPad2,5 and iPad2,6. I suppose ppl would need to
 detect
 this to
 enlarge certain UI elements for the mini (since the physical
 area
 will be
 smaller than a reg sized iPad)
 
 
 On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj f...@adobe.com
 wrote:
 
 CI implementation is what I am gunning for here (and can
 actually
 use
 it).
 
 I don't like it either but reality is for people building
 cross-platform
 apps at some point you have to do:
 
 if (device.platform == 'android') // do some stuff
 
 For example, knowing when to attach to a back button vs
 rendering
 some
 ui
 to handle that.
 
 IMO we should set up deprecation for name and move to
 model
 as
 it's
 clearer (and probably was the reason why iOS went for
 device's
 custom
 name
 in the first place - semantic confusion :P )
 
 On 11/7/12 7:35 AM, Brian LeRoux b...@brian.io wrote:
 
 This may get some rotton tomatoes thrown at me but I
 would be
 in
 favor
 of
 axing these apis altogether. I think they are more
 dangerous
 than
 useful
 /
 developers should favor browser feature detection for
 their
 UI
 work.
 
 There is no programmatic reason to want these properties
 otherwise
 that I
 can think of?
 
 (But agree at least should be consistent as Fil suggests.)
 
 
 On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj f...@adobe.com
 wrote:
 
 Currently if you ask for device.platform you will get
 several
 different
 responses on iOS. You'll get iPhone, iPad, iPod Touch,
 etc.
 This
 seems
 backwards. IMO all of these should return 'iOS'.
 
 Related, device.name returns the custom device name as
 the
 user
 defines
 it
 in iTunes. IMO it should return the model name, I.e.
 What
 device.platform
 returns now.
 
 This would line it up with our docs + other platforms.

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-14 Thread john hight (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497386#comment-13497386
 ] 

john hight commented on CB-1404:


I'd be glad to ... except that due to some un-thriftiness on my part,
I've got a lot of images ballooning the size up to about 64MB.  I'll see if
I can get the size ratcheted down.  Unless, of course, you're ok with
getting it off of github:
https://github.com/johnhight/AudioRecall.git(I'll have it public for a
bit)





 EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
 ---

 Key: CB-1404
 URL: https://issues.apache.org/jira/browse/CB-1404
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0
 Environment: iPad 2, iOS 5.1.1
Reporter: Tom Clarkson
Assignee: Andrew Grieve
 Fix For: 2.2.0


 When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
 WebCore::DocumentThreadableLoader::cancel.
 This appears to be some sort of timing issue, as it does not happen on every 
 call - I am seeing it in an autosave function which makes lots of calls to 
 PGSQLitePlugin. 
 The error did not appear before upgrading to 2.1, and setting the bridge mode 
 to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
 functionality).
 Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
 removing the payload actually does anything different or just makes it fast 
 enough that the timing condition does not come up in normal app usage.
   

--
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-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-14 Thread john hight (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497390#comment-13497390
 ] 

john hight commented on CB-1404:


Oops, nevermind, I'm a newbie to JIRA, didn't know I could attach-upload a
file on the site. I'll upload.





 EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
 ---

 Key: CB-1404
 URL: https://issues.apache.org/jira/browse/CB-1404
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0
 Environment: iPad 2, iOS 5.1.1
Reporter: Tom Clarkson
Assignee: Andrew Grieve
 Fix For: 2.2.0


 When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
 WebCore::DocumentThreadableLoader::cancel.
 This appears to be some sort of timing issue, as it does not happen on every 
 call - I am seeing it in an autosave function which makes lots of calls to 
 PGSQLitePlugin. 
 The error did not appear before upgrading to 2.1, and setting the bridge mode 
 to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
 functionality).
 Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
 removing the payload actually does anything different or just makes it fast 
 enough that the timing condition does not come up in normal app usage.
   

--
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: iOS' device API

2012-11-14 Thread Shazron

I like device.model. Should we adopt it for all the platforms? +1 for me


On Wed, Nov 14, 2012 at 11:44 AM, Filip Maj f...@adobe.com wrote:

 Yeah. Device.name is an ambiguous-sounding API. Thus my original
 recommendation to deprecate device.name and add device.model or
 device.hardware.

 Basically, this API should return a string that makes it clear what
 hardware or model of device it is.

 On 11/14/12 11:28 AM, Shazron shaz...@gmail.com wrote:

 I have somewhat similar concern for iOS:
 https://issues.apache.org/jira/browse/CB-1837
 
 Wonder whether we should output the model number instead eg iPad2,5
 This might solve the comical procedure to detect an iPad Mini (at least
 for
 Cordova):
 http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
 
 
 On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj f...@adobe.com wrote:
 
  Resurrecting this one.
 
  BlackBerry has the same issue sorta.
 
  I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
 When I
  ask for device.version, I get BlackBerry Playbook OS for both.
 
  Device.name also returns weird stuff for the play books, seem like
  arbitrary numbers: 100669958.
 
  Also, device.platform returns playbook. Shouldn't this be
 BlackBerry ?
 
  /cc anyone from RIM
 
  On 11/12/12 7:27 PM, Brian LeRoux b...@brian.io wrote:
 
  thanks shaz
  
  
  On Tue, Nov 13, 2012 at 6:39 AM, Shazron shaz...@gmail.com wrote:
  
   Added:
  
   http://issues.cordova.io/1836
   http://issues.cordova.io/1837
   http://issues.cordova.io/1838
   http://issues.cordova.io/1839
   http://issues.cordova.io/1840
  
  
  
   On Mon, Nov 12, 2012 at 11:14 AM, Shazron shaz...@gmail.com wrote:
  
Adding jira tasks as per Brian's last comment.
   
   
On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
   
+1 sounds like a plan
   
   
On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj f...@adobe.com wrote:
   
+1
   
On 11/8/12 4:01 AM, Brian LeRoux b...@brian.io wrote:
   
I think would it make sense to:

1. align apis as orig msg from fil suggests
2. drop in deprecation notice for sync usage and add to deprec
 page
3. add async equiv and get it out of startup path as andrew
  suggests




On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj f...@adobe.com
 wrote:

 Although I think we're close to being able to author
  cross-platform
apps
 sans UA detection , I think people still have valid use cases
 to
  use
it.

 On 11/7/12 6:18 PM, Andrew Grieve agri...@chromium.org
  wrote:

 I like the idea of at least removing this from the start-up
  path.
   If
users
 want to know about the device, they could always call exec()
themselves.
 
 
 On Wed, Nov 7, 2012 at 4:57 PM, Shazron shaz...@gmail.com
  wrote:
 
  Also, if we remove the device API like Brian suggested, it
  would
   be
 good in
  the sense that we won't have to call the CDVDevice plugin
 to
populate
 some
  js variables before deviceready can fire -- eliminating a
dependency.
 
 
  On Wed, Nov 7, 2012 at 11:00 AM, Shazron
 shaz...@gmail.com
wrote:
 
   Agree with Fil to make it consistent - in essence this
 is an
   iOS
bug
 :)
  
   Brian, there is one case I can think of -- detecting the
  iPad
mini's
   features using js - Max Firt investigated trying to do it
  
 
 


   
  
  
 
 
 http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
 tthe only kludgy way right now using PG would be
  device.platform
   to
   detect iPad2,5 and iPad2,6. I suppose ppl would need to
  detect
this to
   enlarge certain UI elements for the mini (since the
 physical
   area
 will be
   smaller than a reg sized iPad)
  
  
   On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj
 f...@adobe.com
wrote:
  
   CI implementation is what I am gunning for here (and can
actually
use
  it).
  
   I don't like it either but reality is for people
 building
 cross-platform
   apps at some point you have to do:
  
   if (device.platform == 'android') // do some stuff
  
   For example, knowing when to attach to a back button vs
rendering
 some
  ui
   to handle that.
  
   IMO we should set up deprecation for name and move to
   model
as
 it's
   clearer (and probably was the reason why iOS went for
  device's
custom
  name
   in the first place - semantic confusion :P )
  
   On 11/7/12 7:35 AM, Brian LeRoux b...@brian.io wrote:
  
   This may get some rotton tomatoes thrown at me but I
  would be
in
 favor
  of
   axing these apis altogether. I think they are more
  dangerous
than
  useful
   /
   developers should favor browser feature detection for
  their
   UI
work.
   
   There is no programmatic

Re: RIM/BlackBerry folk: please help

2012-11-14 Thread Gord Tanner

So to reproduce I just shell execute ant qnx load-device via a node script?


On Wed, Nov 14, 2012 at 3:20 PM, Filip Maj f...@adobe.com wrote:

 I am working on a continuous integration setup. Got android and iOS
 working. Now trying to get it working with playbook + BB10.

 I've tried many avenues to automate the compilation / signing / deployment
 / launching aspect.

 Using blackberry-deploy I can launch an app. Hooray!

 However, I can't sign the app when I shell out to the ant file (ant
 target build with code.sign=true). I get code signing failed as this
 package is already signed. If I run this command interactively from my
 command line it works fine. Perhaps some kind of permission issue with a
 node process shelling out to ant which in turn fires off to bbwp?

 Then I tried using the debug tokens instead of signing the app. This is a
 shitshow in itself. I keep getting author does not match or something
 along those lines. Tried the various solutions mentioned on the BB support
 forums [1] and none of them work, including:
 - Author tag in config.xml matches the debug token author
 - tablet-sdk/bbwp/bin/bbwp.properties points to the debug token I created
 and installed on the device

 I would also recommend reviewing this whole debug token process as it
 sucks and doesn't work. Echoing the questions in the thread, basically
 Why do I have to enter my company name in 20 different locations?

 Any insight into how to fix the author mismatch or automated signing would
 be helpful.

 [1]
 http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Applica
 tion-author-does-not-match-debug-token-author/td-p/1471779

Re: RIM/BlackBerry folk: please help

I'm doing this with playbook.

For signing, this works:
Edit playbook.xml and set code.sign to true at the top.
Then I run ant playbook build

Note that it should say signing successful

Then tablet-sdkbbwp/blackberry-tablet-sdk/bin/blackberry-deploy
-installApp -launchApp -device ip -password device_password path to
cordova-bb app/build/appname.bar :: this works and launches on the tablet

But if I do the 'ant playbook build' in node via child_process I keep
getting:

Error: code signing request failed because this file has been previously
signed.

Note that I am creating a fresh cordova project every time with
./bin/create, and editing the right settings in project.properties. For
both the node process and me working with the command line I am using the
same generated project.

Related: where the fuck did Sample Inc. come from in my app's author???
(when I do ./blackberry-nativepackager -listManifest path to my app.bar)
My signing keys and my debug tokens have Adobe as the company name.

I will reiterate that this whole debug token process is super annoying and
not convenient for devs AT ALL. Way easier to just sign your shit and be
on your way. Plus debug tokens expire and you can only be limited to x
number of devices with it?

Woo security win...

On 11/14/12 12:26 PM, Gord Tanner gtan...@gmail.com wrote:

So to reproduce I just shell execute ant qnx load-device via a node
script?


On Wed, Nov 14, 2012 at 3:20 PM, Filip Maj f...@adobe.com wrote:

 I am working on a continuous integration setup. Got android and iOS
 working. Now trying to get it working with playbook + BB10.

 I've tried many avenues to automate the compilation / signing /
deployment
 / launching aspect.

 Using blackberry-deploy I can launch an app. Hooray!

 However, I can't sign the app when I shell out to the ant file (ant
 target build with code.sign=true). I get code signing failed as this
 package is already signed. If I run this command interactively from my
 command line it works fine. Perhaps some kind of permission issue with a
 node process shelling out to ant which in turn fires off to bbwp?

 Then I tried using the debug tokens instead of signing the app. This is
a
 shitshow in itself. I keep getting author does not match or something
 along those lines. Tried the various solutions mentioned on the BB
support
 forums [1] and none of them work, including:
 - Author tag in config.xml matches the debug token author
 - tablet-sdk/bbwp/bin/bbwp.properties points to the debug token I
created
 and installed on the device

 I would also recommend reviewing this whole debug token process as it
 sucks and doesn't work. Echoing the questions in the thread, basically
 Why do I have to enter my company name in 20 different locations?

 Any insight into how to fix the author mismatch or automated signing
would
 be helpful.

 [1]
 
http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Appli
ca
 tion-author-does-not-match-debug-token-author/td-p/1471779

[jira] [Commented] (CB-1404) EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode

2012-11-14 Thread john hight (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497420#comment-13497420
 ] 

john hight commented on CB-1404:


Too large to upload as well, it will be on github til I figure out how to make 
it smaller.

 EXC_BAD_ACCESS when using XHR_WITH_PAYLOAD bridge mode 
 ---

 Key: CB-1404
 URL: https://issues.apache.org/jira/browse/CB-1404
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0
 Environment: iPad 2, iOS 5.1.1
Reporter: Tom Clarkson
Assignee: Andrew Grieve
 Fix For: 2.2.0


 When calling a plugin the app crashes on WebThread with EXC_BAD_ACCESS in 
 WebCore::DocumentThreadableLoader::cancel.
 This appears to be some sort of timing issue, as it does not happen on every 
 call - I am seeing it in an autosave function which makes lots of calls to 
 PGSQLitePlugin. 
 The error did not appear before upgrading to 2.1, and setting the bridge mode 
 to IFRAME_NAV restores the previous behaviour (no crashes, but odd scrolling 
 functionality).
 Setting the bridge mode to XHR_NO_PAYLOAD also seems to fix it - not sure if 
 removing the payload actually does anything different or just makes it fast 
 enough that the timing condition does not come up in normal app usage.
   

--
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: Nexus 7 anyone?

Okay, good to hear the file tests passed. Although, there is probably still
something lurking on that device as a couple of folks have reported
problems without too many specifics.

Simon Mac Donald
http://hi.im/simonmacdonald


On Wed, Nov 14, 2012 at 2:19 PM, Joe Bowser bows...@gmail.com wrote:

 Hey

 I just ran the mobile-spec tests, and here's what I found:
 1. Once I remembered to whitelist everything, I only get two errors
 caused by my contacts not being standard.
 2. All the file tests pass on my Nexus 7

 My Nexus 7 is running Android 4.2.  I'll test on an old Android 4.1.2
 Nexus 7 later today or tomorrow.

 On Wed, Nov 14, 2012 at 5:14 AM, Michal Mocny mmo...@chromium.org wrote:
  Thanks Joe, its awesome that we can get android flash instructions
  down to 3 short sentences.
 
  On Wed, Nov 14, 2012 at 12:05 AM, Joe Bowser bows...@gmail.com wrote:
  First, I unlocked the bootloader by pressing power and vol up and vol
  down buttons.  Then once in fastboot, I ran fastboot oem unlock.
 
  After accepting that I voided the warranty on the device, I downloaded
  the factory image from Google, and I ran the flash-all.sh script in
  the directory.  The device rebooted itself into Android 4.2
 
  Here's the link to the factory images:
  https://developers.google.com/android/nexus/images
 
  On Tue, Nov 13, 2012 at 7:44 PM, Michal Mocny mmo...@chromium.org
 wrote:
  Joe, how did you force it to 4.2?
 
  On Tue, Nov 13, 2012 at 9:36 PM, Joe Bowser bows...@gmail.com wrote:
  I did notice that the tests all failed today when I forced mine to
  Android 4.2. I'll test it again tomorrow when I come in the office.
 
  On Tue, Nov 13, 2012 at 6:05 PM, Simon MacDonald
  simon.macdon...@gmail.com wrote:
  If anyone has a Nexus 7 can they run the mobile spec automated file
 API
  tests? There seems to be something strange about that device.
 
  Simon Mac Donald
  http://hi.im/simonmacdonald

Re: [Android] Feedback requested on our camera

Hey Joe,

After delving into this problem for quite some time I have come back around
and I believe this new foreground camera should end up being a plugin
instead of a core part of the API. We really shouldn't be in the business
of implementing a Camera app for end users and there is no way we are going
to make them all happy. I believe we are just opening ourselves up to
more/different problems by continuing on this route.

Sorry to flip, flop on this issue.

Simon Mac Donald
http://hi.im/simonmacdonald


On Tue, Nov 13, 2012 at 6:31 PM, Joe Bowser bows...@gmail.com wrote:

 Hey

 I'm going to resurrect this thread. What do people think of our
 pre-built camera so far? I still have updated on this branch here:

 https://github.com/infil00p/cordova-android/tree/camera

 It'd be good to get more feedback before continuing down this road.
 The downside so far is having to pass around assets.  I wish there was
 a way around this.  Also, feedback on the UI elements would also help.

 There's still work to be done, but should we hav this as a built-in
 option for 2.3.0, or should we delay to 2.4.0?  It'd be good to get
 feedback on this now before we continue to move with this.

 Joe

[jira] [Assigned] (CB-1668) Refactor project template scripts.

2012-11-14 Thread Anis Kadri (JIRA)


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

Anis Kadri reassigned CB-1668:
--

Assignee: Anis Kadri

 Refactor project template scripts.
 --

 Key: CB-1668
 URL: https://issues.apache.org/jira/browse/CB-1668
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, Bada, BlackBerry, iOS, Tizen, webOS, Windows 8, 
 WP7
Affects Versions: Master
Reporter: Andrew Grieve
Assignee: Anis Kadri
Priority: Minor
 Fix For: 2.3.0


 Relevant mailing-list discussion:
 http://markmail.org/thread/znkkjmwgoc23lhhq
 The cordova/* scripts need some attention. Their names reflect what they do, 
 and they should be consistent across platforms.
 The main operations:
 - build (full or incremental) (other scripts depend on this)
 - run (on device / on emulator / in ripple)
 - package (for app-store purposes)

--
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: [Android] Feedback requested on our camera

2012-11-14 Thread Andrew Grieve

Yep, got it working by adding that line to the manifest. My impression is
the same as Simon just said. The stock Camera on 4.2 is really nice, so
taking this away is a bit sad. I understand the motivation behind wanting
this when other stock cameras are buggy though, and there are certainly
many apps out there that have their own cameras in them. So... if we could
make this a plugin, apps that want a custom camera could pull it in and
tweak it to their needs, but I don't think it's the right long-term play.


On Wed, Nov 14, 2012 at 3:47 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:

 Hey Joe,

 After delving into this problem for quite some time I have come back around
 and I believe this new foreground camera should end up being a plugin
 instead of a core part of the API. We really shouldn't be in the business
 of implementing a Camera app for end users and there is no way we are going
 to make them all happy. I believe we are just opening ourselves up to
 more/different problems by continuing on this route.

 Sorry to flip, flop on this issue.

 Simon Mac Donald
 http://hi.im/simonmacdonald


 On Tue, Nov 13, 2012 at 6:31 PM, Joe Bowser bows...@gmail.com wrote:

  Hey
 
  I'm going to resurrect this thread. What do people think of our
  pre-built camera so far? I still have updated on this branch here:
 
  https://github.com/infil00p/cordova-android/tree/camera
 
  It'd be good to get more feedback before continuing down this road.
  The downside so far is having to pass around assets.  I wish there was
  a way around this.  Also, feedback on the UI elements would also help.
 
  There's still work to be done, but should we hav this as a built-in
  option for 2.3.0, or should we delay to 2.4.0?  It'd be good to get
  feedback on this now before we continue to move with this.
 
  Joe

Re: [Android] Feedback requested on our camera

Fair enough.  If we make this a plugin, then we should deal with the
state issue.  Let's close the tickets and let the users know.

On Wed, Nov 14, 2012 at 1:05 PM, Andrew Grieve agri...@chromium.org wrote:
 Yep, got it working by adding that line to the manifest. My impression is
 the same as Simon just said. The stock Camera on 4.2 is really nice, so
 taking this away is a bit sad. I understand the motivation behind wanting
 this when other stock cameras are buggy though, and there are certainly
 many apps out there that have their own cameras in them. So... if we could
 make this a plugin, apps that want a custom camera could pull it in and
 tweak it to their needs, but I don't think it's the right long-term play.


 On Wed, Nov 14, 2012 at 3:47 PM, Simon MacDonald
 simon.macdon...@gmail.comwrote:

 Hey Joe,

 After delving into this problem for quite some time I have come back around
 and I believe this new foreground camera should end up being a plugin
 instead of a core part of the API. We really shouldn't be in the business
 of implementing a Camera app for end users and there is no way we are going
 to make them all happy. I believe we are just opening ourselves up to
 more/different problems by continuing on this route.

 Sorry to flip, flop on this issue.

 Simon Mac Donald
 http://hi.im/simonmacdonald


 On Tue, Nov 13, 2012 at 6:31 PM, Joe Bowser bows...@gmail.com wrote:

  Hey
 
  I'm going to resurrect this thread. What do people think of our
  pre-built camera so far? I still have updated on this branch here:
 
  https://github.com/infil00p/cordova-android/tree/camera
 
  It'd be good to get more feedback before continuing down this road.
  The downside so far is having to pass around assets.  I wish there was
  a way around this.  Also, feedback on the UI elements would also help.
 
  There's still work to be done, but should we hav this as a built-in
  option for 2.3.0, or should we delay to 2.4.0?  It'd be good to get
  feedback on this now before we continue to move with this.
 
  Joe

Re: [Android] Can everyone run the tests?

Simon: Looks like it's missing the manifest. Can you make sure your
manifest is updated? I had to clean that up on one of the more recent
commits.

On Wed, Nov 14, 2012 at 1:10 PM, Simon MacDonald
simon.macdon...@gmail.com wrote:
All of org.apache.cordova.test.BackButtonMultiPageTest fail for me. Seems
to be missing:

java.lang.RuntimeException: Unable to resolve activity for: Intent {
act=android.intent.action.MAIN flg=0x1000
cmp=org.apache.cordova.test/.actions.backbuttonmultipage }
at android.app.Instrumentation.startActivitySync(Instrumentation.java:370)
at
android.test.InstrumentationTestCase.launchActivityWithIntent(InstrumentationTestCase.java:119)
at
android.test.InstrumentationTestCase.launchActivity(InstrumentationTestCase.java:97)
at
android.test.ActivityInstrumentationTestCase2.getActivity(ActivityInstrumentationTestCase2.java:104)
at
org.apache.cordova.test.BackButtonMultiPageTest.setUp(BackButtonMultiPageTest.java:47)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
at
android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:545)
at
android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1551)

Simon Mac Donald
http://hi.im/simonmacdonald

On Tue, Nov 13, 2012 at 1:38 PM, Joe Bowser bows...@gmail.com wrote:

BUMP! Can everyone run these tests? I need to know about failures ASAP

On Mon, Nov 5, 2012 at 9:44 AM, Joe Bowser bows...@gmail.com wrote:
Sorry, wrong thread. Obviously.

The command line version of the unit tests is on the Wiki.

On Mon, Nov 5, 2012 at 9:43 AM, Joe Bowser bows...@gmail.com wrote:

I did send an e-mail about the cleaning of the tests with the wiki
article. Did everyone get it?

On Mon, Nov 5, 2012 at 9:21 AM, Andrew Grieve agri...@chromium.org
wrote:

Yes, thanks Joe for pushing on this. Testing will only make things
better!

Do you think it'd be feasible to create a script that would launch the
tests? Eclipse is great when they fail, but to ensure they pass,
command
line is often nicer. The instructions on the wiki seem like they may be
out
of date? They reference phonegap, and they don't say what cordova
target
to
build.

On Fri, Nov 2, 2012 at 9:25 PM, Joe Bowser bows...@gmail.com wrote:

If we still have JAR issues, that should be a blocker for the
release.
Having these tests should be required now, since we have too many
Java
bits that we can't break. I removed the old Selenium JAR a while ago.

I would love it if we could get Selenium to work with CordovaWebView
so
that we could click on HTML elements, but we should be able to
automate
the
Back Button and Menu Button bindings, as well as random key bindings.
That
being said, we should be able to execute Javascript to do what we
need
instead of testing touch and click events, which in theory should
have
been
tested as part of Android's CTS. (No idea if this ever happens).

On Fri, Nov 2, 2012 at 5:58 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:

That's great Joe. I was under the impression that the Android repo
tests
were still dependent on a jar we didn't have access to. I'll make
sure
running the tests is part of my regular process and gasp I will
even
write a few.

Simon Mac Donald
http://hi.im/simonmacdonald

On Fri, Nov 2, 2012 at 4:38 PM, Joe Bowser bows...@gmail.com
wrote:

Hey

After the last scare with CordovaWebView, I want to know if
everyone
who
commits on Android can run the tests that are currently committed
with
Android? You have to be able to do both things with the tests in
Eclipse:

1. Run the test as an Android Application
2. Run the Android JUnit Tests

There is a command-line method to do this, but honestly if you're
finding
failures here, you'll probably need Eclipse anyway to debug the
Java
code.
If you're super hardcore, I believe that this command is still
in
the
wiki
here:

http://wiki.apache.org/cordova/RunningTests

Also, are other platforms doing testing outside of mobile-spec
Jasmine
tests? What impact would this have on CI work? I'm pretty sure
that
the
Android tests should be relatively simple.

Joe

Re: [Android] Can everyone run the tests?

OK, I'm getting the same error on this end. I have no idea why this
passed last week. I'll add it to the manifest.

On Wed, Nov 14, 2012 at 1:18 PM, Simon MacDonald
simon.macdon...@gmail.com wrote:
The manifest in the Apache repo (
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a=blob;f=test/AndroidManifest.xml;h=e35f6c678ba6381f4b9e9fcadc86ccf0930969bc;hb=HEAD)
does not have backbuttonmultipage anywhere it in.

Simon Mac Donald
http://hi.im/simonmacdonald

On Wed, Nov 14, 2012 at 4:14 PM, Joe Bowser bows...@gmail.com wrote:

Simon: Looks like it's missing the manifest. Can you make sure your
manifest is updated? I had to clean that up on one of the more recent
commits.

On Wed, Nov 14, 2012 at 1:10 PM, Simon MacDonald
simon.macdon...@gmail.com wrote:
All of org.apache.cordova.test.BackButtonMultiPageTest fail for me. Seems
to be missing:

android.test.InstrumentationTestCase.launchActivityWithIntent(InstrumentationTestCase.java:119)
at

android.test.InstrumentationTestCase.launchActivity(InstrumentationTestCase.java:97)
at

android.test.ActivityInstrumentationTestCase2.getActivity(ActivityInstrumentationTestCase2.java:104)
at

org.apache.cordova.test.BackButtonMultiPageTest.setUp(BackButtonMultiPageTest.java:47)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
at

android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:545)
at

android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1551)

Simon Mac Donald
http://hi.im/simonmacdonald

On Tue, Nov 13, 2012 at 1:38 PM, Joe Bowser bows...@gmail.com wrote:

BUMP! Can everyone run these tests? I need to know about failures ASAP

On Mon, Nov 5, 2012 at 9:44 AM, Joe Bowser bows...@gmail.com wrote:
Sorry, wrong thread. Obviously.

The command line version of the unit tests is on the Wiki.

On Mon, Nov 5, 2012 at 9:43 AM, Joe Bowser bows...@gmail.com wrote:

I did send an e-mail about the cleaning of the tests with the wiki
article. Did everyone get it?

On Mon, Nov 5, 2012 at 9:21 AM, Andrew Grieve agri...@chromium.org
wrote:

Yes, thanks Joe for pushing on this. Testing will only make things
better!

Do you think it'd be feasible to create a script that would launch
the
tests? Eclipse is great when they fail, but to ensure they pass,
command
line is often nicer. The instructions on the wiki seem like they
may be
out
of date? They reference phonegap, and they don't say what cordova
target
to
build.

On Fri, Nov 2, 2012 at 9:25 PM, Joe Bowser bows...@gmail.com
wrote:

I would love it if we could get Selenium to work with
CordovaWebView
so
that we could click on HTML elements, but we should be able to
automate
the
Back Button and Menu Button bindings, as well as random key
bindings.
That
being said, we should be able to execute Javascript to do what we
need
instead of testing touch and click events, which in theory should
have
been
tested as part of Android's CTS. (No idea if this ever happens).

On Fri, Nov 2, 2012 at 5:58 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:

That's great Joe. I was under the impression that the Android
repo
tests
were still dependent on a jar we didn't have access to. I'll
make
sure
running the tests is part of my regular process and gasp I
will
even
write a few.

Simon Mac Donald
http://hi.im/simonmacdonald

On Fri, Nov 2, 2012 at 4:38 PM, Joe Bowser bows...@gmail.com
wrote:

Hey

After the last scare with CordovaWebView, I want to know if
everyone
who
commits on Android can run the tests that are currently
committed
with
Android? You have to be able to do both things with the tests
in
Eclipse:

1. Run the test as an Android Application
2. Run the Android JUnit Tests

There is a command-line method to do this, but honestly if
you're
finding
failures here, you'll probably need Eclipse anyway to debug
the
Java
code.
If you're super hardcore, I believe that this command is
still
in
the
wiki
here:

http://wiki.apache.org/cordova/RunningTests

Also, are other

[jira] [Commented] (CB-1843) Echo plugin doesn't work in iOS


[ 
https://issues.apache.org/jira/browse/CB-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497465#comment-13497465
 ] 

Andrew Grieve commented on CB-1843:
---

Downloaded your link and it does repro for me! I'll look into why it's not 
working tomorrow.

 Echo plugin doesn't work in iOS
 ---

 Key: CB-1843
 URL: https://issues.apache.org/jira/browse/CB-1843
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.2.0
 Environment: iPad2, iOS Simulator, iOS 6, XCode 4.5.2
Reporter: Aaron Moman
Assignee: Andrew Grieve

 I'm using the base application for iOS created with the create script.  That 
 works correctly.  I add the Echo plugin example Objective-C code and 
 everything compiles.  Then I add the JS to call it and that's when things get 
 weird.
 In index.js, after the var app = { ... }; statement I add:
 window.echo = function(str, callback) {
 cordova.exec(callback, function(err) {
 callback('Nothing to echo.');
 }, Echo, echo, [str]);
 };
 Then in onDeviceReady I add the following after the receivedEvent call:
 window.echo(echome, function(echoValue) { alert(echoValue == echome); 
 });
 I run the app and I get the green glowing Device is ready message.  So 
 we're getting into onDeviceReady successfully.  But the true alert never 
 pops up.
 Until I double-click on the home button.  Then when the running apps show at 
 the bottom of the screen, then the alert pops up.  I tap back into the app 
 and I can click to dismiss the alert.
 What's going on here?  It seems like the example plug-in should work a little 
 better than this.
 The reason I'm doing this at all is that I'm seeing similar behavior in my 
 app that I'm currently failing to upgrade from 2.1 to 2.2.
 Worse: If I single-click the home button and then go back to the app, I get 
 the alert pop-up, but after I click on it the screen goes black.
 Any help would be greatly appreciated.
 Thanks,
 Aaron

--
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: [Android] Can everyone run the tests?

Yup, it passed when I ran it and only it.

Simon Mac Donald
http://hi.im/simonmacdonald


On Wed, Nov 14, 2012 at 4:35 PM, Joe Bowser bows...@gmail.com wrote:

 How can testPreconditions fail, but testViaLoadUrl pass? Can you run
 the test by itself? testViaHref is known to fail, and there's an issue
 open about that bug.

[jira] [Updated] (CB-1843) Echo plugin doesn't work in iOS

2012-11-14 Thread Aaron Moman (JIRA)


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

Aaron Moman updated CB-1843:



I'm pushing up the status since this breaks a previously working app.  This is 
preventing me from being able to submit to the App Store.

 Echo plugin doesn't work in iOS
 ---

 Key: CB-1843
 URL: https://issues.apache.org/jira/browse/CB-1843
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.2.0
 Environment: iPad2, iOS Simulator, iOS 6, XCode 4.5.2
Reporter: Aaron Moman
Assignee: Andrew Grieve

 I'm using the base application for iOS created with the create script.  That 
 works correctly.  I add the Echo plugin example Objective-C code and 
 everything compiles.  Then I add the JS to call it and that's when things get 
 weird.
 In index.js, after the var app = { ... }; statement I add:
 window.echo = function(str, callback) {
 cordova.exec(callback, function(err) {
 callback('Nothing to echo.');
 }, Echo, echo, [str]);
 };
 Then in onDeviceReady I add the following after the receivedEvent call:
 window.echo(echome, function(echoValue) { alert(echoValue == echome); 
 });
 I run the app and I get the green glowing Device is ready message.  So 
 we're getting into onDeviceReady successfully.  But the true alert never 
 pops up.
 Until I double-click on the home button.  Then when the running apps show at 
 the bottom of the screen, then the alert pops up.  I tap back into the app 
 and I can click to dismiss the alert.
 What's going on here?  It seems like the example plug-in should work a little 
 better than this.
 The reason I'm doing this at all is that I'm seeing similar behavior in my 
 app that I'm currently failing to upgrade from 2.1 to 2.2.
 Worse: If I single-click the home button and then go back to the app, I get 
 the alert pop-up, but after I click on it the screen goes black.
 Any help would be greatly appreciated.
 Thanks,
 Aaron

--
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: Cordova Blackberry Project - Include external jar

2012-11-14 Thread Tim Kim

Hi there Jose,

I believe this is possible, but I've not done so myself. I've done some
googling and it appears there are a lot of confusing links on how to solve
this. eg,
http://supportforums.blackberry.com/t5/Java-Development/Tutorial-How-To-Use-3rd-Party-Libraries-in-your-Applications/m-p/178291

What I would do is just explode/unzip that external .jar file and deal with
the imports that way.



On 13 November 2012 09:40, Jose Larghi jlar...@cespi.unlp.edu.ar wrote:

 Hi all,

 It's possible include an external jar in blackberry project? How? My plugin
 have one dependency jar.

 Thanks.

 *Lic. Larghi, José Ignacio*
 *JEE Software Developer*




-- 
Timothy Kim

Re: Cordova Blackberry Project - Include external jar

2012-11-14 Thread Drew Walters

Yes it's possible. It's how I provided barcode scanning on OS 5 by
including ZXing jar.

https://github.com/phonegap/phonegap-plugins/tree/master/BlackBerry/BarcodeScanner

Basically, preverify the external jar, then place it inside the cordova.jar
at the root of the archive.


On Wed, Nov 14, 2012 at 4:10 PM, Tim Kim timki...@gmail.com wrote:

 Hi there Jose,

 I believe this is possible, but I've not done so myself. I've done some
 googling and it appears there are a lot of confusing links on how to solve
 this. eg,

 http://supportforums.blackberry.com/t5/Java-Development/Tutorial-How-To-Use-3rd-Party-Libraries-in-your-Applications/m-p/178291

 What I would do is just explode/unzip that external .jar file and deal with
 the imports that way.



 On 13 November 2012 09:40, Jose Larghi jlar...@cespi.unlp.edu.ar wrote:

  Hi all,
 
  It's possible include an external jar in blackberry project? How? My
 plugin
  have one dependency jar.
 
  Thanks.
 
  *Lic. Larghi, José Ignacio*
  *JEE Software Developer*
 



 --
 Timothy Kim

[jira] [Commented] (CB-1846) Offline event doesn't work


[ 
https://issues.apache.org/jira/browse/CB-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497534#comment-13497534
 ] 

Joe Bowser commented on CB-1846:


I can't reproduce this issue either, and I've tested it on my Galaxy 
Nexus(4.1.2), Nexus S (2.3.6) and Samsung Galaxy SII (4.0.3).

 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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: RIM/BlackBerry folk: please help

2012-11-14 Thread Tim Kim

The reason why you keep getting signing failures even with a fresh project
is that you already did it once. ie, in your config.xml, the widget version
is set to 1.0.0.0 and the name attribute is cordovaExample. So the
first time should work, but every new fresh project there after will have
the same values.

I would recommend updating the version number every time you deploy and not
worry about that debug-token business -  I've never used it.

-- 
Timothy Kim

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[
https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497560#comment-13497560
]

Joe Bowser commented on CB-1185:

OK, I re-installed, restarted and now I get this error, but I also get this:
D/CordovaLog( 2837): file:///android_asset/www/assets/js/util.js: Line 501 :
500 error null true undefined
I/Web Console( 2837): 500 error null true undefined at
file:///android_asset/www/assets/js/util.js:501

The more I look at this, the less it looks like a Cordova/PhoneGap error, I'm
going to have to close this as Won't Fix for now. If you can figure out
what's causing your 500 error, please feel free to re-submit the bug.

When Application is placed in background and resumed, the UI is frozen
--

[jira] [Resolved] (CB-1185) When Application is placed in background and resumed, the UI is frozen

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

Joe Bowser resolved CB-1185.

Resolution: Won't Fix
Assignee: Joe Bowser (was: Filip Maj)

This seems like poor XHR handling, since I only see the error message for a
brief second before it just spins. The log from my device after finally being
able to reproduce the error shows a 500 error from the server. There MIGHT be
a problem with events, but we need this distilled, and I think we need a new
issue for this.

When Application is placed in background and resumed, the UI is frozen
--

Key: CB-1185
URL: https://issues.apache.org/jira/browse/CB-1185
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.0.0
Environment: Jelly Bean 4.1, ICS 4.0.x
Reporter: Greg
Assignee: Joe Bowser
Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip

[jira] [Created] (CB-1850) Add device.model to the Device API

Shazron Abdullah created CB-1850:


 Summary: Add device.model to the Device API
 Key: CB-1850
 URL: https://issues.apache.org/jira/browse/CB-1850
 Project: Apache Cordova
  Issue Type: Task
Reporter: Shazron Abdullah
 Fix For: 2.3.0


Add device.model to the Device API.
This would identify the exact model of the device, for example iPad2,5

--
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-1852) Add device.model to the Device API

Shazron Abdullah created CB-1852:


 Summary: Add device.model to the Device API
 Key: CB-1852
 URL: https://issues.apache.org/jira/browse/CB-1852
 Project: Apache Cordova
  Issue Type: Sub-task
  Components: Android
Reporter: Shazron Abdullah
Assignee: Joe Bowser
 Fix For: 2.3.0


Add device.model to the Device API.
This would identify the exact model of the device, for example iPad2,5

--
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-1853) Add device.model to the Device API

Shazron Abdullah created CB-1853:


 Summary: Add device.model to the Device API
 Key: CB-1853
 URL: https://issues.apache.org/jira/browse/CB-1853
 Project: Apache Cordova
  Issue Type: Sub-task
  Components: BlackBerry
Reporter: Shazron Abdullah
Assignee: Tim Kim


Add device.model to the Device API.
This would identify the exact model of the device, for example iPad2,5

--
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-1850) Add device.model to the Device API


[ 
https://issues.apache.org/jira/browse/CB-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497583#comment-13497583
 ] 

Shazron Abdullah commented on CB-1850:
--

Tentatively set to 2.3.0 - if we can't make it for then, bump to 2.4.0.


 Add device.model to the Device API
 --

 Key: CB-1850
 URL: https://issues.apache.org/jira/browse/CB-1850
 Project: Apache Cordova
  Issue Type: Task
Reporter: Shazron Abdullah
 Fix For: 2.3.0


 Add device.model to the Device API.
 This would identify the exact model of the device, for example iPad2,5

--
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-1855) Add device.model to the Device API

Shazron Abdullah created CB-1855:


 Summary: Add device.model to the Device API
 Key: CB-1855
 URL: https://issues.apache.org/jira/browse/CB-1855
 Project: Apache Cordova
  Issue Type: Sub-task
  Components: CordovaJS
Reporter: Shazron Abdullah
Assignee: Filip Maj
 Fix For: 2.3.0


Add device.model to the Device API.
This would identify the exact model of the device, for example iPad2,5

--
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-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-14 Thread Lindsey Simon (JIRA)

[
https://issues.apache.org/jira/browse/CB-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497593#comment-13497593
]

Lindsey Simon commented on CB-1185:
---

[~gregavola] Since you do have an easy to repro situation for some magical
reason, can you try adding this to the Activity to see if it makes any
difference? I started wondering if it wasn't a cache/memory issue.

@Override
public void onResume() {
this.appView.clearCache(false);
this.appView.destroyDrawingCache();
super.onResume();
}

When Application is placed in background and resumed, the UI is frozen
--

Key: CB-1185
URL: https://issues.apache.org/jira/browse/CB-1185
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.0.0
Environment: Jelly Bean 4.1, ICS 4.0.x
Reporter: Greg
Assignee: Joe Bowser
Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip

[jira] [Resolved] (CB-1846) Offline event doesn't work


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

Joe Bowser resolved CB-1846.


Resolution: Cannot Reproduce

Tested on Nexus 7 as well with Android 4.2. Offline event does work, but it's 
firing too many events instead of not firing this event.

 Offline event doesn't work
 --

 Key: CB-1846
 URL: https://issues.apache.org/jira/browse/CB-1846
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Samsung Galaxy S2 and Google Nexus 7
Reporter: Remzi Cavdar
Assignee: Joe Bowser
 Fix For: 2.2.0


 The offline event doesn't work and I had said this before release, but you 
 guys wanted to release PhoneGap 2.2.0 
 This is my code:
 document.addEventListener(deviceready, onDeviceReady, false);
 function onDeviceReady() {
   document.addEventListener(offline, function() {
   alert(Er is geen internet verbinding!\nSchakel Wifi of 3G in);
   }, false);
 }
 /* English: alert(No internet connection!\nPlease turn on Wifi or 3G);  */

--
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-1856) Offline Event fires twice on Jellybean

Joe Bowser created CB-1856:
--

 Summary: Offline Event fires twice on Jellybean
 Key: CB-1856
 URL: https://issues.apache.org/jira/browse/CB-1856
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.3.0
 Environment: Neuxs 7 running Android 4.2
Reporter: Joe Bowser
Assignee: Joe Bowser
Priority: Minor
 Fix For: 2.3.0


While testing CB-1846, I discovered that the Offline and Online events are 
being called twice on my Galaxy Nexus and my Nexus 7.  The Samsung Galaxy S2 
and the Nexus S that I tested are working as expected.  We ideally should only 
fire this event once when we switch WiFi on and off.

--
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: [docs] OS version supported with a Cordova version

2012-11-14 Thread Shazron

I think a URL to point for Minimum Requirements that is separate from the
Getting Started Guide would be valuable, and of course the GS Guide would
just point to it in one of its sections.


On Mon, Nov 12, 2012 at 7:54 PM, Brian LeRoux b...@brian.io wrote:

 was trying to think through the exact issue to file here and I'm wondering
 if we want another guide titled 'Before you start' or just ensure there is
 a 'Minimum Requirements' section in each getting started guideI'm
 leaning towards the latter though if we go w/ the former we can give more
 general setup advice.

 Thoughts?


 On Sat, Nov 10, 2012 at 9:55 PM, Brian LeRoux b...@brian.io wrote:

  yep
 
 
  On Thu, Nov 8, 2012 at 9:52 AM, Shazron shaz...@gmail.com wrote:
 
  Can we swipe that table for Cordova?
 
 
  On Thu, Nov 8, 2012 at 3:58 AM, Brian LeRoux b...@brian.io wrote:
 
   Yup this is a very good idea. We sorta have this on the phonegap dist
  here
   http://phonegap.com/about/feature
  
  
   On Wed, Nov 7, 2012 at 11:51 AM, Filip Maj f...@adobe.com wrote:
  
Good idea.
   
Also: all requirements for a platform implementation should be
 clearly
specified at the top of the platform's README. Ant, node, OS
 versions,
   etc.
   
On 11/7/12 11:29 AM, Shazron shaz...@gmail.com wrote:
   
I noticed that we don't have anything in the docs regarding a
 Cordova
version's support for an OS version. For example, Cordova 2.3.0
 will
support iOS 5+ only, there is nowhere in the docs that we can
 reflect
this.

I suppose it can be in the Getting Started Guide requirements but
   perhaps
a
new section will be clearer. Objections on adding a new section? I
  can
   add
the jira tasks.

[jira] [Created] (CB-1857) UIImagePickerController will not change language based on device language.

2012-11-14 Thread Ronald Partridge (JIRA)

Ronald Partridge created CB-1857:


 Summary: UIImagePickerController will not change language based on 
device language.
 Key: CB-1857
 URL: https://issues.apache.org/jira/browse/CB-1857
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.2.0
 Environment: iOS 5.1.1 on iPhone 4S
Reporter: Ronald Partridge
Assignee: Shazron Abdullah
Priority: Minor


I am attempting to figure out why the Camera feature CDVCameraPicker which 
extends UIImagePickerController will not change the language based on the 
device language setting. I am not sure if this is a bug or if this is the way 
UIImagePickerController is supposed to behave in general. Any advice on how to 
get this working in French when the device is in French would be greatly 
appreciated.

--
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: Nexus 7 anyone?

K its running on port 80

On 11/14/12 4:20 PM, Brian LeRoux b...@brian.io wrote:

eh fil, I love the port choice but can you get it on 80? I'd like to
point
dns to ci.cordova.io


On Thu, Nov 15, 2012 at 7:39 AM, Simon MacDonald
simon.macdon...@gmail.comwrote:

 Okay, good to hear the file tests passed. Although, there is probably
still
 something lurking on that device as a couple of folks have reported
 problems without too many specifics.

 Simon Mac Donald
 http://hi.im/simonmacdonald


 On Wed, Nov 14, 2012 at 2:19 PM, Joe Bowser bows...@gmail.com wrote:

  Hey
 
  I just ran the mobile-spec tests, and here's what I found:
  1. Once I remembered to whitelist everything, I only get two errors
  caused by my contacts not being standard.
  2. All the file tests pass on my Nexus 7
 
  My Nexus 7 is running Android 4.2.  I'll test on an old Android 4.1.2
  Nexus 7 later today or tomorrow.
 
  On Wed, Nov 14, 2012 at 5:14 AM, Michal Mocny mmo...@chromium.org
 wrote:
   Thanks Joe, its awesome that we can get android flash instructions
   down to 3 short sentences.
  
   On Wed, Nov 14, 2012 at 12:05 AM, Joe Bowser bows...@gmail.com
 wrote:
   First, I unlocked the bootloader by pressing power and vol up and
vol
   down buttons.  Then once in fastboot, I ran fastboot oem unlock.
  
   After accepting that I voided the warranty on the device, I
downloaded
   the factory image from Google, and I ran the flash-all.sh script in
   the directory.  The device rebooted itself into Android 4.2
  
   Here's the link to the factory images:
   https://developers.google.com/android/nexus/images
  
   On Tue, Nov 13, 2012 at 7:44 PM, Michal Mocny mmo...@chromium.org
  wrote:
   Joe, how did you force it to 4.2?
  
   On Tue, Nov 13, 2012 at 9:36 PM, Joe Bowser bows...@gmail.com
 wrote:
   I did notice that the tests all failed today when I forced mine
to
   Android 4.2. I'll test it again tomorrow when I come in the
office.
  
   On Tue, Nov 13, 2012 at 6:05 PM, Simon MacDonald
   simon.macdon...@gmail.com wrote:
   If anyone has a Nexus 7 can they run the mobile spec automated
file
  API
   tests? There seems to be something strange about that device.
  
   Simon Mac Donald
   http://hi.im/simonmacdonald

[jira] [Commented] (CB-1856) Offline Event fires twice on Jellybean


[ 
https://issues.apache.org/jira/browse/CB-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497685#comment-13497685
 ] 

Andrew Grieve commented on CB-1856:
---

The JS has code to throttle offline events, so my guess here is that the 
webview is sending one of the events and cordova is sending the other. We could 
work around this by cancelling cordova's if the system sends one, or maybe just 
disable cordova's for JB? Either way, I'm not going to look at this (at least 
not right away) since it's low priority.

 Offline Event fires twice on Jellybean
 --

 Key: CB-1856
 URL: https://issues.apache.org/jira/browse/CB-1856
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.3.0
 Environment: Neuxs 7 running Android 4.2
Reporter: Joe Bowser
Assignee: Joe Bowser
Priority: Minor
 Fix For: 2.3.0


 While testing CB-1846, I discovered that the Offline and Online events are 
 being called twice on my Galaxy Nexus and my Nexus 7.  The Samsung Galaxy S2 
 and the Nexus S that I tested are working as expected.  We ideally should 
 only fire this event once when we switch WiFi on and off.

--
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-1858) Wrappers for desktop (Mac and Linux) applications

2012-11-14 Thread Andrew Pennebaker (JIRA)

Andrew Pennebaker created CB-1858:
-

 Summary: Wrappers for desktop (Mac and Linux) applications
 Key: CB-1858
 URL: https://issues.apache.org/jira/browse/CB-1858
 Project: Apache Cordova
  Issue Type: Improvement
Affects Versions: 2.2.0
 Environment: Mac OS X 10.8 and Linux
Reporter: Andrew Pennebaker
Priority: Minor


I see that Cordova has support for Windows 8 desktop applications. Does Cordova 
also have support for desktop applications in Mac OS X or Linux?

If not, could Cordova please add this? I'd love to be able to write apps for 
every major platform all in JavaScript.

--
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: [Android] Can everyone run the tests?

2012-11-14 Thread Andrew Grieve

Tried to follow the command-line instructions but get:

agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework (asdf)
$ adb shell am instrument -w
com.phonegap/android.test.InstrumentationTestRunner
INSTRUMENTATION_STATUS: id=ActivityManagerService
INSTRUMENTATION_STATUS: Error=Unable to find instrumentation info for:
ComponentInfo{com.phonegap/android.test.InstrumentationTestRunner}
INSTRUMENTATION_STATUS_CODE: -1
android.util.AndroidException: INSTRUMENTATION_FAILED:
com.phonegap/android.test.InstrumentationTestRunner

Changing to org.apache.cordova:
agrieve@dhcp-172-23-181-44 ~/git/incubator-cordova-android/framework (asdf)
$ adb shell am instrument -w
org.apache.cordova/android.test.InstrumentationTestRunner
android.util.AndroidException: INSTRUMENTATION_FAILED:
org.apache.cordova/android.test.InstrumentationTestRunner

On Wed, Nov 14, 2012 at 4:41 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:

 Yup, it passed when I ran it and only it.

 Simon Mac Donald
 http://hi.im/simonmacdonald


 On Wed, Nov 14, 2012 at 4:35 PM, Joe Bowser bows...@gmail.com wrote:

  How can testPreconditions fail, but testViaLoadUrl pass? Can you run
  the test by itself? testViaHref is known to fail, and there's an issue
  open about that bug.

Re: CLA Confirmations

2012-11-14 Thread Andrew Grieve

bump


On Tue, Nov 13, 2012 at 12:06 PM, Andrew Grieve agri...@chromium.orgwrote:

 I think I've heard that sometimes when people send in their CLAs that they
 don't make it to this page:

 https://people.apache.org/committer-index.html#unlistedclas

 Is there someone that we should email in this case? Seems it's happened to
 Kevin :(

[jira] [Resolved] (CB-1843) Echo plugin doesn't work in iOS