date:20150128

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-medic/pull/24


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-file-transfer pull request: CB-5059 Add a CookieMan...

2015-01-28 Thread crissi

Github user crissi commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/60#issuecomment-71813597
  
+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-android pull request: CB-4914 Fix build whitespace issue

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/147


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-camera pull request: add try ... catch for getting ...

2015-01-28 Thread vilic

GitHub user vilic opened a pull request:

https://github.com/apache/cordova-plugin-camera/pull/63

add try ... catch for getting image orientation

There's bug in Windows Phone 8.1 causing Seek on a DssPhotoStream not 
working properly.
https://connect.microsoft.com/VisualStudio/feedback/details/783252
But a mis-oriented file is better than nothing, so try and catch.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vilic/cordova-plugin-camera patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-camera/pull/63.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #63


commit d7e708db092dee3140adbb906322de6f1ed6ec03
Author: VILIC VANE i...@vilic.info
Date:   2015-01-28T17:31:21Z

add try ... catch for getting image orientation

There's bug in Windows Phone 8.1 causing Seek on a DssPhotoStream not 
working properly.
https://connect.microsoft.com/VisualStudio/feedback/details/783252
But a mis-oriented file is better than nothing, so try and catch.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-browser pull request: CB-8182 - port 'cordova serve' to 'c...

2015-01-28 Thread jsoref

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-browser/pull/9#issuecomment-71878798
  
`cordova serve` is potentially usable by `cordova-android` or `cordova-ios` 
or `cordova-blackberry`, so, no, please don't just fork it or hand wave and 
pray that forcing people to use `cordova-browser` will somehow work.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-browser pull request: CB-8182 - port 'cordova serve' to 'c...

2015-01-28 Thread jsoref

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-browser/pull/9#issuecomment-71878896
  
Specifically, it in theory allows one to live(-ish) edit an application 
instead of constantly republishing it to the device.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-file-transfer pull request: CB-5059 Add a CookieMan...

2015-01-28 Thread dpogue

Github user dpogue commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/60#issuecomment-71879606
  
@agrieve Thanks, updated


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: [DISCUSS] Cordova-Android 4.0.0 Release

2015-01-28 Thread Murat Sutunc

I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and there are some 
failures. I’ve searched the jira for issues but wasn’t able to find any. Has 
anyone else ran into these issues before?

org.apache.cordova.contacts.tests.tests  Contacts (navigator.contacts) Round 
trip Contact tests (creating + save + delete + find). Contacts.spec.24 
Creating, saving, finding a contact should work, after which we should not be 
able to find it, and we should not be able to delete it again.
•   Expected 2 to be 1
•   Expected 1 to be 0
 it(contacts.spec.24 Creating, saving, finding a contact should work, 
removing it should work, after which we should not be able to find it, and we 
should not be able to delete it again., function (done) {
  // Save method is not supported on Windows platform
  if (isWindows) {
  pending();
  return;
  }
  if (isWindowsPhone8) {
  done();
  return;
  }
  gContactObj = new Contact();
  gContactObj.name = new ContactName();
  gContactObj.name.familyName = DeleteMe;
  gContactObj.save(function(c_obj) {
  var findWin = function(cs) {
  expect(cs.length).toBe(1);
  // update to have proper saved id
  gContactObj = cs[0];
  gContactObj.remove(function() {
  var findWinAgain = function(seas) {
  expect(seas.length).toBe(0);
  gContactObj.remove(function() {
  throw(success callback called after 
non-existent Contact object called remove(). Test failed.);
  }, function(e) {
  
expect(e.code).toBe(ContactError.UNKNOWN_ERROR);
  done();
  });
  };
  var findFailAgain = function(e) {
  throw(find error callback invoked after delete, 
test failed.);
  };
  var obj = new ContactFindOptions();
  obj.filter=DeleteMe;
  obj.multiple=true;
  navigator.contacts.find([displayName, name, 
phoneNumbers, emails], findWinAgain, findFailAgain, obj);
  }, function(e) {
  throw(Newly created contact's remove function 
invoked error callback. Test failed.);
  });
  };
  var findFail = fail;
  var obj = new ContactFindOptions();
  obj.filter=DeleteMe;
  obj.multiple=true;
  navigator.contacts.find([displayName, name, 
phoneNumbers, emails], findWin, findFail, obj);
  }, fail);
  });

org.apache.cordova.file.tests.test  file api filereader file.spec.81 
(couldn’t find a JIRA issue)
•   Expected `` to be null
describe('FileReader', function () {
it(file.spec.81 should have correct methods, function () {
var reader = new FileReader();
expect(reader).toBeDefined();
expect(typeof reader.readAsBinaryString).toBe('function');
expect(typeof reader.readAsDataURL).toBe('function');
expect(typeof reader.readAsText).toBe('function');
expect(typeof reader.readAsArrayBuffer).toBe('function');
expect(typeof reader.abort).toBe('function');
 test below fails 
   '' !== null
expect(reader.result).toBe(null); 
});
});

org.apache.cordova.file.tests.tests  file api parent references file.spec.111 
(couldn’t find a fire issue):
•   root.getFile succeeds, it is expected to fail.
var fileName = traverse.file.uri;
// create a new file entry
createFile(fileName, function (entry) {
// lookup file system entry
root.getFile('../' + fileName, {
create : false
}, succeed.bind(null, done, root.getFile('../+fileName+ 
')- Unexpected success callback, it should not traverse abvoe the root 
directory), 
function (error) { //.

org.apache.cordova.file-transfer.tests.tests  FileTransfer methods download 
filetransfer.spec.6 should get 401 status on http basic auth failure
•   Expected null to be 401
it('filetransfer.spec.6 should get 401 status on http basic 
auth failure', function (done) {

// NOTE:
//  using server without credentials
var fileURL = SERVER + '/download_basic_auth';

Re: [Proposal] Publishing plugins to NPM top level package.json for cordova projects

2015-01-28 Thread Michal Mocny

Thanks for putting this together Steve!  Gives us something concrete to
debate ;)

On Tue, Jan 27, 2015 at 7:17 PM, Steven Gill stevengil...@gmail.com wrote:

 Hey All,

 In preparation of the upcoming hangout this Thursday, here is my proposal
 on publishing plugins to npm (Phase 1) and adding a top level package.json
 into every cordova project (Phase 2).

 https://docs.google.com/document/d/1M0L4RHp8U6T_TZANaGz20RwLDulM1_iE56osU-o_bUU/edit?usp=sharing

 Looking forward to some feedback!

 -Steve

[GitHub] cordova-lib pull request: CB-8123 Plugin references can target spe...

2015-01-28 Thread purplecabbage

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-lib/pull/155#issuecomment-71907847
  
Very cool Tim!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova-Android 4.0.0 Release

On Wed, Jan 28, 2015 at 1:44 PM, Joe Bowser bows...@gmail.com wrote:

 On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve agri...@chromium.org
 wrote:

 
  - Make CordovaActivity not implement CordovaInterface, but instead
 provide
  CordovaInterface via an inner class (to solidify that you can't cast the
  activity to CordovaInterface and expect that to work - some used to do
 this
  but I think we've cleaned it all up now)
 
  This literally came out of nowhere.  Why are you trying so hard to remove
 the embedded view use case? What if someone is implementing an activity
 that inherits from another activity like MapActivity?  This API change came
 without any discussion.

I meant for this to be discussion. Certainly this is non-critical, but I
think it makes the embedded use-case easier not harder. Will do it in a PR
for review.



 All of this can be done in a few days, but I'd also like to see the dust
  settle a bit before going forward with 4.0.0 release. E.g. At least wait
  until we do a blog post for 3.7.0 (are you doing this?), and have done a
  tools release that updates the pinned version to 3.7.0
 
 
 If someone else wants to do the blog post on that, that's fine.  And I
 agree that there should be a tools release with 3.7.0 pinned, even though
 3.7.0 is really just a technicality so we can get 4.0.0 out IMO.


3.7.0 adds Lollipop support. That's pretty big! I won't have time to get to
it this week if there are any other takers?




 
  On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com wrote:
 
   Reminder: failures with plugins are not blockers.  I've run into that
   contact issue numerous times when testing with my personal device.  I
   recommend making sure that your contacts are completely clean so that
 you
   don't get these weird results.
  
   The file failures have been happening for quite a while, and those are
  not
   blockers for the platform release either.  Do these failures happen on
 a
   platform other than ICS?
  
   On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com
  wrote:
  
I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and there
  are
some failures. I’ve searched the jira for issues but wasn’t able to
  find
any. Has anyone else ran into these issues before?
   
org.apache.cordova.contacts.tests.tests  Contacts
  (navigator.contacts)
Round trip Contact tests (creating + save + delete + find).
Contacts.spec.24 Creating, saving, finding a contact should work,
 after
which we should not be able to find it, and we should not be able to
   delete
it again.
•   Expected 2 to be 1
•   Expected 1 to be 0
 it(contacts.spec.24 Creating, saving, finding a contact
  should
work, removing it should work, after which we should not be able to
  find
it, and we should not be able to delete it again., function (done) {
  // Save method is not supported on Windows platform
  if (isWindows) {
  pending();
  return;
  }
  if (isWindowsPhone8) {
  done();
  return;
  }
  gContactObj = new Contact();
  gContactObj.name = new ContactName();
  gContactObj.name.familyName = DeleteMe;
  gContactObj.save(function(c_obj) {
  var findWin = function(cs) {
  expect(cs.length).toBe(1);
  // update to have proper saved id
  gContactObj = cs[0];
  gContactObj.remove(function() {
  var findWinAgain = function(seas) {
  expect(seas.length).toBe(0);
  gContactObj.remove(function() {
  throw(success callback called
 after
non-existent Contact object called remove(). Test failed.);
  }, function(e) {
  expect(e.code).toBe(ContactErr
or.UNKNOWN_ERROR);
  done();
  });
  };
  var findFailAgain = function(e) {
  throw(find error callback invoked
 after
delete, test failed.);
  };
  var obj = new ContactFindOptions();
  obj.filter=DeleteMe;
  obj.multiple=true;
  navigator.contacts.find([displayName,
  name,
phoneNumbers, emails], findWinAgain, findFailAgain, obj);
  }, function(e) {
  throw(Newly created contact's remove
  function
invoked error callback. Test failed.);
  });

iOS 8.1.3

2015-01-28 Thread Edna Y Morales


Apple recently released a minor update (iOS 8.1.3). No issues were found on
Cordova. FYI

Thanks,
Edna Morales

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-01-28 Thread Steven Gill

I can do the tools release. Let's chat about it tomorrow at hangout.
On Jan 28, 2015 12:33 PM, Andrew Grieve agri...@chromium.org wrote:

 On Wed, Jan 28, 2015 at 1:44 PM, Joe Bowser bows...@gmail.com wrote:

  On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve agri...@chromium.org
  wrote:
 
  
   - Make CordovaActivity not implement CordovaInterface, but instead
  provide
   CordovaInterface via an inner class (to solidify that you can't cast
 the
   activity to CordovaInterface and expect that to work - some used to do
  this
   but I think we've cleaned it all up now)
  
   This literally came out of nowhere.  Why are you trying so hard to
 remove
  the embedded view use case? What if someone is implementing an activity
  that inherits from another activity like MapActivity?  This API change
 came
  without any discussion.
 
 I meant for this to be discussion. Certainly this is non-critical, but I
 think it makes the embedded use-case easier not harder. Will do it in a PR
 for review.


 
  All of this can be done in a few days, but I'd also like to see the dust
   settle a bit before going forward with 4.0.0 release. E.g. At least
 wait
   until we do a blog post for 3.7.0 (are you doing this?), and have done
 a
   tools release that updates the pinned version to 3.7.0
  
  
  If someone else wants to do the blog post on that, that's fine.  And I
  agree that there should be a tools release with 3.7.0 pinned, even though
  3.7.0 is really just a technicality so we can get 4.0.0 out IMO.
 

 3.7.0 adds Lollipop support. That's pretty big! I won't have time to get to
 it this week if there are any other takers?


 
 
  
   On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com
 wrote:
  
Reminder: failures with plugins are not blockers.  I've run into that
contact issue numerous times when testing with my personal device.  I
recommend making sure that your contacts are completely clean so that
  you
don't get these weird results.
   
The file failures have been happening for quite a while, and those
 are
   not
blockers for the platform release either.  Do these failures happen
 on
  a
platform other than ICS?
   
On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com
   wrote:
   
 I've ran the mobile-spec tests on android 4.0.3 with 4.0.x and
 there
   are
 some failures. I've searched the jira for issues but wasn't able to
   find
 any. Has anyone else ran into these issues before?

 org.apache.cordova.contacts.tests.tests  Contacts
   (navigator.contacts)
 Round trip Contact tests (creating + save + delete + find).
 Contacts.spec.24 Creating, saving, finding a contact should work,
  after
 which we should not be able to find it, and we should not be able
 to
delete
 it again.
 *   Expected 2 to be 1
 *   Expected 1 to be 0
  it(contacts.spec.24 Creating, saving, finding a contact
   should
 work, removing it should work, after which we should not be able to
   find
 it, and we should not be able to delete it again., function
 (done) {
   // Save method is not supported on Windows platform
   if (isWindows) {
   pending();
   return;
   }
   if (isWindowsPhone8) {
   done();
   return;
   }
   gContactObj = new Contact();
   gContactObj.name = new ContactName();
   gContactObj.name.familyName = DeleteMe;
   gContactObj.save(function(c_obj) {
   var findWin = function(cs) {
   expect(cs.length).toBe(1);
   // update to have proper saved id
   gContactObj = cs[0];
   gContactObj.remove(function() {
   var findWinAgain = function(seas) {
   expect(seas.length).toBe(0);
   gContactObj.remove(function() {
   throw(success callback called
  after
 non-existent Contact object called remove(). Test failed.);
   }, function(e) {
   expect(e.code).toBe(ContactErr
 or.UNKNOWN_ERROR);
   done();
   });
   };
   var findFailAgain = function(e) {
   throw(find error callback invoked
  after
 delete, test failed.);
   };
   var obj = new ContactFindOptions();
   obj.filter=DeleteMe;
   obj.multiple=true;
   navigator.contacts.find([displayName,
   name,

[GitHub] cordova-coho pull request: CB-8375 Improve windows support for for...

2015-01-28 Thread muratsu

GitHub user muratsu opened a pull request:

https://github.com/apache/cordova-coho/pull/62

CB-8375 Improve windows support for for-each

This improvement makes coho for-each work on Windows without issues. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-coho CB-8375

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-coho/pull/62.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #62


commit d1d8d687430292afd85e79a584f618cd28e265a8
Author: Murat Sutunc mura...@microsoft.com
Date:   2015-01-28T23:56:09Z

CB-8375 Improve windows support for for-each




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: So...can we merge 4.0.x into master yet?

Merged 4.0.x in.

On Mon, Jan 26, 2015 at 2:27 PM, Joe Bowser bows...@gmail.com wrote:

 Well, I think we NEED to support third-party WebViews as a first step.  If
 I don't hear any objections, I'm going to merge 4.0.x into master tomorrow,
 and start a discuss thread for the 4.0.x release.  I believe all we really
 need to do right now is make sure that the CookieManager issues are
 resolved (without a Factory please, we've gone 5 years without using that
 Java anti-pattern).

 As for the WebView, I don't want to inherit one, but at the same time I
 don't really want to rely on Intel and XWalk.  This is definitely an
 internal conversation that I'm sure is going on (or should be going on) at
 all our workplaces right now, and I'd be interested in hearing what
 people's thoughts are about having the One true WebView.

 On Mon Jan 26 2015 at 11:22:45 AM Marcel Kinard cmarc...@gmail.com
 wrote:

  I just read Adrian Ludwig's post on Plus, I now feel worse about Jelly
  Bean users. On one hand, we could communicate all over about loading only
  trusted content into the webview, but I think that will be ignored by a
 lot
  of devs. On the other hand, we could provide our own webview by default
 for
  4.0 and above. That would require we drop support for Gingerbread (which
  I'm not necessarily against), but also brings with it ownership of the
  webview and us delivering security patches for it. Or maybe by default
  prevent non-local content from being loaded into the webview. Sigh.
 
   On Jan 24, 2015, at 3:33 PM, Joe Bowser bows...@gmail.com wrote:
  
   More about WebKit and Jellybean not being updated. This is the same
 line
   we've been saying, but a lot of users have been completely
 disregarding.
   So, I don't know where we should go from here:
  
   https://plus.google.com/117193854832907724231/posts/1md7ruEwBLF
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-android pull request: CB-5059 Add a CookieManager abstract...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/151


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-android 4.0 JUnit tests

I'd prefer to go the other way, and change AndroidWebView to composition.
It's more flexible and does a better job of splitting up groups of APIs.

On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin ningxin...@intel.com wrote:

 Hi Joe,
 
  The tests don't work with Crosswalk because Crosswalk's main class
 doesn't
  inherit from a view.  This is why we had to change the CordovaWebView
  from being a class to being an Interface in the first place.  I don't
 think there is
  a way for these tests to work with Crosswalk because of this
 incompatibility.
  I don't think there is a way to re-use these tests because of this
 fundamental
  change.

 Crosswalk main class (XWalkView) actually inherits from a view (via
 FrameLayout). See
 https://crosswalk-project.org/apis/embeddingapidocs_v3/index.html

 I inspected the commit that changed the XWalkCordovaWebView from
 inheritance to composition (
 https://github.com/MobileChromeApps/cordova-crosswalk-engine/commit/26029ce8ae6d651a44a90222514cc6902ef8bb4a).
 The reason was some APIs of CordovaWebView interface (e.g. CanGoBack)
 conflict with XWalkView internal implementation at that time. And I
 remembered Ian and me thought CordovaWebView as an interface and
 compositing of webview probably was a good decouple solution.

 However, this changed in Crosswalk embedding API 3 (current version) that
 we separated the public interface and implementation. I briefly checked
 that the inheritance approach works with Crosswalk webview now.

 Folks, do you think we need to align all webview engines to inheritance
 pattern?

 Thanks,
 -ningxin

  On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei junwei...@intel.com wrote:
 
   Hi,
  
   I pulled cordova-android 4.0 branch, and running JUnit test in /test
   directory, but there are compiled error as below, and I want reuse the
   JUnit tests to test Crosswalk pluggable webView,  so I request a PR
   https://github.com/apache/cordova-android/pull/140, could someone
  help
   me to review and merge it.
  
   /test/menus.java:37: error: method registerForContextMenu in class
   Activity cannot be applied to given types;
   [javac] super.registerForContextMenu(super.appView);
   reason: actual argument CordovaWebView cannot be converted to View
  by
   method invocation conversion
  
   test/splashscreen.java:33: error: method loadUrl in class
   CordovaActivity cannot be applied to given types;
   [javac]
  super.loadUrl(file:///android_asset/www/splashscreen/index.html,
   2000);
   reason: actual and formal argument lists differ in length
  
   Thanks,
   Junwei.
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Build signed archives using CLI

2015-01-28 Thread Victor Sosa

Hi Andrew.

AFAICT, no one has done any work on this area, but I'd like to add this
topic to the hangout agenda, start discussing this. I think Subhag has a
very good design in the google doc in this thread. We can start from there
and try to make this happen for a future release.

Thoughts before adding it to the agenda?

2015-01-26 20:08 GMT-06:00 Andrew Grieve agri...@chromium.org:

In anyone interested in working on any of this?

Was just looking at it to see if there was anything I needed to do to add
support to Android for release packaging.

Main thing lacking to me is whether we should support specifying release
key information outside of the platforms/android directory. E.g. have a
cordova-keys.json as a sibling to www/ that has per-platform key locations
settings.

On Wed, Nov 5, 2014 at 3:15 PM, Victor Sosa sosah.vic...@gmail.com
wrote:

Hello Cordova community
Curious to know where we stand about this topic. Even though this topic
looks to have significant impact on Cordova, Subhag has a document
proposal
with little discussion activity.

I like Subhag's proposal, but I want to bring back the idea of a
prompt-less keychain.

Is anything else, besides what is depicted in the proposal, missing here?

Document:

https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNBL1auAMGFM/edit?usp=sharing

-- Forwarded message --
From: Carlos Santana csantan...@gmail.com
Date: 2014-10-15 12:42 GMT-05:00
Subject: Re: Build signed archives using CLI
To: dev@cordova.apache.org dev@cordova.apache.org

+1 on having a new command cordova package this will allow IBM tooling
to
hook into before_package and after_package for our own customizations
(direct update, authenticity, etc..)
+1 on using sane defaults and not prompting (i.e. default keychain maybe
used and unlock already) if not found what we need then prompt or fail
+1 have some config/settings outside platforms/ as I like to be
transient
replaceable. using config.xml, something.json, or file conventions like
res/packaging/platform/ are all ok options.

On Thu, Oct 9, 2014 at 5:16 PM, Subhag Oak subhag@microsoft.com
wrote:

Here is the link to the proposal:

https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNBL1auAMGFM/edit?usp=sharing
Jump on it people :)

Subhag Oak | Senior Program Manager
Visual Studio, Client Tools
s...@microsoft.com
425 707 5598 office

-Original Message-
From: Subhag Oak [mailto:subhag@microsoft.com]
Sent: Thursday, October 9, 2014 12:58 PM
To: dev@cordova.apache.org
Subject: RE: Build signed archives using CLI

Adding to what Shazron said, isn't config.xml supposed to be considered
as app-wide settings/properties? Typically packaging information is per
platform and hence in my opinion, should be decoupled from config
settings.
Jesse, I am working on a documentation that I will share out soon for
the
community to collaborate.

Subhag Oak | Senior Program Manager
Visual Studio, Client Tools
s...@microsoft.com
425 707 5598 office

-Original Message-
From: Shazron [mailto:shaz...@gmail.com]
Sent: Thursday, October 9, 2014 12:02 PM
To: dev@cordova.apache.org
Subject: Re: Build signed archives using CLI

Liking Subhag's proposal.
Agree with Jesse on using conventions as a default plus config.xml --
with
overrides/env-vars possible. The only caveat for including info in the
config.xml is, the config.xml data is copied into the iOS platform and
will
be included in the .app bundle, and will leak information (even though
harmless, since it shouldn't contain passwords, etc) -- so maybe that
is
not desirable, using config.xml.

We will need to provide the password each time at least for iOS, since
we
need to unlock the keychain for code signing.

On Thu, Oct 9, 2014 at 11:25 AM, Andrew Grieve agri...@chromium.org
wrote:

The prompting is actually pretty appropriate here since passwords are
involved I think. I think also that keys will often not be checked
into source control, but maybe the best way to support that is to
allow multiple ways of specifying things (e.g. default to convention,
allow override via config.xml, allow override via command-line env
variable as well)

On Thu, Oct 9, 2014 at 2:17 PM, Jesse purplecabb...@gmail.com
wrote:

I am liking all of this.
Are we ready to move this to an editable plaintext doc to
collaborate
on?

I agree that we should take advantage of as much 'by-convention' as
we
can,
meaning things like `cordova package ios` defaults to a code sign
identity
of 'iPhone Developer' and signs based on app-bundle-id, ...

If it does not make sense as a convention, then I too would like to
see
as
much as

Re: Cordova plugin namespace

I don't think the URL ever existed. XML namespace URLs don't need to
actually exist IIRC. They are just identifiers.

On Tue, Jan 27, 2015 at 6:07 PM, John M. Wargo j...@johnwargo.com wrote:

 Looking at the plugin guide at http://cordova.apache.org/
 docs/en/4.0.0/plugin_ref_spec.md.html the first sentence on the page
 refers to a Cordova Plugin Namespace page that no longer exists:
 http://apache.org/cordova/ns/plugins/1.0.

 Anyone know what happened to it?
 --

 *John M. Wargo*
 www.johnwargo.com

Re: File Transfer plugin and Crosswalk engine cookies

--webview=crosswalk sounds good. All it will do is add the plugin

On Tue, Jan 27, 2015 at 4:09 PM, Murat Sutunc mura...@microsoft.com wrote:

 What exactly would this flag do underneath? I suppose it will add the
 crosswalk plugin and run it's tests. Am I missing anything else?

  On Jan 27, 2015, at 12:29 PM, Jesse purplecabb...@gmail.com wrote:
 
  If you know there will be more, wouldn't it be simpler to just do
 something
  like :
  --webview=crosswalk // ?
 
  Just a small thing.
 
  @purplecabbage
  risingj.com
 
  On Tue, Jan 27, 2015 at 12:23 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
  I think that would be manageable. Especially since right now there is
 only
  1.
 
  On Tue, Jan 27, 2015 at 2:16 PM, Joe Bowser bows...@gmail.com wrote:
 
  I don't know if we want to do that, then we'd have to create flags for
  every potential third party webview.
 
  On Tue Jan 27 2015 at 7:03:28 AM Andrew Grieve agri...@chromium.org
  wrote:
 
  Sounds good. We should add a --crosswalk flag to createmobilespec.sh
 :)
 
  On Tue, Jan 27, 2015 at 2:07 AM, Hu, Ningxin ningxin...@intel.com
  wrote:
 
  Hi Joe,
 
 
  Crosswalk has its own release schedule, so it should have its own
  test
  project
  somewhere that tests the interfaces that it implements.  Of course,
  this
  would be similar to the ones that we still need to write for the
  AndroidWebView.  That said, I think for now we should proceed with
  the
  current tests and write the tests for 4.1.x
 
  This means that even if Crosswalk doesn't pass the JUnit tests, it
  still
  won't
  hold up the Cordova 4.0 release, because it's Crosswalk failing the
  tests, not
  Cordova itself.  Being independent and interoperable is good,
  since I
  anticipate Crosswalk to release much more quickly than Cordova.
 
  It makes sense.
 
  From crosswalk-engine testing perspective, let's:
  1. focus on mobile-spec integration test for Cordova 4.0 release
  2. maintain the JUnit test project independently and align with 4.1.x
  development
 
  Please let us know if there are anything missed.
 
  Thanks,
  -ningxin
 
 
  On Mon Jan 26 2015 at 10:14:11 PM Fu, Junwei junwei...@intel.com
  wrote:
 
  Crosswalk engine have been tested with mobile-spec and owned
  functionality test, but there are no JUnit test for Crosswalk
  engine,
  and the JUnit test in cordova-anroid 4.0 were being re-wrote.
  Does
  the
  Crosswalk engine need pass JUnit test before voting on releases?
  What's plan about making JUnit test cases to test pluggable
  webView.
 
  Thanks,
  Junwei.
 
  -Original Message-
  From: Joe Bowser [mailto:bows...@gmail.com]
  Sent: Tuesday, January 27, 2015 7:55 AM
  To: dev
  Subject: Re: File Transfer plugin and Crosswalk engine cookies
 
  As far as I'm aware, we're basically waiting for this to be done
  before starting the vote thread.  Does this code exist yet?
 
  On Tue Jan 20 2015 at 12:12:22 PM Andrew Grieve 
  agri...@chromium.org
  wrote:
 
  I was planning on doing exactly what Darryl described. Would
  love
  such a PR! Note that we've just used this approach for the new
  WebView security
  hooks:
 
  https://github.com/apache/cordova-android/commit/
  623b394c830b8a83b5c2f16624d8013b6f851cd9
  https://github.com/apache/cordova-android/commit/
  11002d4a56a4901087f514e2d01f8db392d0abe1
 
 
  CookieManager has been exposed to plugins for a long time, and
  it
  would be crippling if FileTransfer could not set cookies.
 
 
 
  On Tue, Jan 20, 2015 at 1:48 PM, Joe Bowser bows...@gmail.com
 
  wrote:
 
  I think we should make the File Transfer plugin not need a
  CookieManager.
  It sounds like that's the bigger problem than it having to be
  tied
  to a particular implementation of Cookies.
 
  On Tue Jan 20 2015 at 10:32:25 AM Darryl Pogue
  dvpdin...@gmail.com
  wrote:
 
  With the idea of preparing Cordova Android 4.0.x  for
  release
  starting to come up in discussions, I thought it was worth
  raising this as a potential blocker.
 
  The file transfer plugin uses the Android webview cookie
  manager.
  When you're using a Crosswalk webview (or GeckoView
  presumably),
  in the best case there are no cookies with file transfer
  requests and in the worst case it will cause the app to
  crash
  on
  Android
  4.2.x.
 
  There are a few existing bug reports and PRs related to
  this,
  but none of them propose a general solution for different
  webviews.
  [1] [2] [3] [4]
 
  I was looking at this problem last week and the only
  general
  solution I could think of would involve adding a
  CordovaCookieManager interface and implementing it for each
  webview engine, which didn't seem to be the most idea
  situation.
 
  I can write that interface and make a PR for it, but I'd
  rather
  hear if anyone has better ideas before starting to make
  changes
  across multiple repos.
 
 
  [1]:
  https://github.com/crosswalk-project/crosswalk-cordova-
  android/pull/38
  [2]:
  https://github.com/apache/cordova-plugin-file-transfer/pull/8

RE: cordova-android 4.0 JUnit tests

2015-01-28 Thread Hu, Ningxin

Hi Joe,

I have never seen an example of Crosswalk using Android XML layouts, and
as far as I'm currently aware, embedding Crosswalk is less straightforward
than embedding AndroidWebView or MozillaWebView.

Is this what you are looking for?
https://github.com/crosswalk-project/crosswalk/blob/master/runtime/android/core_shell/res/layout/fragment_main.xml#L11

Thanks,
-ningxin

On Wed Jan 28 2015 at 10:07:18 AM Andrew Grieve agri...@chromium.org
wrote:

You can still embed a view using composition. We are not providing any
backwards compatibility right now, even with inheritance, because
CordovaWebView is no longer a View (it's an interface, which requires
an explicit cast to (View), or a call to .getView() to be considered
as a
View)

On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser bows...@gmail.com
wrote:

I completely disagree, and think we should go the inheritance pattern.
The
reason for that is that we have to provide backwards compatibility
for
some
views where the implementation is a view, and there's no dual
inheritance in Java, which is the only way that I can see us
accommodating both types of implementations. If we didn't already
have users embedding CordovaWebView (and seriously guys, if you're
reading this, please don't keep leaving me hanging here, I want you
to step up into this conversation). Also, other views, such as the
prototype MozillaView
that I
worked on, are implemented so that they inherit from a view.

Just because it may offer some us some flexibility doesn't mean that
it's worth taking away an entire feature from other users. My most
popular repository after Cordova itself is the example where I show
how to embed
a
CordovaWebView, so people have been using this feature.

On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve
agri...@chromium.org
wrote:

I'd prefer to go the other way, and change AndroidWebView to
composition.
It's more flexible and does a better job of splitting up groups of
APIs.

On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin
ningxin...@intel.com
wrote:

Hi Joe,

The tests don't work with Crosswalk because Crosswalk's main
class
doesn't
inherit from a view. This is why we had to change the
CordovaWebView
from being a class to being an Interface in the first place.
I
don't
think there is
a way for these tests to work with Crosswalk because of this
incompatibility.
I don't think there is a way to re-use these tests because of
this
fundamental
change.

Crosswalk main class (XWalkView) actually inherits from a view
(via FrameLayout). See
https://crosswalk-project.org/apis/embeddingapidocs_v3/index.htm
l

I inspected the commit that changed the XWalkCordovaWebView
from
inheritance to composition (
https://github.com/MobileChromeApps/cordova-crosswalk-
engine/com
mit/
26029ce8ae6d651a44a90222514cc6902ef8bb4a).
The reason was some APIs of CordovaWebView interface (e.g.
CanGoBack) conflict with XWalkView internal implementation at
that time. And I remembered Ian and me thought CordovaWebView
as
an interface and compositing of webview probably was a good
decouple solution.

However, this changed in Crosswalk embedding API 3 (current
version)
that
we separated the public interface and implementation. I briefly
checked
that the inheritance approach works with Crosswalk webview now.

Folks, do you think we need to align all webview engines to
inheritance
pattern?

Thanks,
-ningxin

On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei
junwei...@intel.com
wrote:

Hi,

I pulled cordova-android 4.0 branch, and running JUnit test
in
/test
directory, but there are compiled error as below, and I want
reuse
the
JUnit tests to test Crosswalk pluggable webView, so I
request a
PR
https://github.com/apache/cordova-android/pull/140, could
someone
help
me to review and merge it.

/test/menus.java:37: error: method registerForContextMenu in
class
Activity cannot be applied to given types;
[javac] super.registerForContextMenu(super.appView);
reason: actual argument CordovaWebView cannot be converted
to
View
by
method invocation conversion

test/splashscreen.java:33: error: method loadUrl in class
CordovaActivity cannot be applied to given types;
[javac]
super.loadUrl(file:///android_asset/www/splashscreen/index.ht
ml,
2000);
reason: actual and formal argument lists differ in length

Thanks,
Junwei.

-
To unsubscribe,

Re: cordova-android 4.0 JUnit tests

That's part of it.  What's the setup code for that look like?

On Wed Jan 28 2015 at 7:15:10 PM Hu, Ningxin ningxin...@intel.com wrote:

 Hi Joe,
 
  I have never seen an example of Crosswalk using Android XML layouts, and
  as far as I'm currently aware, embedding Crosswalk is less
 straightforward
  than embedding AndroidWebView or MozillaWebView.
 

 Is this what you are looking for? https://github.com/crosswalk-
 project/crosswalk/blob/master/runtime/android/core_shell/
 res/layout/fragment_main.xml#L11

 Thanks,
 -ningxin

  On Wed Jan 28 2015 at 10:07:18 AM Andrew Grieve agri...@chromium.org
  wrote:
 
   You can still embed a view using composition. We are not providing any
   backwards compatibility right now, even with inheritance, because
   CordovaWebView is no longer a View (it's an interface, which requires
   an explicit cast to (View), or a call to .getView() to be considered
   as a
   View)
  
   On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser bows...@gmail.com
  wrote:
  
I completely disagree, and think we should go the inheritance
 pattern.
   The
reason for that is that we have to provide backwards compatibility
for
   some
views where the implementation is a view, and there's no dual
inheritance in Java, which is the only way that I can see us
accommodating both types of implementations.  If we didn't already
have users embedding CordovaWebView (and seriously guys, if you're
reading this, please don't keep leaving me hanging here, I want you
to step up into this conversation).  Also, other views, such as the
prototype MozillaView
   that I
worked on, are implemented so that they inherit from a view.
   
Just because it may offer some us some flexibility doesn't mean that
it's worth taking away an entire feature from other users.  My most
popular repository after Cordova itself is the example where I show
how to embed
   a
CordovaWebView, so people have been using this feature.
   
On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve
agri...@chromium.org
wrote:
   
 I'd prefer to go the other way, and change AndroidWebView to
   composition.
 It's more flexible and does a better job of splitting up groups of
   APIs.

 On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin
 ningxin...@intel.com
 wrote:

  Hi Joe,
  
   The tests don't work with Crosswalk because Crosswalk's main
   class
  doesn't
   inherit from a view.  This is why we had to change the
   CordovaWebView
   from being a class to being an Interface in the first place.
   I
   don't
  think there is
   a way for these tests to work with Crosswalk because of this
  incompatibility.
   I don't think there is a way to re-use these tests because of
   this
  fundamental
   change.
 
  Crosswalk main class (XWalkView) actually inherits from a view
  (via FrameLayout). See
  https://crosswalk-project.org/apis/embeddingapidocs_v3/index.htm
  l
 
  I inspected the commit that changed the XWalkCordovaWebView
  from
  inheritance to composition (
  https://github.com/MobileChromeApps/cordova-crosswalk-
  engine/com
  mit/
 26029ce8ae6d651a44a90222514cc6902ef8bb4a).
  The reason was some APIs of CordovaWebView interface (e.g.
  CanGoBack) conflict with XWalkView internal implementation at
  that time. And I remembered Ian and me thought CordovaWebView
  as
  an interface and compositing of webview probably was a good
  decouple solution.
 
  However, this changed in Crosswalk embedding API 3 (current
  version)
that
  we separated the public interface and implementation. I briefly
   checked
  that the inheritance approach works with Crosswalk webview now.
 
  Folks, do you think we need to align all webview engines to
   inheritance
  pattern?
 
  Thanks,
  -ningxin
 
   On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei
   junwei...@intel.com
 wrote:
  
Hi,
   
I pulled cordova-android 4.0 branch, and running JUnit test
in
/test
directory, but there are compiled error as below, and I want
   reuse
 the
JUnit tests to test Crosswalk pluggable webView,  so I
request a
   PR
https://github.com/apache/cordova-android/pull/140, could
   someone
   help
me to review and merge it.
   
/test/menus.java:37: error: method registerForContextMenu in
   class
Activity cannot be applied to given types;
[javac] super.registerForContextMenu(
 super.appView);
reason: actual argument CordovaWebView cannot be converted
to
   View
   by
method invocation conversion
   
test/splashscreen.java:33: error: method loadUrl in class
CordovaActivity cannot be applied to given types;
[javac]

Browserify what's left proposal

2015-01-28 Thread Steven Gill

Sorry for sending this out so late. We can review it together during the
hangout tomorrow.

https://docs.google.com/document/d/14rZxM0Dj4z7Q9UwcnV6tIkLrUSaM17INnmVshuY_oMU/edit?usp=sharing

RE: Build signed archives using CLI

2015-01-28 Thread Chuck Lantz

Dan Levine whom some of you met at PhoneGap day actually has been working on a 
PR based on Subhag's proposal for discussion - he is out sick which is why he 
didn't respond to this thread. I'll let him speak to it once he's back but the 
good news is there is someone working on something in this area.

-Chuck

-Original Message-
From: Victor Sosa [mailto:sosah.vic...@gmail.com] 
Sent: Wednesday, January 28, 2015 7:57 AM
To: dev@cordova.apache.org
Subject: Re: Build signed archives using CLI

Hi Andrew.

AFAICT, no one has done any work on this area, but I'd like to add this topic 
to the hangout agenda, start discussing this. I think Subhag has a very good 
design in the google doc in this thread. We can start from there and try to 
make this happen for a future release.

Thoughts before adding it to the agenda?

2015-01-26 20:08 GMT-06:00 Andrew Grieve agri...@chromium.org:

 In anyone interested in working on any of this?

 Was just looking at it to see if there was anything I needed to do to 
 add support to Android for release packaging.

 Main thing lacking to me is whether we should support specifying 
 release key information outside of the platforms/android directory. 
 E.g. have a cordova-keys.json as a sibling to www/ that has 
 per-platform key locations  settings.

 On Wed, Nov 5, 2014 at 3:15 PM, Victor Sosa sosah.vic...@gmail.com
 wrote:

  Hello Cordova community
  Curious to know where we stand about this topic. Even though this 
  topic looks to have significant impact on Cordova, Subhag has a 
  document
 proposal
  with little discussion activity.
 
  I like Subhag's proposal, but I want to bring back the idea of a 
  prompt-less keychain.
 
  Is anything else, besides what is depicted in the proposal, missing here?
 
  Document:
 
 
 https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
 L1auAMGFM/edit?usp=sharing
 
 
  -- Forwarded message --
  From: Carlos Santana csantan...@gmail.com
  Date: 2014-10-15 12:42 GMT-05:00
  Subject: Re: Build signed archives using CLI
  To: dev@cordova.apache.org dev@cordova.apache.org
 
 
  +1 on having a new command cordova package this will allow IBM 
  +tooling
 to
  hook into before_package and after_package for our own 
  customizations (direct update, authenticity, etc..)
  +1 on using sane defaults and not prompting (i.e. default keychain 
  +maybe
  used and unlock already) if not found what we need then prompt or 
  fail
  +1 have some config/settings outside platforms/ as I like to be
 transient
  replaceable. using config.xml, something.json, or file conventions 
  like res/packaging/platform/  are all ok options.
 
 
  On Thu, Oct 9, 2014 at 5:16 PM, Subhag Oak 
  subhag@microsoft.com
  wrote:
 
   Here is the link to the proposal:
  
 
 
 https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
 L1auAMGFM/edit?usp=sharing
   Jump on it people :)
  
   Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools 
   s...@microsoft.com
   425 707 5598 office
  
   -Original Message-
   From: Subhag Oak [mailto:subhag@microsoft.com]
   Sent: Thursday, October 9, 2014 12:58 PM
   To: dev@cordova.apache.org
   Subject: RE: Build signed archives using CLI
  
   Adding to what Shazron said, isn't config.xml supposed to be 
   considered as app-wide settings/properties? Typically packaging 
   information is per platform and hence in my opinion, should be 
   decoupled from config
  settings.
   Jesse, I am working on a documentation that I will share out  soon 
   for
  the
   community to collaborate.
  
   Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools 
   s...@microsoft.com
   425 707 5598 office
  
   -Original Message-
   From: Shazron [mailto:shaz...@gmail.com]
   Sent: Thursday, October 9, 2014 12:02 PM
   To: dev@cordova.apache.org
   Subject: Re: Build signed archives using CLI
  
   Liking Subhag's proposal.
   Agree with Jesse on using conventions as a default plus config.xml 
   --
  with
   overrides/env-vars possible. The only caveat for including info in 
   the config.xml is, the config.xml data is copied into the iOS 
   platform and
  will
   be included in the .app bundle, and will leak information (even 
   though harmless, since it shouldn't contain passwords, etc) -- so 
   maybe that
 is
   not desirable, using config.xml.
  
   We will need to provide the password each time at least for iOS, 
   since
 we
   need to unlock the keychain for code signing.
  
  
  
  
  
  
  
  
   On Thu, Oct 9, 2014 at 11:25 AM, Andrew Grieve 
   agri...@chromium.org
   wrote:
  
The prompting is actually pretty appropriate here since 
passwords are involved I think. I think also that keys will 
often not be checked into source control, but maybe the best way 
to support that is to allow multiple ways of specifying things 
(e.g. default to convention, allow override via config.xml, 
allow override via command-line

Re: Build signed archives using CLI

2015-01-28 Thread Victor Sosa

Yay!! Great news!

Chuck, by any chance, do you have a link to the sandbox, or design doc or
something worth to look at it? If no, we can wait until Dan is back (hope
he feels better soon)
I'm happy to help if needed.

2015-01-28 10:05 GMT-06:00 Chuck Lantz cla...@microsoft.com:

 Dan Levine whom some of you met at PhoneGap day actually has been working
 on a PR based on Subhag's proposal for discussion - he is out sick which is
 why he didn't respond to this thread. I'll let him speak to it once he's
 back but the good news is there is someone working on something in this
 area.

 -Chuck

 -Original Message-
 From: Victor Sosa [mailto:sosah.vic...@gmail.com]
 Sent: Wednesday, January 28, 2015 7:57 AM
 To: dev@cordova.apache.org
 Subject: Re: Build signed archives using CLI

 Hi Andrew.

 AFAICT, no one has done any work on this area, but I'd like to add this
 topic to the hangout agenda, start discussing this. I think Subhag has a
 very good design in the google doc in this thread. We can start from there
 and try to make this happen for a future release.

 Thoughts before adding it to the agenda?

 2015-01-26 20:08 GMT-06:00 Andrew Grieve agri...@chromium.org:

  In anyone interested in working on any of this?
 
  Was just looking at it to see if there was anything I needed to do to
  add support to Android for release packaging.
 
  Main thing lacking to me is whether we should support specifying
  release key information outside of the platforms/android directory.
  E.g. have a cordova-keys.json as a sibling to www/ that has
  per-platform key locations  settings.
 
  On Wed, Nov 5, 2014 at 3:15 PM, Victor Sosa sosah.vic...@gmail.com
  wrote:
 
   Hello Cordova community
   Curious to know where we stand about this topic. Even though this
   topic looks to have significant impact on Cordova, Subhag has a
   document
  proposal
   with little discussion activity.
  
   I like Subhag's proposal, but I want to bring back the idea of a
   prompt-less keychain.
  
   Is anything else, besides what is depicted in the proposal, missing
 here?
  
   Document:
  
  
  https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
  L1auAMGFM/edit?usp=sharing
  
  
   -- Forwarded message --
   From: Carlos Santana csantan...@gmail.com
   Date: 2014-10-15 12:42 GMT-05:00
   Subject: Re: Build signed archives using CLI
   To: dev@cordova.apache.org dev@cordova.apache.org
  
  
   +1 on having a new command cordova package this will allow IBM
   +tooling
  to
   hook into before_package and after_package for our own
   customizations (direct update, authenticity, etc..)
   +1 on using sane defaults and not prompting (i.e. default keychain
   +maybe
   used and unlock already) if not found what we need then prompt or
   fail
   +1 have some config/settings outside platforms/ as I like to be
  transient
   replaceable. using config.xml, something.json, or file conventions
   like res/packaging/platform/  are all ok options.
  
  
   On Thu, Oct 9, 2014 at 5:16 PM, Subhag Oak
   subhag@microsoft.com
   wrote:
  
Here is the link to the proposal:
   
  
  
  https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
  L1auAMGFM/edit?usp=sharing
Jump on it people :)
   
Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools
s...@microsoft.com
425 707 5598 office
   
-Original Message-
From: Subhag Oak [mailto:subhag@microsoft.com]
Sent: Thursday, October 9, 2014 12:58 PM
To: dev@cordova.apache.org
Subject: RE: Build signed archives using CLI
   
Adding to what Shazron said, isn't config.xml supposed to be
considered as app-wide settings/properties? Typically packaging
information is per platform and hence in my opinion, should be
decoupled from config
   settings.
Jesse, I am working on a documentation that I will share out  soon
for
   the
community to collaborate.
   
Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools
s...@microsoft.com
425 707 5598 office
   
-Original Message-
From: Shazron [mailto:shaz...@gmail.com]
Sent: Thursday, October 9, 2014 12:02 PM
To: dev@cordova.apache.org
Subject: Re: Build signed archives using CLI
   
Liking Subhag's proposal.
Agree with Jesse on using conventions as a default plus config.xml
--
   with
overrides/env-vars possible. The only caveat for including info in
the config.xml is, the config.xml data is copied into the iOS
platform and
   will
be included in the .app bundle, and will leak information (even
though harmless, since it shouldn't contain passwords, etc) -- so
maybe that
  is
not desirable, using config.xml.
   
We will need to provide the password each time at least for iOS,
since
  we
need to unlock the keychain for code signing.
   
   
   
   
   
   
   
   
On Thu, Oct 9, 2014 at 11:25 AM, Andrew Grieve

[GitHub] cordova-plugin-file-transfer pull request: CB-5059 Add a CookieMan...

2015-01-28 Thread agrieve

Github user agrieve commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/60#discussion_r23698327
  
--- Diff: src/android/FileTransfer.java ---
@@ -316,7 +316,7 @@ public void run() {
 conn.setRequestProperty(Content-Type, 
multipart/form-data; boundary= + BOUNDARY);
 
 // Set the cookies on the response
-String cookie = 
CookieManager.getInstance().getCookie(target);
+String cookie = 
webView.getCookieManager().getCookie(target);
--- End diff --

I think we'll need to use reflection here to keep the plugin compatible 
with 3.x versions of android.

e.g.: Look at how getPluginManager() is handled on line 854.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: So...can we merge 4.0.x into master yet?

Cool.  I'll start the discuss thread.

On Wed Jan 28 2015 at 7:05:17 AM Andrew Grieve agri...@chromium.org wrote:

 Merged 4.0.x in.

 On Mon, Jan 26, 2015 at 2:27 PM, Joe Bowser bows...@gmail.com wrote:

  Well, I think we NEED to support third-party WebViews as a first step.
 If
  I don't hear any objections, I'm going to merge 4.0.x into master
 tomorrow,
  and start a discuss thread for the 4.0.x release.  I believe all we
 really
  need to do right now is make sure that the CookieManager issues are
  resolved (without a Factory please, we've gone 5 years without using that
  Java anti-pattern).
 
  As for the WebView, I don't want to inherit one, but at the same time I
  don't really want to rely on Intel and XWalk.  This is definitely an
  internal conversation that I'm sure is going on (or should be going on)
 at
  all our workplaces right now, and I'd be interested in hearing what
  people's thoughts are about having the One true WebView.
 
  On Mon Jan 26 2015 at 11:22:45 AM Marcel Kinard cmarc...@gmail.com
  wrote:
 
   I just read Adrian Ludwig's post on Plus, I now feel worse about Jelly
   Bean users. On one hand, we could communicate all over about loading
 only
   trusted content into the webview, but I think that will be ignored by a
  lot
   of devs. On the other hand, we could provide our own webview by default
  for
   4.0 and above. That would require we drop support for Gingerbread
 (which
   I'm not necessarily against), but also brings with it ownership of the
   webview and us delivering security patches for it. Or maybe by default
   prevent non-local content from being loaded into the webview. Sigh.
  
On Jan 24, 2015, at 3:33 PM, Joe Bowser bows...@gmail.com wrote:
   
More about WebKit and Jellybean not being updated. This is the same
  line
we've been saying, but a lot of users have been completely
  disregarding.
So, I don't know where we should go from here:
   
https://plus.google.com/117193854832907724231/posts/1md7ruEwBLF
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] Cordova-Android 4.0.0 Release

Hey

So, it's finally here.  I want to see us work more on Pluggable Webviews,
and adding the API, but I think it's time that we released what we've been
working on for almost a year to our users.  I know that the API isn't
exactly the most awesome we can make it, but it works, and I'd rather have
it out at 80% than it sitting for a few more months in limbo.

Are there any major blocking tasks that would prevent a vote thread that
anyone knows about, or should we start firing up a release?  I don't think
we're going to make our January date, but the first week of February isn't
that terrible.

Thoughts?

Joe

[GitHub] cordova-blackberry pull request: CB-6418 Remove copyright statemen...

2015-01-28 Thread jsoref

GitHub user jsoref opened a pull request:

https://github.com/apache/cordova-blackberry/pull/181

CB-6418 Remove copyright statements



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jsoref/cordova-blackberry cb_6418

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-blackberry/pull/181.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #181


commit 84f8f5d3eb097c1e383374201d183ceceacc292c
Author: Josh Soref jso...@blackberry.com
Date:   2015-01-28T16:29:44Z

CB-6418 Remove copyright statements




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova-Android 4.0.0 Release

2015-01-28 Thread Josh Bavari

Joe and team,

I work for Ionic and I've had some involvement with the Cordova project
since last year. At Ionic, we've released a Crosswalk build using Cordova
Android 4.0 so we can use the cordova crosswalk engine for the ionic
platform.

I've been working with Ian and Andrew on this to gather more understanding
and to get some help along the way. I must say, excellent work, everyone.

As such, we've accumulated quite a bit of users who are actively using
Cordova Android 4.0. Currently, we've had over 10k test trials with it, and
I'm happy to say, mostly it's been smooth.

What I've done is made a fork to adjust a few small things, but for the
most part, we're using 4.0.

I'd love to provide any more feedback that you'd wish.

Thanks again for the awesome work.

On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com wrote:

 Hey

 So, it's finally here.  I want to see us work more on Pluggable Webviews,
 and adding the API, but I think it's time that we released what we've been
 working on for almost a year to our users.  I know that the API isn't
 exactly the most awesome we can make it, but it works, and I'd rather have
 it out at 80% than it sitting for a few more months in limbo.

 Are there any major blocking tasks that would prevent a vote thread that
 anyone knows about, or should we start firing up a release?  I don't think
 we're going to make our January date, but the first week of February isn't
 that terrible.

 Thoughts?

 Joe




-- 
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com

[GitHub] cordova-blackberry pull request: CB-6418 Remove copyright statemen...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-blackberry/pull/181


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Build signed archives using CLI

Sounds good, let's wait until Dan is back to discuss. The main point I'd
like to cover is whether it'd be good to have layer of indirection between
cordova and the platform-specific files that dictate signing info.

E.g.:
Instead of using ant.properties / gradle.properties / build.xcconfig, have:

cordova-keys.json
 {
ios: { identity: , provisioning_profile:  },
android-debug: { keystore: , alias: , password: , type:  },
android-release: { keystore: , alias: , password: , type:  }
...
}

Then, have a prepare step that makes the platforms do the right thing

(Note that for android it's important to have debug siging keys as well
since they are used for Play Services and Cloud Console APIs).






On Wed, Jan 28, 2015 at 11:29 AM, Victor Sosa sosah.vic...@gmail.com
wrote:

 Yay!! Great news!

 Chuck, by any chance, do you have a link to the sandbox, or design doc or
 something worth to look at it? If no, we can wait until Dan is back (hope
 he feels better soon)
 I'm happy to help if needed.

 2015-01-28 10:05 GMT-06:00 Chuck Lantz cla...@microsoft.com:

  Dan Levine whom some of you met at PhoneGap day actually has been working
  on a PR based on Subhag's proposal for discussion - he is out sick which
 is
  why he didn't respond to this thread. I'll let him speak to it once he's
  back but the good news is there is someone working on something in this
  area.
 
  -Chuck
 
  -Original Message-
  From: Victor Sosa [mailto:sosah.vic...@gmail.com]
  Sent: Wednesday, January 28, 2015 7:57 AM
  To: dev@cordova.apache.org
  Subject: Re: Build signed archives using CLI
 
  Hi Andrew.
 
  AFAICT, no one has done any work on this area, but I'd like to add this
  topic to the hangout agenda, start discussing this. I think Subhag has a
  very good design in the google doc in this thread. We can start from
 there
  and try to make this happen for a future release.
 
  Thoughts before adding it to the agenda?
 
  2015-01-26 20:08 GMT-06:00 Andrew Grieve agri...@chromium.org:
 
   In anyone interested in working on any of this?
  
   Was just looking at it to see if there was anything I needed to do to
   add support to Android for release packaging.
  
   Main thing lacking to me is whether we should support specifying
   release key information outside of the platforms/android directory.
   E.g. have a cordova-keys.json as a sibling to www/ that has
   per-platform key locations  settings.
  
   On Wed, Nov 5, 2014 at 3:15 PM, Victor Sosa sosah.vic...@gmail.com
   wrote:
  
Hello Cordova community
Curious to know where we stand about this topic. Even though this
topic looks to have significant impact on Cordova, Subhag has a
document
   proposal
with little discussion activity.
   
I like Subhag's proposal, but I want to bring back the idea of a
prompt-less keychain.
   
Is anything else, besides what is depicted in the proposal, missing
  here?
   
Document:
   
   
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
   L1auAMGFM/edit?usp=sharing
   
   
-- Forwarded message --
From: Carlos Santana csantan...@gmail.com
Date: 2014-10-15 12:42 GMT-05:00
Subject: Re: Build signed archives using CLI
To: dev@cordova.apache.org dev@cordova.apache.org
   
   
+1 on having a new command cordova package this will allow IBM
+tooling
   to
hook into before_package and after_package for our own
customizations (direct update, authenticity, etc..)
+1 on using sane defaults and not prompting (i.e. default keychain
+maybe
used and unlock already) if not found what we need then prompt or
fail
+1 have some config/settings outside platforms/ as I like to be
   transient
replaceable. using config.xml, something.json, or file conventions
like res/packaging/platform/  are all ok options.
   
   
On Thu, Oct 9, 2014 at 5:16 PM, Subhag Oak
subhag@microsoft.com
wrote:
   
 Here is the link to the proposal:

   
   
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
   L1auAMGFM/edit?usp=sharing
 Jump on it people :)

 Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools
 s...@microsoft.com
 425 707 5598 office

 -Original Message-
 From: Subhag Oak [mailto:subhag@microsoft.com]
 Sent: Thursday, October 9, 2014 12:58 PM
 To: dev@cordova.apache.org
 Subject: RE: Build signed archives using CLI

 Adding to what Shazron said, isn't config.xml supposed to be
 considered as app-wide settings/properties? Typically packaging
 information is per platform and hence in my opinion, should be
 decoupled from config
settings.
 Jesse, I am working on a documentation that I will share out  soon
 for
the
 community to collaborate.

 Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools
 s...@microsoft.com
 425 707 5598

Re: Build signed archives using CLI

2015-01-28 Thread Darryl Pogue

One issue we've run into on iOS is that the xcconfig specifies iPhone
Developer by default, and for release builds that needs to be iPhone
Distribution.

We ended up using a before_compile JS hook to check if we're building
with --release and modify the xcconfig:
https://gist.github.com/dpogue/8ed1945c7464b448820e

On 28 January 2015 at 10:17, Andrew Grieve agri...@chromium.org wrote:
 Sounds good, let's wait until Dan is back to discuss. The main point I'd
 like to cover is whether it'd be good to have layer of indirection between
 cordova and the platform-specific files that dictate signing info.

 E.g.:
 Instead of using ant.properties / gradle.properties / build.xcconfig, have:

 cordova-keys.json
  {
 ios: { identity: , provisioning_profile:  },
 android-debug: { keystore: , alias: , password: , type:  },
 android-release: { keystore: , alias: , password: , type:  }
 ...
 }

 Then, have a prepare step that makes the platforms do the right thing

 (Note that for android it's important to have debug siging keys as well
 since they are used for Play Services and Cloud Console APIs).






 On Wed, Jan 28, 2015 at 11:29 AM, Victor Sosa sosah.vic...@gmail.com
 wrote:

 Yay!! Great news!

 Chuck, by any chance, do you have a link to the sandbox, or design doc or
 something worth to look at it? If no, we can wait until Dan is back (hope
 he feels better soon)
 I'm happy to help if needed.

 2015-01-28 10:05 GMT-06:00 Chuck Lantz cla...@microsoft.com:

  Dan Levine whom some of you met at PhoneGap day actually has been working
  on a PR based on Subhag's proposal for discussion - he is out sick which
 is
  why he didn't respond to this thread. I'll let him speak to it once he's
  back but the good news is there is someone working on something in this
  area.
 
  -Chuck
 
  -Original Message-
  From: Victor Sosa [mailto:sosah.vic...@gmail.com]
  Sent: Wednesday, January 28, 2015 7:57 AM
  To: dev@cordova.apache.org
  Subject: Re: Build signed archives using CLI
 
  Hi Andrew.
 
  AFAICT, no one has done any work on this area, but I'd like to add this
  topic to the hangout agenda, start discussing this. I think Subhag has a
  very good design in the google doc in this thread. We can start from
 there
  and try to make this happen for a future release.
 
  Thoughts before adding it to the agenda?
 
  2015-01-26 20:08 GMT-06:00 Andrew Grieve agri...@chromium.org:
 
   In anyone interested in working on any of this?
  
   Was just looking at it to see if there was anything I needed to do to
   add support to Android for release packaging.
  
   Main thing lacking to me is whether we should support specifying
   release key information outside of the platforms/android directory.
   E.g. have a cordova-keys.json as a sibling to www/ that has
   per-platform key locations  settings.
  
   On Wed, Nov 5, 2014 at 3:15 PM, Victor Sosa sosah.vic...@gmail.com
   wrote:
  
Hello Cordova community
Curious to know where we stand about this topic. Even though this
topic looks to have significant impact on Cordova, Subhag has a
document
   proposal
with little discussion activity.
   
I like Subhag's proposal, but I want to bring back the idea of a
prompt-less keychain.
   
Is anything else, besides what is depicted in the proposal, missing
  here?
   
Document:
   
   
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
   L1auAMGFM/edit?usp=sharing
   
   
-- Forwarded message --
From: Carlos Santana csantan...@gmail.com
Date: 2014-10-15 12:42 GMT-05:00
Subject: Re: Build signed archives using CLI
To: dev@cordova.apache.org dev@cordova.apache.org
   
   
+1 on having a new command cordova package this will allow IBM
+tooling
   to
hook into before_package and after_package for our own
customizations (direct update, authenticity, etc..)
+1 on using sane defaults and not prompting (i.e. default keychain
+maybe
used and unlock already) if not found what we need then prompt or
fail
+1 have some config/settings outside platforms/ as I like to be
   transient
replaceable. using config.xml, something.json, or file conventions
like res/packaging/platform/  are all ok options.
   
   
On Thu, Oct 9, 2014 at 5:16 PM, Subhag Oak
subhag@microsoft.com
wrote:
   
 Here is the link to the proposal:

   
   
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNB
   L1auAMGFM/edit?usp=sharing
 Jump on it people :)

 Subhag Oak  |  Senior Program Manager Visual Studio, Client Tools
 s...@microsoft.com
 425 707 5598 office

 -Original Message-
 From: Subhag Oak [mailto:subhag@microsoft.com]
 Sent: Thursday, October 9, 2014 12:58 PM
 To: dev@cordova.apache.org
 Subject: RE: Build signed archives using CLI

 Adding to what Shazron said, isn't config.xml supposed to be

RE: Build signed archives using CLI

2015-01-28 Thread Chuck Lantz

Yeah personally I am thinking that - particularly if we treat platforms as 
dependencies in package.json as proposed - we'll need some facility to set 
native build settings. We may be able to come up with some sort of abstraction 
for this part, but I'm kind of thinking we'll ultimately want a facility to 
include native build property files (ant/gradle.properties, things like the 
signing identity in build.xcconfig, etc) in the CLI project.  That said, we 
could have another facility for common settings like certs.

-Chuck

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Wednesday, January 28, 2015 10:18 AM
To: dev
Subject: Re: Build signed archives using CLI

Sounds good, let's wait until Dan is back to discuss. The main point I'd like 
to cover is whether it'd be good to have layer of indirection between cordova 
and the platform-specific files that dictate signing info.

E.g.:
Instead of using ant.properties / gradle.properties / build.xcconfig, have:

cordova-keys.json
 {
ios: { identity: , provisioning_profile:  },
android-debug: { keystore: , alias: , password: , type:  },
android-release: { keystore: , alias: , password: , type:  }
...
}

Then, have a prepare step that makes the platforms do the right thing

(Note that for android it's important to have debug siging keys as well since 
they are used for Play Services and Cloud Console APIs).






On Wed, Jan 28, 2015 at 11:29 AM, Victor Sosa sosah.vic...@gmail.com
wrote:

 Yay!! Great news!

 Chuck, by any chance, do you have a link to the sandbox, or design doc 
 or something worth to look at it? If no, we can wait until Dan is back 
 (hope he feels better soon) I'm happy to help if needed.

 2015-01-28 10:05 GMT-06:00 Chuck Lantz cla...@microsoft.com:

  Dan Levine whom some of you met at PhoneGap day actually has been 
  working on a PR based on Subhag's proposal for discussion - he is 
  out sick which
 is
  why he didn't respond to this thread. I'll let him speak to it once 
  he's back but the good news is there is someone working on something 
  in this area.
 
  -Chuck
 
  -Original Message-
  From: Victor Sosa [mailto:sosah.vic...@gmail.com]
  Sent: Wednesday, January 28, 2015 7:57 AM
  To: dev@cordova.apache.org
  Subject: Re: Build signed archives using CLI
 
  Hi Andrew.
 
  AFAICT, no one has done any work on this area, but I'd like to add 
  this topic to the hangout agenda, start discussing this. I think 
  Subhag has a very good design in the google doc in this thread. We 
  can start from
 there
  and try to make this happen for a future release.
 
  Thoughts before adding it to the agenda?
 
  2015-01-26 20:08 GMT-06:00 Andrew Grieve agri...@chromium.org:
 
   In anyone interested in working on any of this?
  
   Was just looking at it to see if there was anything I needed to do 
   to add support to Android for release packaging.
  
   Main thing lacking to me is whether we should support specifying 
   release key information outside of the platforms/android directory.
   E.g. have a cordova-keys.json as a sibling to www/ that has 
   per-platform key locations  settings.
  
   On Wed, Nov 5, 2014 at 3:15 PM, Victor Sosa 
   sosah.vic...@gmail.com
   wrote:
  
Hello Cordova community
Curious to know where we stand about this topic. Even though 
this topic looks to have significant impact on Cordova, Subhag 
has a document
   proposal
with little discussion activity.
   
I like Subhag's proposal, but I want to bring back the idea of a 
prompt-less keychain.
   
Is anything else, besides what is depicted in the proposal, 
missing
  here?
   
Document:
   
   
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9
   PuNB
   L1auAMGFM/edit?usp=sharing
   
   
-- Forwarded message --
From: Carlos Santana csantan...@gmail.com
Date: 2014-10-15 12:42 GMT-05:00
Subject: Re: Build signed archives using CLI
To: dev@cordova.apache.org dev@cordova.apache.org
   
   
+1 on having a new command cordova package this will allow IBM 
+tooling
   to
hook into before_package and after_package for our own 
customizations (direct update, authenticity, etc..)
+1 on using sane defaults and not prompting (i.e. default 
+keychain maybe
used and unlock already) if not found what we need then prompt 
or fail
+1 have some config/settings outside platforms/ as I like to 
+be
   transient
replaceable. using config.xml, something.json, or file 
conventions like res/packaging/platform/  are all ok options.
   
   
On Thu, Oct 9, 2014 at 5:16 PM, Subhag Oak 
subhag@microsoft.com
wrote:
   
 Here is the link to the proposal:

   
   
   https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9
   PuNB
   L1auAMGFM/edit?usp=sharing
 Jump on it people :)

 Subhag Oak  |  Senior Program Manager

Re: cordova-android 4.0 JUnit tests

I think we're talking about the same thing.

You can have an XWalkCordovaView within a layout, and then attach
a XWalkCordovaWebView to it in code afterwards.

What might be even better though, is if we made CordovaWebView extend View
(probably AbsoluteLayout), and then you wouldn't have to change anything at
all, and the XML inflation would work with either engine.

On Wed, Jan 28, 2015 at 1:25 PM, Joe Bowser bows...@gmail.com wrote:

 What is your definition of embedding a view? I think we're talking about
 two different things.  What I'm talking about is being able to embed
 AndroidWebView as an embedded view without having to change any code other
 than the name of the class.  This means that you don't have to worry about
 the container or any other thing.

 I have never seen an example of Crosswalk using Android XML layouts, and as
 far as I'm currently aware, embedding Crosswalk is less straightforward
 than embedding AndroidWebView or MozillaWebView.

 On Wed Jan 28 2015 at 10:07:18 AM Andrew Grieve agri...@chromium.org
 wrote:

  You can still embed a view using composition. We are not providing any
  backwards compatibility right now, even with inheritance, because
  CordovaWebView is no longer a View (it's an interface, which requires an
  explicit cast to (View), or a call to .getView() to be considered as a
  View)
 
  On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser bows...@gmail.com wrote:
 
   I completely disagree, and think we should go the inheritance pattern.
  The
   reason for that is that we have to provide backwards compatibility for
  some
   views where the implementation is a view, and there's no dual
 inheritance
   in Java, which is the only way that I can see us accommodating both
 types
   of implementations.  If we didn't already have users embedding
   CordovaWebView (and seriously guys, if you're reading this, please
 don't
   keep leaving me hanging here, I want you to step up into this
   conversation).  Also, other views, such as the prototype MozillaView
  that I
   worked on, are implemented so that they inherit from a view.
  
   Just because it may offer some us some flexibility doesn't mean that
 it's
   worth taking away an entire feature from other users.  My most popular
   repository after Cordova itself is the example where I show how to
 embed
  a
   CordovaWebView, so people have been using this feature.
  
   On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve agri...@chromium.org
   wrote:
  
I'd prefer to go the other way, and change AndroidWebView to
  composition.
It's more flexible and does a better job of splitting up groups of
  APIs.
   
On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin ningxin...@intel.com
wrote:
   
 Hi Joe,
 
  The tests don't work with Crosswalk because Crosswalk's main
 class
 doesn't
  inherit from a view.  This is why we had to change the
  CordovaWebView
  from being a class to being an Interface in the first place.  I
  don't
 think there is
  a way for these tests to work with Crosswalk because of this
 incompatibility.
  I don't think there is a way to re-use these tests because of
 this
 fundamental
  change.

 Crosswalk main class (XWalkView) actually inherits from a view (via
 FrameLayout). See
 https://crosswalk-project.org/apis/embeddingapidocs_v3/index.html

 I inspected the commit that changed the XWalkCordovaWebView from
 inheritance to composition (

 https://github.com/MobileChromeApps/cordova-crosswalk-engine/commit/
26029ce8ae6d651a44a90222514cc6902ef8bb4a).
 The reason was some APIs of CordovaWebView interface (e.g.
 CanGoBack)
 conflict with XWalkView internal implementation at that time. And I
 remembered Ian and me thought CordovaWebView as an interface and
 compositing of webview probably was a good decouple solution.

 However, this changed in Crosswalk embedding API 3 (current
 version)
   that
 we separated the public interface and implementation. I briefly
  checked
 that the inheritance approach works with Crosswalk webview now.

 Folks, do you think we need to align all webview engines to
  inheritance
 pattern?

 Thanks,
 -ningxin

  On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei junwei...@intel.com
 
wrote:
 
   Hi,
  
   I pulled cordova-android 4.0 branch, and running JUnit test in
   /test
   directory, but there are compiled error as below, and I want
  reuse
the
   JUnit tests to test Crosswalk pluggable webView,  so I request
 a
  PR
   https://github.com/apache/cordova-android/pull/140, could
  someone
  help
   me to review and merge it.
  
   /test/menus.java:37: error: method registerForContextMenu in
  class
   Activity cannot be applied to given types;
   [javac]
  super.registerForContextMenu(super.appView);
   reason: actual argument CordovaWebView cannot be converted to

Re: [DISCUSS] Cordova-Android 4.0.0 Release

On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve agri...@chromium.org
wrote:


 - Make CordovaActivity not implement CordovaInterface, but instead provide
 CordovaInterface via an inner class (to solidify that you can't cast the
 activity to CordovaInterface and expect that to work - some used to do this
 but I think we've cleaned it all up now)

 This literally came out of nowhere.  Why are you trying so hard to remove
the embedded view use case? What if someone is implementing an activity
that inherits from another activity like MapActivity?  This API change came
without any discussion.

All of this can be done in a few days, but I'd also like to see the dust
 settle a bit before going forward with 4.0.0 release. E.g. At least wait
 until we do a blog post for 3.7.0 (are you doing this?), and have done a
 tools release that updates the pinned version to 3.7.0


If someone else wants to do the blog post on that, that's fine.  And I
agree that there should be a tools release with 3.7.0 pinned, even though
3.7.0 is really just a technicality so we can get 4.0.0 out IMO.



 On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com wrote:

  Reminder: failures with plugins are not blockers.  I've run into that
  contact issue numerous times when testing with my personal device.  I
  recommend making sure that your contacts are completely clean so that you
  don't get these weird results.
 
  The file failures have been happening for quite a while, and those are
 not
  blockers for the platform release either.  Do these failures happen on a
  platform other than ICS?
 
  On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com
 wrote:
 
   I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and there
 are
   some failures. I’ve searched the jira for issues but wasn’t able to
 find
   any. Has anyone else ran into these issues before?
  
   org.apache.cordova.contacts.tests.tests  Contacts
 (navigator.contacts)
   Round trip Contact tests (creating + save + delete + find).
   Contacts.spec.24 Creating, saving, finding a contact should work, after
   which we should not be able to find it, and we should not be able to
  delete
   it again.
   •   Expected 2 to be 1
   •   Expected 1 to be 0
it(contacts.spec.24 Creating, saving, finding a contact
 should
   work, removing it should work, after which we should not be able to
 find
   it, and we should not be able to delete it again., function (done) {
 // Save method is not supported on Windows platform
 if (isWindows) {
 pending();
 return;
 }
 if (isWindowsPhone8) {
 done();
 return;
 }
 gContactObj = new Contact();
 gContactObj.name = new ContactName();
 gContactObj.name.familyName = DeleteMe;
 gContactObj.save(function(c_obj) {
 var findWin = function(cs) {
 expect(cs.length).toBe(1);
 // update to have proper saved id
 gContactObj = cs[0];
 gContactObj.remove(function() {
 var findWinAgain = function(seas) {
 expect(seas.length).toBe(0);
 gContactObj.remove(function() {
 throw(success callback called after
   non-existent Contact object called remove(). Test failed.);
 }, function(e) {
 expect(e.code).toBe(ContactErr
   or.UNKNOWN_ERROR);
 done();
 });
 };
 var findFailAgain = function(e) {
 throw(find error callback invoked after
   delete, test failed.);
 };
 var obj = new ContactFindOptions();
 obj.filter=DeleteMe;
 obj.multiple=true;
 navigator.contacts.find([displayName,
 name,
   phoneNumbers, emails], findWinAgain, findFailAgain, obj);
 }, function(e) {
 throw(Newly created contact's remove
 function
   invoked error callback. Test failed.);
 });
 };
 var findFail = fail;
 var obj = new ContactFindOptions();
 obj.filter=DeleteMe;
 obj.multiple=true;
 navigator.contacts.find([displayName, name,
   phoneNumbers, emails], findWin, findFail, obj);
 }, fail);
 });
  
   org.apache.cordova.file.tests.test  file api filereader file.spec.81
   (couldn’t find a JIRA issue)
   •

Re: [DISCUSS] Cordova-Android 4.0.0 Release

Reminder: failures with plugins are not blockers.  I've run into that
contact issue numerous times when testing with my personal device.  I
recommend making sure that your contacts are completely clean so that you
don't get these weird results.

The file failures have been happening for quite a while, and those are not
blockers for the platform release either.  Do these failures happen on a
platform other than ICS?

On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com wrote:

 I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and there are
 some failures. I’ve searched the jira for issues but wasn’t able to find
 any. Has anyone else ran into these issues before?

 org.apache.cordova.contacts.tests.tests  Contacts (navigator.contacts)
 Round trip Contact tests (creating + save + delete + find).
 Contacts.spec.24 Creating, saving, finding a contact should work, after
 which we should not be able to find it, and we should not be able to delete
 it again.
 •   Expected 2 to be 1
 •   Expected 1 to be 0
  it(contacts.spec.24 Creating, saving, finding a contact should
 work, removing it should work, after which we should not be able to find
 it, and we should not be able to delete it again., function (done) {
   // Save method is not supported on Windows platform
   if (isWindows) {
   pending();
   return;
   }
   if (isWindowsPhone8) {
   done();
   return;
   }
   gContactObj = new Contact();
   gContactObj.name = new ContactName();
   gContactObj.name.familyName = DeleteMe;
   gContactObj.save(function(c_obj) {
   var findWin = function(cs) {
   expect(cs.length).toBe(1);
   // update to have proper saved id
   gContactObj = cs[0];
   gContactObj.remove(function() {
   var findWinAgain = function(seas) {
   expect(seas.length).toBe(0);
   gContactObj.remove(function() {
   throw(success callback called after
 non-existent Contact object called remove(). Test failed.);
   }, function(e) {
   expect(e.code).toBe(ContactErr
 or.UNKNOWN_ERROR);
   done();
   });
   };
   var findFailAgain = function(e) {
   throw(find error callback invoked after
 delete, test failed.);
   };
   var obj = new ContactFindOptions();
   obj.filter=DeleteMe;
   obj.multiple=true;
   navigator.contacts.find([displayName, name,
 phoneNumbers, emails], findWinAgain, findFailAgain, obj);
   }, function(e) {
   throw(Newly created contact's remove function
 invoked error callback. Test failed.);
   });
   };
   var findFail = fail;
   var obj = new ContactFindOptions();
   obj.filter=DeleteMe;
   obj.multiple=true;
   navigator.contacts.find([displayName, name,
 phoneNumbers, emails], findWin, findFail, obj);
   }, fail);
   });

 org.apache.cordova.file.tests.test  file api filereader file.spec.81
 (couldn’t find a JIRA issue)
 •   Expected `` to be null
 describe('FileReader', function () {
 it(file.spec.81 should have correct methods, function () {
 var reader = new FileReader();
 expect(reader).toBeDefined();
 expect(typeof reader.readAsBinaryString).toBe('function');
 expect(typeof reader.readAsDataURL).toBe('function');
 expect(typeof reader.readAsText).toBe('function');
 expect(typeof reader.readAsArrayBuffer).toBe('function');
 expect(typeof reader.abort).toBe('function');
  test below fails 
    '' !== null
 expect(reader.result).toBe(null);
 });
 });

 org.apache.cordova.file.tests.tests  file api parent references
 file.spec.111 (couldn’t find a fire issue):
 •   root.getFile succeeds, it is expected to fail.
 var fileName = traverse.file.uri;
 // create a new file entry
 createFile(fileName, function (entry) {
 // lookup file system entry
 root.getFile('../' + fileName, {
 create : false
 }, succeed.bind(null, done,
 root.getFile('../+fileName+ ')- Unexpected

Re: cordova-android 4.0 JUnit tests

You can still embed a view using composition. We are not providing any
backwards compatibility right now, even with inheritance, because
CordovaWebView is no longer a View (it's an interface, which requires an
explicit cast to (View), or a call to .getView() to be considered as a View)

On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser bows...@gmail.com wrote:

 I completely disagree, and think we should go the inheritance pattern.  The
 reason for that is that we have to provide backwards compatibility for some
 views where the implementation is a view, and there's no dual inheritance
 in Java, which is the only way that I can see us accommodating both types
 of implementations.  If we didn't already have users embedding
 CordovaWebView (and seriously guys, if you're reading this, please don't
 keep leaving me hanging here, I want you to step up into this
 conversation).  Also, other views, such as the prototype MozillaView that I
 worked on, are implemented so that they inherit from a view.

 Just because it may offer some us some flexibility doesn't mean that it's
 worth taking away an entire feature from other users.  My most popular
 repository after Cordova itself is the example where I show how to embed a
 CordovaWebView, so people have been using this feature.

 On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve agri...@chromium.org
 wrote:

  I'd prefer to go the other way, and change AndroidWebView to composition.
  It's more flexible and does a better job of splitting up groups of APIs.
 
  On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin ningxin...@intel.com
  wrote:
 
   Hi Joe,
   
The tests don't work with Crosswalk because Crosswalk's main class
   doesn't
inherit from a view.  This is why we had to change the CordovaWebView
from being a class to being an Interface in the first place.  I don't
   think there is
a way for these tests to work with Crosswalk because of this
   incompatibility.
I don't think there is a way to re-use these tests because of this
   fundamental
change.
  
   Crosswalk main class (XWalkView) actually inherits from a view (via
   FrameLayout). See
   https://crosswalk-project.org/apis/embeddingapidocs_v3/index.html
  
   I inspected the commit that changed the XWalkCordovaWebView from
   inheritance to composition (
   https://github.com/MobileChromeApps/cordova-crosswalk-engine/commit/
  26029ce8ae6d651a44a90222514cc6902ef8bb4a).
   The reason was some APIs of CordovaWebView interface (e.g. CanGoBack)
   conflict with XWalkView internal implementation at that time. And I
   remembered Ian and me thought CordovaWebView as an interface and
   compositing of webview probably was a good decouple solution.
  
   However, this changed in Crosswalk embedding API 3 (current version)
 that
   we separated the public interface and implementation. I briefly checked
   that the inheritance approach works with Crosswalk webview now.
  
   Folks, do you think we need to align all webview engines to inheritance
   pattern?
  
   Thanks,
   -ningxin
  
On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei junwei...@intel.com
  wrote:
   
 Hi,

 I pulled cordova-android 4.0 branch, and running JUnit test in
 /test
 directory, but there are compiled error as below, and I want reuse
  the
 JUnit tests to test Crosswalk pluggable webView,  so I request a PR
 https://github.com/apache/cordova-android/pull/140, could someone
help
 me to review and merge it.

 /test/menus.java:37: error: method registerForContextMenu in class
 Activity cannot be applied to given types;
 [javac] super.registerForContextMenu(super.appView);
 reason: actual argument CordovaWebView cannot be converted to View
by
 method invocation conversion

 test/splashscreen.java:33: error: method loadUrl in class
 CordovaActivity cannot be applied to given types;
 [javac]
super.loadUrl(file:///android_asset/www/splashscreen/index.html,
 2000);
 reason: actual and formal argument lists differ in length

 Thanks,
 Junwei.

 
  -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-android 4.0 JUnit tests

What is your definition of embedding a view? I think we're talking about
two different things.  What I'm talking about is being able to embed
AndroidWebView as an embedded view without having to change any code other
than the name of the class.  This means that you don't have to worry about
the container or any other thing.

I have never seen an example of Crosswalk using Android XML layouts, and as
far as I'm currently aware, embedding Crosswalk is less straightforward
than embedding AndroidWebView or MozillaWebView.

On Wed Jan 28 2015 at 10:07:18 AM Andrew Grieve agri...@chromium.org
wrote:

 You can still embed a view using composition. We are not providing any
 backwards compatibility right now, even with inheritance, because
 CordovaWebView is no longer a View (it's an interface, which requires an
 explicit cast to (View), or a call to .getView() to be considered as a
 View)

 On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser bows...@gmail.com wrote:

  I completely disagree, and think we should go the inheritance pattern.
 The
  reason for that is that we have to provide backwards compatibility for
 some
  views where the implementation is a view, and there's no dual inheritance
  in Java, which is the only way that I can see us accommodating both types
  of implementations.  If we didn't already have users embedding
  CordovaWebView (and seriously guys, if you're reading this, please don't
  keep leaving me hanging here, I want you to step up into this
  conversation).  Also, other views, such as the prototype MozillaView
 that I
  worked on, are implemented so that they inherit from a view.
 
  Just because it may offer some us some flexibility doesn't mean that it's
  worth taking away an entire feature from other users.  My most popular
  repository after Cordova itself is the example where I show how to embed
 a
  CordovaWebView, so people have been using this feature.
 
  On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve agri...@chromium.org
  wrote:
 
   I'd prefer to go the other way, and change AndroidWebView to
 composition.
   It's more flexible and does a better job of splitting up groups of
 APIs.
  
   On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin ningxin...@intel.com
   wrote:
  
Hi Joe,

 The tests don't work with Crosswalk because Crosswalk's main class
doesn't
 inherit from a view.  This is why we had to change the
 CordovaWebView
 from being a class to being an Interface in the first place.  I
 don't
think there is
 a way for these tests to work with Crosswalk because of this
incompatibility.
 I don't think there is a way to re-use these tests because of this
fundamental
 change.
   
Crosswalk main class (XWalkView) actually inherits from a view (via
FrameLayout). See
https://crosswalk-project.org/apis/embeddingapidocs_v3/index.html
   
I inspected the commit that changed the XWalkCordovaWebView from
inheritance to composition (
https://github.com/MobileChromeApps/cordova-crosswalk-engine/commit/
   26029ce8ae6d651a44a90222514cc6902ef8bb4a).
The reason was some APIs of CordovaWebView interface (e.g. CanGoBack)
conflict with XWalkView internal implementation at that time. And I
remembered Ian and me thought CordovaWebView as an interface and
compositing of webview probably was a good decouple solution.
   
However, this changed in Crosswalk embedding API 3 (current version)
  that
we separated the public interface and implementation. I briefly
 checked
that the inheritance approach works with Crosswalk webview now.
   
Folks, do you think we need to align all webview engines to
 inheritance
pattern?
   
Thanks,
-ningxin
   
 On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei junwei...@intel.com
   wrote:

  Hi,
 
  I pulled cordova-android 4.0 branch, and running JUnit test in
  /test
  directory, but there are compiled error as below, and I want
 reuse
   the
  JUnit tests to test Crosswalk pluggable webView,  so I request a
 PR
  https://github.com/apache/cordova-android/pull/140, could
 someone
 help
  me to review and merge it.
 
  /test/menus.java:37: error: method registerForContextMenu in
 class
  Activity cannot be applied to given types;
  [javac] super.registerForContextMenu(super.appView);
  reason: actual argument CordovaWebView cannot be converted to
 View
 by
  method invocation conversion
 
  test/splashscreen.java:33: error: method loadUrl in class
  CordovaActivity cannot be applied to given types;
  [javac]
 super.loadUrl(file:///android_asset/www/splashscreen/index.html,
  2000);
  reason: actual and formal argument lists differ in length
 
  Thanks,
  Junwei.
 
  
   -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands,

Re: [DISCUSS] Cordova-Android 4.0.0 Release

Things i think we should still wait for:
- Ian's been working on getting crosswalk 10 working and is hitting some
FileTransfer crash issues.
- Mobilespec really should be passing, let's investigate and fix plugins /
tests if they are the issues.
- Android's update script is not preserving artifacts of framework
type=gradleReference/ (hoping to work on this today)
- *LinearLayoutSoftKeyboardDetect - delete it!*
- Ensure that our gradle support is to the point where plugins can target
android-sdk-provided libs (play services  -compat libs)
- Make CordovaActivity not implement CordovaInterface, but instead provide
CordovaInterface via an inner class (to solidify that you can't cast the
activity to CordovaInterface and expect that to work - some used to do this
but I think we've cleaned it all up now)

All of this can be done in a few days, but I'd also like to see the dust
settle a bit before going forward with 4.0.0 release. E.g. At least wait
until we do a blog post for 3.7.0 (are you doing this?), and have done a
tools release that updates the pinned version to 3.7.0


On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com wrote:

 Reminder: failures with plugins are not blockers.  I've run into that
 contact issue numerous times when testing with my personal device.  I
 recommend making sure that your contacts are completely clean so that you
 don't get these weird results.

 The file failures have been happening for quite a while, and those are not
 blockers for the platform release either.  Do these failures happen on a
 platform other than ICS?

 On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com wrote:

  I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and there are
  some failures. I’ve searched the jira for issues but wasn’t able to find
  any. Has anyone else ran into these issues before?
 
  org.apache.cordova.contacts.tests.tests  Contacts (navigator.contacts)
  Round trip Contact tests (creating + save + delete + find).
  Contacts.spec.24 Creating, saving, finding a contact should work, after
  which we should not be able to find it, and we should not be able to
 delete
  it again.
  •   Expected 2 to be 1
  •   Expected 1 to be 0
   it(contacts.spec.24 Creating, saving, finding a contact should
  work, removing it should work, after which we should not be able to find
  it, and we should not be able to delete it again., function (done) {
// Save method is not supported on Windows platform
if (isWindows) {
pending();
return;
}
if (isWindowsPhone8) {
done();
return;
}
gContactObj = new Contact();
gContactObj.name = new ContactName();
gContactObj.name.familyName = DeleteMe;
gContactObj.save(function(c_obj) {
var findWin = function(cs) {
expect(cs.length).toBe(1);
// update to have proper saved id
gContactObj = cs[0];
gContactObj.remove(function() {
var findWinAgain = function(seas) {
expect(seas.length).toBe(0);
gContactObj.remove(function() {
throw(success callback called after
  non-existent Contact object called remove(). Test failed.);
}, function(e) {
expect(e.code).toBe(ContactErr
  or.UNKNOWN_ERROR);
done();
});
};
var findFailAgain = function(e) {
throw(find error callback invoked after
  delete, test failed.);
};
var obj = new ContactFindOptions();
obj.filter=DeleteMe;
obj.multiple=true;
navigator.contacts.find([displayName, name,
  phoneNumbers, emails], findWinAgain, findFailAgain, obj);
}, function(e) {
throw(Newly created contact's remove function
  invoked error callback. Test failed.);
});
};
var findFail = fail;
var obj = new ContactFindOptions();
obj.filter=DeleteMe;
obj.multiple=true;
navigator.contacts.find([displayName, name,
  phoneNumbers, emails], findWin, findFail, obj);
}, fail);
});
 
  org.apache.cordova.file.tests.test  file api filereader file.spec.81
  (couldn’t find a JIRA issue)
  •   Expected `` to be null
  describe('FileReader', function () {

RE: [DISCUSS] Cordova-Android 4.0.0 Release

2015-01-28 Thread Murat Sutunc

Just give some data point, running mobile spec I'm getting:
- 11 failures in 4.4.2 
- 6 failures in 4.0.4
Ideally we should bring those numbers to 0 to ensure a stable release. 

-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com] 
Sent: Wednesday, January 28, 2015 10:45 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release

On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve agri...@chromium.org
wrote:

 - Make CordovaActivity not implement CordovaInterface, but instead 
 provide CordovaInterface via an inner class (to solidify that you 
 can't cast the activity to CordovaInterface and expect that to work - 
 some used to do this but I think we've cleaned it all up now)

 This literally came out of nowhere.  Why are you trying so hard to 
 remove
the embedded view use case? What if someone is implementing an activity that 
inherits from another activity like MapActivity?  This API change came without 
any discussion.

All of this can be done in a few days, but I'd also like to see the dust
 settle a bit before going forward with 4.0.0 release. E.g. At least 
 wait until we do a blog post for 3.7.0 (are you doing this?), and have 
 done a tools release that updates the pinned version to 3.7.0

If someone else wants to do the blog post on that, that's fine.  And I agree 
that there should be a tools release with 3.7.0 pinned, even though
3.7.0 is really just a technicality so we can get 4.0.0 out IMO.

 On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com wrote:

  Reminder: failures with plugins are not blockers.  I've run into 
  that contact issue numerous times when testing with my personal 
  device.  I recommend making sure that your contacts are completely 
  clean so that you don't get these weird results.

  The file failures have been happening for quite a while, and those 
  are
 not
  blockers for the platform release either.  Do these failures happen 
  on a platform other than ICS?

  On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com
 wrote:

   I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and 
   there
 are
   some failures. I’ve searched the jira for issues but wasn’t able 
   to
 find
   any. Has anyone else ran into these issues before?

   org.apache.cordova.contacts.tests.tests  Contacts
 (navigator.contacts)
   Round trip Contact tests (creating + save + delete + find).
   Contacts.spec.24 Creating, saving, finding a contact should work, 
   after which we should not be able to find it, and we should not be 
   able to
  delete
   it again.
   •   Expected 2 to be 1
   •   Expected 1 to be 0
it(contacts.spec.24 Creating, saving, finding a contact
 should
   work, removing it should work, after which we should not be able 
   to
 find
   it, and we should not be able to delete it again., function (done) {
 // Save method is not supported on Windows platform
 if (isWindows) {
 pending();
 return;
 }
 if (isWindowsPhone8) {
 done();
 return;
 }
 gContactObj = new Contact();
 gContactObj.name = new ContactName();
 gContactObj.name.familyName = DeleteMe;
 gContactObj.save(function(c_obj) {
 var findWin = function(cs) {
 expect(cs.length).toBe(1);
 // update to have proper saved id
 gContactObj = cs[0];
 gContactObj.remove(function() {
 var findWinAgain = function(seas) {
 expect(seas.length).toBe(0);
 gContactObj.remove(function() {
 throw(success callback called 
   after non-existent Contact object called remove(). Test failed.);
 }, function(e) {
 expect(e.code).toBe(ContactErr 
   or.UNKNOWN_ERROR);
 done();
 });
 };
 var findFailAgain = function(e) {
 throw(find error callback invoked 
   after delete, test failed.);
 };
 var obj = new ContactFindOptions();
 obj.filter=DeleteMe;
 obj.multiple=true;
 navigator.contacts.find([displayName,
 name,
   phoneNumbers, emails], findWinAgain, findFailAgain, obj);
 }, function(e) {
 throw(Newly created contact's remove
 function
   invoked error callback. Test failed.);
 });
 };
 var findFail = fail;

[GitHub] cordova-browser pull request: CB-8182 - port 'cordova serve' to 'c...

2015-01-28 Thread kirkshoop

Github user kirkshoop commented on the pull request:

https://github.com/apache/cordova-browser/pull/9#issuecomment-71892622
  
no prayer was involved. 

As I said, if there are good scenarios for `cordova serve` then it should 
continue to exist. You have explained that it should exist and I agree with you.

The scenarios for `cordova run browser` are different and require that the 
project be hosted over http in the browser platform as well. Currently, a file 
url is used which causes issues with CORS headers and other effects that cause 
`cordova run browser` with a file url to behave completely differently than it 
will when actually hosted as a web site. These differences need to be minimized 
to ensure that more bugs can be reproduced and fixed locally.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova-android 4.0 JUnit tests

On Wed Jan 28 2015 at 10:42:46 AM Andrew Grieve agri...@chromium.org
wrote:

 I think we're talking about the same thing.

 You can have an XWalkCordovaView within a layout, and then attach
 a XWalkCordovaWebView to it in code afterwards.

 What might be even better though, is if we made CordovaWebView extend View
 (probably AbsoluteLayout), and then you wouldn't have to change anything at
 all, and the XML inflation would work with either engine.


This still doesn't fix the problem.  If CordovaWebView extends view, what
does AndroidWebView or MozillaWebView extend? They're both currently
extending WebView and GeckoView respectively.  This also means that the
embedding code would have to completely change and would be even more
incompatible than the interface approach.



 On Wed, Jan 28, 2015 at 1:25 PM, Joe Bowser bows...@gmail.com wrote:

  What is your definition of embedding a view? I think we're talking about
  two different things.  What I'm talking about is being able to embed
  AndroidWebView as an embedded view without having to change any code
 other
  than the name of the class.  This means that you don't have to worry
 about
  the container or any other thing.
 
  I have never seen an example of Crosswalk using Android XML layouts, and
 as
  far as I'm currently aware, embedding Crosswalk is less straightforward
  than embedding AndroidWebView or MozillaWebView.
 
  On Wed Jan 28 2015 at 10:07:18 AM Andrew Grieve agri...@chromium.org
  wrote:
 
   You can still embed a view using composition. We are not providing any
   backwards compatibility right now, even with inheritance, because
   CordovaWebView is no longer a View (it's an interface, which requires
 an
   explicit cast to (View), or a call to .getView() to be considered as a
   View)
  
   On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser bows...@gmail.com
 wrote:
  
I completely disagree, and think we should go the inheritance
 pattern.
   The
reason for that is that we have to provide backwards compatibility
 for
   some
views where the implementation is a view, and there's no dual
  inheritance
in Java, which is the only way that I can see us accommodating both
  types
of implementations.  If we didn't already have users embedding
CordovaWebView (and seriously guys, if you're reading this, please
  don't
keep leaving me hanging here, I want you to step up into this
conversation).  Also, other views, such as the prototype MozillaView
   that I
worked on, are implemented so that they inherit from a view.
   
Just because it may offer some us some flexibility doesn't mean that
  it's
worth taking away an entire feature from other users.  My most
 popular
repository after Cordova itself is the example where I show how to
  embed
   a
CordovaWebView, so people have been using this feature.
   
On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve agri...@chromium.org
 
wrote:
   
 I'd prefer to go the other way, and change AndroidWebView to
   composition.
 It's more flexible and does a better job of splitting up groups of
   APIs.

 On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin 
 ningxin...@intel.com
 wrote:

  Hi Joe,
  
   The tests don't work with Crosswalk because Crosswalk's main
  class
  doesn't
   inherit from a view.  This is why we had to change the
   CordovaWebView
   from being a class to being an Interface in the first place.  I
   don't
  think there is
   a way for these tests to work with Crosswalk because of this
  incompatibility.
   I don't think there is a way to re-use these tests because of
  this
  fundamental
   change.
 
  Crosswalk main class (XWalkView) actually inherits from a view
 (via
  FrameLayout). See
  https://crosswalk-project.org/apis/embeddingapidocs_v3/
 index.html
 
  I inspected the commit that changed the XWalkCordovaWebView from
  inheritance to composition (
 
  https://github.com/MobileChromeApps/cordova-crosswalk-engine/commit/
 26029ce8ae6d651a44a90222514cc6902ef8bb4a).
  The reason was some APIs of CordovaWebView interface (e.g.
  CanGoBack)
  conflict with XWalkView internal implementation at that time.
 And I
  remembered Ian and me thought CordovaWebView as an interface and
  compositing of webview probably was a good decouple solution.
 
  However, this changed in Crosswalk embedding API 3 (current
  version)
that
  we separated the public interface and implementation. I briefly
   checked
  that the inheritance approach works with Crosswalk webview now.
 
  Folks, do you think we need to align all webview engines to
   inheritance
  pattern?
 
  Thanks,
  -ningxin
 
   On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei 
 junwei...@intel.com
  
 wrote:
  
Hi,
   
I pulled cordova-android 4.0 branch, and running JUnit test
 in
/test

Re: [DISCUSS] Cordova-Android 4.0.0 Release