from:"Tommy\-Carlos Williams"

Re: [Android] Ending support for Ice Cream Sandwich?

2016-05-06 Thread Tommy-Carlos Williams

Very +1

> On 5 May 2016, at 23:57, Joe Bowser  wrote:
> 
> Hey
> 
> So, it's been a while, but it looks like we should really drop support for
> ICS, because Crosswalk is dropping support for ICS.
> 
> https://crosswalk-project.org/blog/deprecate-40.html
> 
> So, yeah, I think we should drop support for ICS.  I know it's been a "Meh,
> why not?" thing for people to support for a while and there wasn't a super
> strong case for dropping it, but now that we can't use Crosswalk to fix our
> WebView woes, I think it's time to put this thing at rest and move on.
> 
> Thoughts?
> 
> Joe

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

Re: package discovery

2016-02-05 Thread Tommy-Carlos Williams

+1


> On 6 Feb 2016, at 6:51 AM, Steven Gill  wrote:
> 
> Hey everyone!
> 
> With templates out now, I wanted to propose a few keywords for improving
> discoverability.
> 
> Firstly, every package should contain 'ecosystem:cordova'.
> 
> I suggest we add these new keywords.
> 'cordova:platform'
> 'cordova:plugin'
> 'cordova:template'
> 'cordova-tool' (don't really need this one)
> 
> then we can eventually create a new template.cordova.io search site based
> off the plugins search site that uses the 'cordova:template'.
> 
> I'm going to blog about templates next week as long as we can land some
> consensus on this.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [DISCUSS] Cordova 6.0.0 Release!

2016-01-23 Thread Tommy-Carlos Williams

+1


> On 24 Jan 2016, at 10:05 AM, julio cesar sanchez  
> wrote:
> 
> +1
> 
> 2016-01-23 21:55 GMT+01:00 Carlos Santana :
> 
>> +1
>> 
>> On Fri, Jan 22, 2016 at 3:24 PM Steven Gill 
>> wrote:
>> 
>>> any objections or concerns? Some PRs or issues that need to get fixed
>>> before I do this?
>>> 
>>> I want to try to get the vote out either later today or Monday.
>>> 
>>> -Steve
>>> 
>> 


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

Re: Plugin Audit 2015

2015-11-13 Thread Tommy-Carlos Williams

It's not a "must have".  I have yet to use it in any of my projects. 

It can be very handy, and I am glad someone is maintaining it, but it's not 
required. 

> On 14 Nov 2015, at 06:29, Jesse  wrote:
> 
> Okay. I'll back down then. I thought it was a 'must have' which to me 
> dictates that we 'must have' a fork. 
> 
> 
> 
>> On Nov 13, 2015, at 10:46 AM, Shazron  wrote:
>> 
>> I don't agree with keyboard being in core. It's not "required" on ios,
>> it's just a cosmetic change, and its pretty hacky to get right. With
>> iPad and iPad Pro's new enhanced keyboards, this will be a bigger
>> nightmare to maintain thus I am strongly against this.
>> 
>> With iOS 7 and greater's flat UI, the toolbar doesn't look that bad anyway.
>> 
>> As an example, Gmail iOS doesn't even bother trying to hide the
>> toolbar. Try to do a Search on it to see the keyboard. It uses a
>> WebView I believe for most of its UI.
>> 
>> 
>>> On Thu, Nov 12, 2015 at 9:52 PM, Jesse  wrote:
>>> The reason I think the keyboard should be core is that it is required on
>>> ios, and we are completely dependent on ionic to maintain it.  The license
>>> is Apache 2.0 so I think it would make the most sense for use to depend on
>>> a fork of our own and ask Ionic to continue to contribute to it.
>>> ( or review their future changes and pull into our branch when appropriate.
>>> )
>>> 
>>> 
>>> 
>>> 
>>> 
>>> @purplecabbage
>>> risingj.com
>>> 
>>> On Tue, Nov 10, 2015 at 12:12 PM, Kerri Shotts 
>>> wrote:
>>> 
 Yay, the audit happened! :-) So very cool. Not sure I agree with a couple
 of the choices, but haven’t had the brain power to think through everything
 yet.

 If the keyboard plugin is going to remain managed by ionic, then I’d keep
 it out of core, honestly. To me, “core” implies Apache-managed. Installed
 by default, OTH, wouldn’t be a bad idea.

 As for native dialogs, well… personally, I’m all for doing them in
 HTML/CSS/JS. On the flip side, native dialogs can be a quick way to display
 messages or get input. That said, I don’t think it needs to be a core
 plugin. Perhaps spin it off into a third-party plugin and let the community
 step up if they see the need.

 @Parashuram: I have a native controls plugin for iOS. It needs some love,
 though, which I plan on getting to once my book is done (almost!). I know
 there are others out there too, but I’m not sure how many support Android.

 Kerri Shotts , photoKandy Studios LLC • (312) 380–1035 • (618) 435–0823
 (mobile)

 http://www.photokandy.com/ • @photokandy • Github • CoderWall

 → CONFIDENTIAL ←

 This email and any attachments may be confidential. If you are not the
 intended recipient, please let us know by replying to this message, and
 then remove the message and its attachments from your system. You should
 not disseminate, distribute, or otherwise copy or release the information
 contained herein, nor can we accept any liability for any loss or damages
 resulting from the use, abuse, or mis-use of the information contained
 herein.

 → SECURITY ←

 Computer viruses can be distributed via email. It is the recipient’s
 responsibility to check this email and any attachments for viruses. Email
 transmission cannot be guaranteed to be secure or error-free as the email
 could have been intercepted, corrupted, delayed, and/or re-transmitted. The
 sender does not accept any liability for errors or omissions within this
 message or its attachments, nor for any viruses which may be present.

 Note: We do our very best to ensure that nothing we send contains viruses.
 However, because of the nature of email and the way it is sent, we can’t
 promise that some other party hasn’t intercepted our email and added
 malicious content. Due to the nature of email, we can’t accept any
 liability for any damage or loss arising from the use, abuse, or mis-use of
 this email and any of its attachments.

 → PRIVACY ←

 Email is not a secure communications medium. When replying to this or any
 message, you should not include any information that you do not want the
 entire world to be capable of seeing. In other words, don’t send financial
 accounts (CC#s, Bank Account #s, etc.), passwords, social security numbers,
 or the like, even when asked directly. photoKandy Studios LLC
 will never  ask you for this information.

 Information transmitted via email may be intercepted and retransmitted by
 any number of other entities. This is the nature of email, and as such, we
 can’t be held liable for any loss or damage incurred by replying to this
 message with compromising information. Review your message prior to sending
 it, and ensure that

Re: [DISCUSS] Proposal to Remove the Cordova iOS Native Whitelist

2015-11-03 Thread Tommy-Carlos Williams

+1 to letting the OS handle it. 

> On 4 Nov 2015, at 12:44, Jesse  wrote:
> 
> I completely support the proposal!
> 
> 
> @purplecabbage
> risingj.com
> 
>> On Tue, Nov 3, 2015 at 5:35 PM, Shazron  wrote:
>> 
>> BUMP. This is important, and is causing a lot of pain for our users.
>> For example:
>> https://github.com/jessemonroy650/top-phonegap-mistakes/blob/master/the-whitelist-system.md
>> 
>> 
>>> On Mon, Nov 2, 2015 at 5:38 PM, Shazron  wrote:
>>> To view contents of the PR easily:
>> https://github.com/shazron/cordova-discuss/blob/da7af6606848a1b7d96f4d5ee5402360bf5fd53c/proposals/ios-whitelist-removal.md
>>> 
 On Mon, Nov 2, 2015 at 5:36 PM, Shazron  wrote:
 PR sent: https://github.com/cordova/cordova-discuss/pull/27
 
> On Mon, Nov 2, 2015 at 5:21 PM, Shazron  wrote:
> Sorry everyone -- I'm structuring it as a PR and will revert my
> commits. Will be easier to comment that way
> 
>> On Mon, Nov 2, 2015 at 5:05 PM, Shazron  wrote:
>> https://github.com/cordova/cordova-discuss/blob/master/proposals/ios-whitelist-removal.md
>> 
>> Comment here or there, etc. I've included flowcharts...
>> 
>> tldr; remove the whitelist in cordova-ios-4.x. we are not good at
>> security, let the OS handle it.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>> 
>> 

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

Re: Cordova website redesign

2015-10-07 Thread Tommy-Carlos Williams

Yeah... I kinda fell into the "not sure, wait and see what others thought" 
category on this one.  

I would also like more discussion unless everyone really has no opinion.  

> On 8 Oct 2015, at 05:42, Jesse  wrote:
> 
> I would suggest that the lack of response on the logo change means we don't 
> need it. 
> I think there should at least be some discussion before moving on it. 
> 
>> On Oct 7, 2015, at 11:31 AM, Brad Gashler  wrote:
>> 
>> Hi Everyone,
>> 
>> I wanted to follow up on the branding changes proposed by Ben Sperry (his 
>> email is included below).
>> 
>> I’m planning on implementing his changes, since no objections were raised.  
>> This includes the new logo, with its modern typeface, as shown in picture A 
>> below.  Also, we may replace the background image with the simple gradient 
>> as shown in picture B below.  Please let me know if there are any concerns 
>> replacing this background image.
>> 
>> Thanks,
>> 
>> Brad Gashler
>> 
>> 
>> A) New logo only
>> 
>> 
>> 
>> B) New logo and new gradient background
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Ben Sperry [mailto:b...@ionic.io] 
>> Sent: Thursday, September 24, 2015 1:17 PM
>> To: dev@cordova.apache.org
>> Subject: Re: Cordova website redesign
>> 
>> I really like where this update is going, and what it signals to the
>> community: Cordova is a legitimate, modern tech solution that's still very 
>> much alive and growing. The website look/feel has a lot of confidence, love 
>> it!
>> 
>> I'm curious what thoughts are around a Cordova logo update itself. I put 
>> together a version that I thought might support the evolution of Cordova 
>> into a more modern looking brand. Would love feedback on this early logo 
>> update mockup: regular 
>> 
>> / flat
>> 
>> 
>> A few things to note: The typeface is really the big update - the little 
>> robot logo itself can stay the same (because he is awesome). The existing 
>> typeface is just plain-old Helvetica, which is totally fine, but can 
>> sometimes feel empty of any personality or uniqueness. My suggestion is 
>> simply to update it to a more contemporary, custom typeface (in this case, 
>> Brandon Text 
>> ).
>> 
>> Would love to hear any and all thoughts on this!
>> 
>>> On Thu, Sep 24, 2015 at 1:25 PM, Frederico Galvão < 
>>> frederico.gal...@pontoget.com.br> wrote:
>>> 
>>> Looks great indeed, nice job!
>>> 
>>> One thing I noticed is that
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fproje
>>> cts.apache.org%2fproject.html%3fcordova=01%7c01%7cbradga%40micros
>>> oft.com%7c46d14102d64c4e5de06408d2c51d409d%7c72f988bf86f141af91ab2d7cd
>>> 011db47%7c1=ZeVerioKs9Eu8faVlumAOu0bmmXPyqq6tJ5gsXU2KNM%3d
>>> seems very outdated.
>>> 
>>> 2015-09-23 22:49 GMT-03:00 Carlos Santana :
>>> 
 This looks great.
 Can you add a sub page link in the navigation column to this page?
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
>>> a.apache.org%2fuse-the-force-luke%2fdocs%2fen%2fedge%2fplugin_ref%2fsp
>>> ec.html=01%7c01%7cbradga%40microsoft.com%7c46d14102d64c4e5de06408
>>> d2c51d409d%7c72f988bf86f141af91ab2d7cd011db47%7c1=Ng%2fQbCHankWf
>>> qNC%2fx9Xsaj1OxfSkoMhaH97WmznRfeI%3d
 
 
> On Wed, Sep 23, 2015 at 7:50 PM Anis KADRI  wrote:
> 
> Waw. It looks really really nice! Thanks so much for taking care
> of
>>> this.
> 
>> On Wed, Sep 23, 2015 at 2:45 PM Shazron  wrote:
>> 
>> Thank you for doing this, the site is great!
>> The community will love this.
>> 
>> On Wed, Sep 23, 2015 at 11:02 AM, Ryan J. Salva <
>>> ryanjsa...@gmail.com>
>> wrote:
>>> TLDR
>>> 
>>> -- Feedback requested for a proposed Cordova website redesign
>>> at
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%
>>> 2fcordova.apache.org%2fuse-the-force-luke=01%7c01%7cbradg
>>> a%40microsoft.com%7c46d14102d64c4e5de06408d2c51d409d%7c72f988b
>>> f86f141af91ab2d7cd011db47%7c1=WfhsLEijWdilHq7RBNF6%2fGuf
>>>

Re: [DISCUSS] Tools Release

2015-09-17 Thread Tommy-Carlos Williams

Were we waiting on a vote? I would +1

> On 17 Sep 2015, at 22:50, Carlos Santana  wrote:
> 
> A day has pass and no sign of a vote for the emergency fix.
> 
> Why not just do a tools release with everything it's in master today?
> in theory we should be able to do a release of what's in master at any time
> 
> 
> On Thu, Sep 17, 2015 at 5:29 AM Vladimir Kotikov (Akvelon) <
> v-vlk...@microsoft.com> wrote:
> 
>> I believe this is not a blocker. We have platforms pinned with tilde, so
>> platform's patch release will be picked up automatically.
>> 
>> -
>> Best regards, Vladimir
>> 
>> -Original Message-
>> From: Tommy Williams [mailto:to...@devgeeks.org]
>> Sent: Thursday, September 17, 2015 7:59 AM
>> To: dev@cordova.apache.org
>> Subject: Re: [DISCUSS] Tools Release
>> 
>> I have a cherry pick to cordova-ios[1] that would be good to be included
>> in 5.3.2 if there are already plans to update iOS’s pinned version…
>> 
>> 1.
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9046=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7cc74c34192a664443cce908d2bf1cc69b%7c72f988bf86f141af91ab2d7cd011db47%7c1=M%2f1jcQ0q3%2bllZYMoSsU0dHNrX12No0fK5HlcW3C13mg%3d
>> 
>> 
>> On 17 September 2015 at 03:46:52, Carlos Santana (csantan...@gmail.com)
>> wrote:
>> 
>> +1
>> 
>> There are more commits seating in master, Should we plan for another
>> release right after releasing the cherry-pick release for nodejs@4?
>> 
>> 
>> On Wed, Sep 16, 2015 at 11:25 AM Steven Gill 
>> wrote:
>> 
>>> Good idea with the cherry-pick.
>>> On Sep 16, 2015 8:07 AM, "Sergey Grebnov (Akvelon)" <
>>> v-seg...@microsoft.com>
>>> wrote:
>>> 
 We currently have iOS and Node v4 compatibility issue[1] which has
 been recently fixed[2] so I propose to cherry pick that fix and do
 patch
>>> release
 (cordova@5.3.2).
 
 Does anyone have any reason to delay a tools patch release?
 
 If not, I will start the release tomorrow.
 
 [1]
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fiss
 ues.apache.org%2fjira%2fbrowse%2fCB-9297=01%7c01%7cv-vlkoti%400
 64d.mgd.microsoft.com%7cc74c34192a664443cce908d2bf1cc69b%7c72f988bf8
 6f141af91ab2d7cd011db47%7c1=MtwvQkbecpe9ES%2fY5JyJbOnNsQUQaNfe
 LWy9BBMgejk%3d
 [2]
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>>> b.com%2fapache%2fcordova-lib%2fcommit%2f5f008df5e4b8bff934b05d049fda07
>>> 74b7bc4583=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7cc74c3419
>>> 2a664443cce908d2bf1cc69b%7c72f988bf86f141af91ab2d7cd011db47%7c1=
>>> RsC5DIjZnjBQ8pZ9xl%2fBPPw26DUVpurcw6bZGAD17Pg%3d
 
 Thx!
 Sergey
 
 
 
 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
>> 

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

Re: [iOS] proposed major whitelist change

2015-08-26 Thread Tommy-Carlos Williams

+1 from me. 



 On 26 Aug 2015, at 23:13, Shazron shaz...@gmail.com wrote:
 
 Any objections or further feedback? If not I will move on to what we seem
 to have consensus about:
 
 If there are no access entries, then network requests are wide open
 (wildcard * default) and security is handled via CSP.
 We would recommend no access entries to be used, users should use CSP.
 
 On Tue, Aug 11, 2015 at 7:01 PM, Shazron shaz...@gmail.com wrote:
 
 
 So, is the whitelist plugin network request list * with no access
 entries, or
 * because of the access entry added to the default project?
 
 
 * would be the default. So if there are no access entries, it would be
 added. If the default project had the access wildcard, then no change
 (since that is the default anyway).
 
 The old way you would need an explicit access entry wildcard for
 unrestricted native and web code access -- the new way is unrestricted
 native code access (unless set explicitly), and CSP for web code access.
 

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

Re: WKWebView and iOS 9

2015-08-25 Thread tommy-carlos williams

+1


On 26 August 2015 at 07:20:18, Shazron (shaz...@gmail.com) wrote:

I'm going to move onto the 2 plugin idea if there are no objections. This 
will preserve the existing plugin into a newly named plugin. 

On Mon, Aug 24, 2015 at 3:24 PM, Carlos Santana csantan...@gmail.com 
wrote: 

 I like much better your naming suggestions for the plugins 
 
 - Carlos 
 Sent from my iPhone 
 
  On Aug 24, 2015, at 4:17 PM, Shazron shaz...@gmail.com wrote: 
  
  I like the two plugin idea. 
  
  Using file:// would be the recommended and default, iOS 9 only -- and 
 this 
  should be wkwebview-engine 
  Using the local webserver -- and this could be 
  wkwebview-engine-local-webserver 
  
  
  On Thu, Aug 20, 2015 at 2:42 PM, Carlos Santana csantan...@gmail.com 
  wrote: 
  
  What about 2 plugins? 
  
  Maybe more clear for the developer can add one or the other 
  
  wkengine-file (only supported on iOS 9+) 
  wkengine-webserver (only supported iOS8, iOS9 and higher) 
  
  
  
  
  People that don't want to use the webserver might be annoyed to have 
 dead 
  code link. 
  
  - Carlos 
  Sent from my iPhone 
  
  On Aug 20, 2015, at 3:11 PM, Shazron shaz...@gmail.com wrote: 
  
  Ok re-capping the proposal, we need to move on this: 
  
  1. Recommend UIWebView usage on iOS 8 and below 
  2. Recommend WKWebView usage on iOS 9 only (using file:// loading) and 
  the 
  plugin will support this 
  3. WKWebView usage using local web server supported through a 
 preference 
  (will only work on iOS 8 and above) 
  
  As a consequence of #3: 
  a) The local webserver plugin will always be installed when you install 
  the 
  wkwebview-engine plugin 
  b) The local webserver plugin code will be always be linked into your 
 app 
  executable, so the symbols will always be there. There will be no 
  runtime/memory impact if the pref is off 
  c) we can't make local-webserver dependency depend on iOS 8 only, some 
  would want to use #3 for iOS 8 and above, for example 
  
  
  On Wed, Aug 5, 2015 at 3:15 PM, julio cesar sanchez  
  jcesarmob...@gmail.com 
  wrote: 
  
  You are right, sorry, I haven't looked into the pluggable webviews 
 yet. 
  
  After looking into the WKWebView engine plugin I've seen that the 
 local 
  webserver is a dependency, I thought it was included inside the plugin 
  (as 
  the one from Eddy). 
  
  So, the way to go is remove the dependency and make it only available 
  for 
  iOS 9? and if the user want to use it on iOS 8 then he install the 
  webserver plugin manually and maybe add a preference on the WKWebView 
  engine plugin? or is there a way that the preference (or an install 
  param) 
  can install the webserver plugin with a hook or something? 
  
  
  2015-08-05 8:30 GMT+02:00 Shazron shaz...@gmail.com: 
  
  I don't think that is a good idea. The reason why WKWebView is a 
 plugin 
  is 
  the faster update cycle. This is the total point of the new 4.x 
  release: 
  pluggable webviews. If the current UIWebView implementation is buggy, 
  someone could *potentially* update that also. 
  
  On Wed, Aug 5, 2015 at 1:44 PM, julio cesar sanchez  
  jcesarmob...@gmail.com 
  wrote: 
  
  My idea: 
  
  Make iOS 9 use WKWebView as default without plugin and iOS 8 and 
  previous 
  use UIWebView, then if people want WKWebView on iOS 8 they install 
 the 
  existing plugin with the webserver 
  
  2015-08-05 5:54 GMT+02:00 Shazron shaz...@gmail.com: 
  
  +1 Carlos 
  
  On Wednesday, August 5, 2015, Carlos Santana  
 csantan...@gmail.com 
  wrote: 
  
  I would like to see by default or configuration setting be able to 
  have 
  that combination WKWebView plugin only works on iOS 9 and older 
  iOSes 
  fallback to UIWebView 
  
  I can already hear customers asking too many questions about 
  running 
  a 
  webserver inside their app (i.e. security, energy, old hacks on 
  their 
  own 
  custom plugins, etc). I prefer to have the option to tell them 
  it's a 
  choice it's very easy to select to not have a webserver at all. 
  
  - Carlos 
  Sent from my iPhone 
  
  On Aug 4, 2015, at 8:16 PM, Shazron shaz...@gmail.com 
  javascript:; 
  wrote: 
  
  My thinking -- It'll be a hybrid approach - iOS 8 uses local-web 
  server, 
  iOS 9 doesn't. We'll have to support both if the dev deploys to 
  an 
  older 
  target (the final fallback is UIWebView) 
  
  Either that or WKWebView plugin only works on iOS 9 and older 
  iOSes 
  fallback to UIWebView. 
  
  On Wednesday, August 5, 2015, Edna Y Morales  
  eymor...@us.ibm.com 
  javascript:; wrote: 
  
  
  Hi all, 
  
  Since the file:// url loading bug was fixed for WKWebView in iOS 
  9, 
  are 
  we 
  going to move away from the local webserver solution? 
  
  Thanks, 
  Edna Morales 
  - 
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org 
  javascript:; 
  For additional commands, e-mail: dev-h...@cordova.apache.org 
  javascript:;

Re: Issue in config.xml passing

2015-08-24 Thread Tommy-Carlos Williams

Gah. Answered and didn't see you already had, Rob :)



 On 25 Aug 2015, at 02:29, Rob Paveza rob.pav...@microsoft.com wrote:
 
 Hi Abid,
 
 Your version value is in Smart Quotes, i.e., angle quotes, like you would get 
 from writing code in Word or Outlook:
 
 id=com.sparteqz.ezone version=“1.3.1”
 
 Change those back in your text editor and you should be good.
 
 -Rob
 
 From: Abid Kh a...@sparteqz.com
 Sent: Sunday, August 23, 2015 10:50 PM
 To: dev@cordova.apache.org
 Subject: Fwd: Issue in config.xml passing
 
 -- Forwarded message --
 From: Abid Kh a...@sparteqz.com
 Date: Mon, Aug 24, 2015 at 11:05 AM
 Subject: Issue in config.xml passing
 To: issues-h...@cordova.apache.org, dev-h...@cordova.apache.org
 
 
 
 Sir, I need to update my apk in playstore. So i changed my version in
 config.xml as usual. But now it throw errorrs in parsing config.xml.
 
 Also i tried new project and build it. it worked fine fo me. But When i
 change version of new project same errors thrown. So please help me
 
 
 CLI
 ==
 
 Nazims-MacBook-Pro:ezone abid$ cordova build android
 
 Parsing /Users/abid/Android/phonegap/ezone/config.xml failed
 
 Error: Unquoted attribute value
 
 Line: 1
 
 Column: 41
 
 Char: “
 
at error
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/node_modules/elementtree/node_modules/sax/lib/sax.js:347:8)
 
at strictFail
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/node_modules/elementtree/node_modules/sax/lib/sax.js:364:22)
 
at Object.write
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/node_modules/elementtree/node_modules/sax/lib/sax.js:913:11)
 
at XMLParser.feed
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/node_modules/elementtree/lib/parsers/sax.js:48:15)
 
at ElementTree.parse
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/node_modules/elementtree/lib/elementtree.js:271:10)
 
at Object.exports.XML
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/node_modules/elementtree/lib/elementtree.js:606:13)
 
at Object.module.exports.parseElementtreeSync
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/util/xml-helpers.js:123:38)
 
at Object.ConfigParser
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/configparser/ConfigParser.js:33:24)
 
at getScriptsFromConfigXml
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/hooks/scriptsFinder.js:108:21)
 
at getApplicationHookScripts
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/hooks/scriptsFinder.js:56:17)
 
 Nazims-MacBook-Pro:ezone abid$
 
 
 
 
 Config.xml
 
 ==
 
 
 ?xml version='1.0' encoding='utf-8'?
 
 widget id=com.sparteqz.ezone version=“1.3.1” xmlns=
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.w3.org%2fns%2fwidgetsdata=01%7c01%7cROPAVE%40exchange.microsoft.com%7c7f156d63cba3426177c108d2aca0981b%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=WsrxkgXR4ahRr9DXajnxu%2fAoyOGMxKt7yUJleELz1EU%3d;
  
 xmlns:cdv=https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordova.apache.org%2fns%2f1.0data=01%7c01%7cROPAVE%40exchange.microsoft.com%7c7f156d63cba3426177c108d2aca0981b%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=NxlYMsj7Xx2aKOossViPx%2bXAhN7Ngi6zRmRkjvX1z9M%3d;
 
nameEzone/name
 
description
 
A sample Apache Cordova application that responds to the
 deviceready event.
 
/description
 
author email=dev@cordova.apache.org 
 href=https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordova.iodata=01%7c01%7cROPAVE%40exchange.microsoft.com%7c7f156d63cba3426177c108d2aca0981b%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=DV822%2fNVS0qN%2fDYlzYzZnzCT5%2fL6AW0j6wxZyw4V2N4%3d;
 
Apache Cordova Team
 
/author
 
content src=index.html /
 
plugin name=cordova-plugin-whitelist version=“3” /
 
access origin=* /
 
allow-intent href=http://*/*; /
 
allow-intent href=https://*/*; /
 
allow-intent href=tel:* /
 
allow-intent href=sms:* /
 
allow-intent href=mailto:*; /
 
allow-intent href=geo:* /
 
platform name=android
 
allow-intent href=market:* /
 
/platform
 
platform name=ios
 
allow-intent href=itms:* /
 
allow-intent href=itms-apps:* /
 
/platform
 
 /widget
 
 
 
 Please solve my problems
 --
 *Warm Regards,*
 
 *A R Abid*
 
 *---*
 
 *Founder/CTO*
 
 
 *MOB: **+91 9895971627* a...@sparteqz.com
 *SKYPE: abikh.kunnil786*
 
 
 
 
 --
 *Warm Regards,*
 
 *A R Abid*
 
 *---*
 
 *Founder/CTO*
 
 
 *MOB: **+91 9895971627* a...@sparteqz.com
 *SKYPE: abikh.kunnil786*
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Issue in config.xml passing

2015-08-24 Thread Tommy-Carlos Williams

Just off the top of my head, are the quotes in the version attribute smart 
quotes like from a word processor, etc?

id=com.sparteqz.ezone version=“1.3.1”

They certainly appear to be in the config.xml included below...



 On 24 Aug 2015, at 15:50, Abid Kh a...@sparteqz.com wrote:
 
 widget id=com.sparteqz.ezone version=“1.3.1” xmlns=

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

Re: CB-9496 - Quick sanity check...

2015-08-19 Thread tommy-carlos williams

So can someone look at merging this in then?

:)

Or am I OK to merge my own PR if everyone (well, Joe and Carlos) are happy with 
it? 


On 18 August 2015 at 12:04:55, tommy-carlos williams (to...@devgeeks.org) wrote:

I think they just should have been in the plugin all along… 

If it’s not needed by most apps, it’s kinda annoying to have to remove them 
manually :)


On 18 August 2015 at 11:59:25, Joe Bowser (bows...@gmail.com) wrote:

That makes sense if the Network Information API is present in Crosswalk.
I'm really wondering how this will work with Marshmallow.



On Mon, Aug 17, 2015 at 6:57 PM tommy-carlos williams to...@devgeeks.org
wrote:

 I noticed that my app had gained two new permissions on Android and hunted
 them down to an addition for Crosswalk[1] that really should be in the
 Crosswalk plugin itself.

 I added the permissions to the Crosswalk plugin, now I want to remove them
 from cordova-android’s templates[3][4]

 I just want to make sure there would be no reason to keep these in.


 1.
 https://github.com/apache/cordova-android/commit/4a67dd2e28aed257c85b75c11026ae7a2a19c2ad
 2.
 https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/pull/43
 3. https://issues.apache.org/jira/browse/CB-9496
 4. https://github.com/apache/cordova-android/pull/206

Re: CB-9496 - Quick sanity check...

2015-08-17 Thread tommy-carlos williams

I think they just should have been in the plugin all along… 

If it’s not needed by most apps, it’s kinda annoying to have to remove them 
manually :)


On 18 August 2015 at 11:59:25, Joe Bowser (bows...@gmail.com) wrote:

That makes sense if the Network Information API is present in Crosswalk.  
I'm really wondering how this will work with Marshmallow.  



On Mon, Aug 17, 2015 at 6:57 PM tommy-carlos williams to...@devgeeks.org  
wrote:  

 I noticed that my app had gained two new permissions on Android and hunted  
 them down to an addition for Crosswalk[1] that really should be in the  
 Crosswalk plugin itself.  
  
 I added the permissions to the Crosswalk plugin, now I want to remove them  
 from cordova-android’s templates[3][4]  
  
 I just want to make sure there would be no reason to keep these in.  
  
  
 1.  
 https://github.com/apache/cordova-android/commit/4a67dd2e28aed257c85b75c11026ae7a2a19c2ad
   
 2.  
 https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/pull/43 
  
 3. https://issues.apache.org/jira/browse/CB-9496  
 4. https://github.com/apache/cordova-android/pull/206

CB-9496 - Quick sanity check...

2015-08-17 Thread tommy-carlos williams

I noticed that my app had gained two new permissions on Android and hunted them 
down to an addition for Crosswalk[1] that really should be in the Crosswalk 
plugin itself.

I added the permissions to the Crosswalk plugin, now I want to remove them from 
cordova-android’s templates[3][4]

I just want to make sure there would be no reason to keep these in.


1. 
https://github.com/apache/cordova-android/commit/4a67dd2e28aed257c85b75c11026ae7a2a19c2ad
2. https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/pull/43
3. https://issues.apache.org/jira/browse/CB-9496
4. https://github.com/apache/cordova-android/pull/206

Re: Cordova Face to Face meeting

2015-08-17 Thread tommy-carlos williams

FOMO!

:(

Enjoy… 


On 18 August 2015 at 06:57:27, julio cesar sanchez (jcesarmob...@gmail.com) 
wrote:

I can't go, too far, too expensive and not much vacation left.  
Take notes and share them with the ones that can't go.  

Have fun!  

El lunes, 17 de agosto de 2015, Jesse purplecabb...@gmail.com escribió:  

 Done.  
  
  
  
  On Aug 17, 2015, at 10:29 AM, Steven Gill stevengil...@gmail.com  
 javascript:; wrote:  
   
  Last chance to enter availability in doodle for the face to face. Doodle:  
  http://doodle.com/58peh49rqm2tbyhm. I am closing it tomorrow so we can  
 try  
  to finalize the dates and book flights.  
   
  On Fri, Aug 7, 2015 at 4:08 PM, Carlos Santana csantan...@gmail.com  
 javascript:; wrote:  
   
  I think 2 days is a good idea it will give a chance to have a social  
 night  
  #jsdrinking  
   
  I think I'm the last person to suggest since I'm wrestling with the fax  
  machine here :-)  
  On Fri, Aug 7, 2015 at 6:14 PM Carlos Santana csantan...@gmail.com  
 javascript:;  
  wrote:  
   
  Yeah I would preferred more than a day. It would be hard to justify the  
  business trip from North Carolina for a single day  
   
  We are looking into sending two folks.  
   
  - Carlos  
  Sent from my iPhone  
   
  On Aug 7, 2015, at 5:51 PM, Steven Gill stevengil...@gmail.com  
 javascript:;  
  wrote:  
   
  I'd be open to 2 days but 1 could work to.  
   
  Maybe something like:  
  Day 1: intros, roadmap planning, identify pain points, etc  
  Day 2: split into smaller teams and try to solve some of the concerns  
  from  
  day 1.  
   
  On Fri, Aug 7, 2015 at 2:48 PM, Parashuram N panar...@microsoft.com  
 javascript:;  
  wrote:  
   
  I am guessing that this would be a one day meeting.  
   
  -Original Message-  
  From: Carlos Santana [mailto:csantan...@gmail.com javascript:;]  
  Sent: Friday, August 7, 2015 2:25 PM  
  To: dev@cordova.apache.org javascript:;  
  Subject: Re: Cordova Face to Face meeting  
   
  How many days are we planning to meet? I'm writing the travel request  
  by  
  hand to send the fax :-)  
   
   
  On Thu, Aug 6, 2015 at 9:42 PM Masahiro Tanaka masah...@asial.co.jp  
 javascript:;  
  wrote:  
   
  I'm in! :)  
   
  On Fri, 07 Aug 2015 08:37:50 +0900, Steven Gill  
  stevengil...@gmail.com javascript:;  
  wrote:  
   
  Doodle:  
  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdood  
  le.com%2f58peh49rqm2tbyhmdata=01%7c01%7cpanarasi%40microsoft.com  
  %7c  
   
 3fa83cc33aeb446a585708d29f6ebe75%7c72f988bf86f141af91ab2d7cd011db47%  
  7c1sdata=Vq5pSYf1esq4Nw1%2fYJmbPEYP4kvZrbPHJhBfgWy18j0%3d  
   
  On Thu, Aug 6, 2015 at 4:17 PM, Parashuram N  
  panar...@microsoft.com javascript:;  
  wrote:  
   
  Sorry for dropping the ball here - Microsoft can host this in  
  October. I will start working with my Corporate facilities team to  
  get the place where we can meet, and let you guys know the  
 details.  
   
  Would it be safe to assume that there will be approx. 30 people at  
  the meeting ?  
  Steve, please do start a doodle for this.  
   
  -Original Message-  
  From: Tim Barham [mailto:tim.bar...@microsoft.com javascript:;]  
  Sent: Thursday, August 6, 2015 4:08 PM  
  To: dev@cordova.apache.org javascript:;  
  Subject: RE: Cordova Face to Face meeting  
   
  I'll be there! Looking forward to it.  
   
  -Original Message-  
  From: Jesse [mailto:purplecabb...@gmail.com javascript:;]  
  Sent: Friday, August 7, 2015 8:25 AM  
  To: dev@cordova.apache.org javascript:;  
  Subject: Re: Cordova Face to Face meeting  
   
  Yes!  
   
   
   
  My team is hiring!  
  @purplecabbage  
  https://na01.safelinks.protection.outlook.com/?url=risingj.comdata  
  =01%7c01%7cpanarasi%40microsoft.com  
  %7c3fa83cc33aeb446a585708d29f6eb  
   
 e75%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=PHqR%2bUh%2bsPBfg0  
  lU8kpQVavrBk9E4flFB%2fiUIipcSqM%3d  
   
  On Thu, Aug 6, 2015 at 2:59 PM, Steven Gill  
  stevengil...@gmail.com javascript:;  
  wrote:  
   
  Does October timeframe look okay for Microsoft to host? I can  
  send out a doodle.  
   
  On Sat, Jul 25, 2015 at 8:59 AM, Raymond Camden  
  raymondcam...@gmail.com javascript:;  
  wrote:  
   
  I'd love to do this too (and like Carlos, need to ask  
  permission of course ;). October works for me too, just not  
 9-11.  
   
  On Wed, Jul 22, 2015 at 10:26 PM, Carlos Santana  
  csantan...@gmail.com javascript:;  
  wrote:  
  She is a school psychologist so her chances of finding this  
  mailing is almost zero :-) On Wed, Jul 22, 2015 at 10:55 PM  
  Dmitry Blotsky   
  dblot...@microsoft.com javascript:;  
  wrote:  
   
  This is a publicly-archived mailing list, so the element of  
  surprise  
  is  
  now lost. ;)  
   
  On Jul 22, 2015, at 4:00 PM, Carlos Santana  
  csantan...@gmail.com javascript:;  
  wrote:  
   
  oh heck go to vacation there, and then surprise wife that  
  a 2 day  
  work  
  meeting just came up

Re: Cordova July Hangout

2015-07-16 Thread Tommy-Carlos Williams

Alarm set for 4:30am. 

Better go to bed now ;)



 On 16 Jul 2015, at 21:20, Carlos Santana csantan...@gmail.com wrote:
 
 Looking forward to Hangout today, I will bring doughnuts :-)
 On Mon, Jul 13, 2015 at 10:42 AM Vladimir Kotikov (Akvelon) 
 v-vlk...@microsoft.com wrote:
 
 Hey, guys. I've just opened a PR (
 https://github.com/cordova/cordova-discuss/pull/12) with high level
 overview of cordova-lib refactoring proposal, so anyone interested may get
 familiar with it. Feel free to leave your questions and notes, to be able
 to discuss them during hangout.
 
 ---
 Best regards, Vladimir
 
 -Original Message-
 From: tommy-carlos williams [mailto:to...@devgeeks.org]
 Sent: Thursday, 9 July, 2015 3:30
 To: dev@cordova.apache.org
 Subject: RE: Cordova July Hangout
 
 Thanks, Nikhil.
 
 Looking forward to it.
 
 
 --
 tommy-carlos williams
 
 On 9 July 2015 at 08:18:24, Nikhil Khandelwal (nikhi...@microsoft.com)
 wrote:
 
 I'm closing the doodle now. Thursday July 16th 12 - 2 PM PST has the
 maximum folks. Please add it to your calendars. I will send out a hangout
 link closer to the event.
 
 Thanks,
 Nikhil
 
 
 -Original Message-
 From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
 Sent: Tuesday, July 7, 2015 1:50 PM
 To: dev@cordova.apache.org
 Subject: RE: Cordova July Hangout
 
 In case you are interested in this and have not responded. Here's the
 doodle link:
 http://doodle.com/vut5qrb4gy7dtmw9
 
 I plan to close this by tomorrow and send out the final date/time. Thanks!
 
 Thanks,
 Nikhil
 
 
 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Monday, July 6, 2015 10:16 AM
 To: dev@cordova.apache.org
 Subject: Re: Cordova July Hangout
 
 Let's do it!
 On Jul 1, 2015 10:57 AM, Nikhil Khandelwal nikhi...@microsoft.com
 wrote:
 
 I was wondering if it is a good time for a hangout. Here are few good
 topics for discussion:
 1. Re-working cordova-lib - cordova platform interactions.
 Review new API - Vladimir
 https://github.com/cordova/cordova-discuss/pull/9
 2. Status of testing infrastructure - what are the next steps here ?
 Is there scope for consolidation  fixing failing tests? Better
 release testing. - Dmitry 3. Documentation website and workflow
 improvements - Dmitry
 https://github.com/cordova/cordova-discuss/pull/11
 4. iOS 4 release - status update - Shazron 5. Browserify updates -
 Steve Gill 6. Cordova plugin npm search - Demo  next steps - Murat
 https://github.com/cordova/cordova-discuss/issues/7
 
 Feel free to add to this list:
 https://docs.google.com/document/d/1Ig-qAyIbqKPtTCGkYaqJ2VYufPweTGDm5A
 w-dFGpjRc/edit
 
 I propose we meet in the week of 7/13. Here's the doodle for this:
 http://doodle.com/vut5qrb4gy7dtmw9
 
 Thanks,
 Nikhil
 
 (I understand folks for Adobe are out this week - hopefully we can see
 some responses next week to meet the week after)
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 

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

RE: Cordova July Hangout

2015-07-16 Thread tommy-carlos williams

That is just the public link, yeah?


-- 
tommy-carlos williams

On 17 July 2015 at 05:40:17, Parashuram N (panar...@microsoft.com) wrote:

Steve has created a new link. 
https://plus.google.com/events/cu7bp8n2adp53rkmg2e8o5jd4vk  

-Original Message-  
From: Andrey Kurdumov [mailto:kant2...@googlemail.com]  
Sent: Thursday, July 16, 2015 12:38 PM  
To: dev@cordova.apache.org  
Subject: Re: Cordova July Hangout  

Old link not working, would you post new one?  


2015-07-17 1:32 GMT+06:00 Rob Paveza rob.pav...@microsoft.com:  

 We'll have it back momentarily, we just noticed as well.  
   
 From: Andrey Kurdumov kant2...@googlemail.com  
 Sent: Thursday, July 16, 2015 12:31 PM  
 To: dev@cordova.apache.org  
 Subject: Re: Cordova July Hangout  
  
 Does hangout on air stopped?  
  
 2015-07-17 1:12 GMT+06:00 Parashuram N panar...@microsoft.com:  
  
  I think we can add items to the agenda. Docs is indeed a good thing  
  to discuss.  
   
  -Original Message-  
  From: Andrey Kurdumov [mailto:kant2...@googlemail.com]  
  Sent: Thursday, July 16, 2015 12:10 PM  
  To: dev@cordova.apache.org  
  Subject: Re: Cordova July Hangout  
   
  Maybe it is too late, but ask anyway. Any change to look/participate  
  at the conversation, since I particularly interested in the Docs part?  
   
  2015-07-17 0:36 GMT+06:00 Nikhil Khandelwal nikhi...@microsoft.com:  
   
   Hangout link here:  
   https://plus.google.com/hangouts/_/gtsa5mhzwcxdaj4n5pfadet5hia  

   -Nikhil  

   -Original Message-  
   From: Tommy-Carlos Williams [mailto:to...@devgeeks.org]  
   Sent: Thursday, July 16, 2015 4:57 AM  
   To: dev@cordova.apache.org  
   Subject: Re: Cordova July Hangout  

   Alarm set for 4:30am.  

   Better go to bed now ;)  



On 16 Jul 2015, at 21:20, Carlos Santana csantan...@gmail.com  
 wrote:  
 
Looking forward to Hangout today, I will bring doughnuts :-) On  
Mon, Jul 13, 2015 at 10:42 AM Vladimir Kotikov (Akvelon)   
v-vlk...@microsoft.com wrote:  
 
Hey, guys. I've just opened a PR (  
https://github.com/cordova/cordova-discuss/pull/12) with high  
level overview of cordova-lib refactoring proposal, so anyone  
interested may get familiar with it. Feel free to leave your  
questions and notes, to be able to discuss them during hangout.  
 
---  
Best regards, Vladimir  
 
-Original Message-  
From: tommy-carlos williams [mailto:to...@devgeeks.org]  
Sent: Thursday, 9 July, 2015 3:30  
To: dev@cordova.apache.org  
Subject: RE: Cordova July Hangout  
 
Thanks, Nikhil.  
 
Looking forward to it.  
 
 
--  
tommy-carlos williams  
 
On 9 July 2015 at 08:18:24, Nikhil Khandelwal  
(nikhi...@microsoft.com)  
wrote:  
 
I'm closing the doodle now. Thursday July 16th 12 - 2 PM PST  
has the maximum folks. Please add it to your calendars. I will  
send out a hangout link closer to the event.  
 
Thanks,  
Nikhil  
 
 
-Original Message-  
From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]  
Sent: Tuesday, July 7, 2015 1:50 PM  
To: dev@cordova.apache.org  
Subject: RE: Cordova July Hangout  
 
In case you are interested in this and have not responded.  
Here's the doodle link:  
http://doodle.com/vut5qrb4gy7dtmw9  
 
I plan to close this by tomorrow and send out the final date/time.  
   Thanks!  
 
Thanks,  
Nikhil  
 
 
-Original Message-  
From: Steven Gill [mailto:stevengil...@gmail.com]  
Sent: Monday, July 6, 2015 10:16 AM  
To: dev@cordova.apache.org  
Subject: Re: Cordova July Hangout  
 
Let's do it!  
On Jul 1, 2015 10:57 AM, Nikhil Khandelwal  
nikhi...@microsoft.com  
wrote:  
 
I was wondering if it is a good time for a hangout. Here are  
few good topics for discussion:  
1. Re-working cordova-lib - cordova platform interactions.  
Review new API - Vladimir  
https://github.com/cordova/cordova-discuss/pull/9  
2. Status of testing infrastructure - what are the next steps  
here  
 ?  
Is there scope for consolidation  fixing failing tests?  
Better release testing. - Dmitry 3. Documentation website and  
workflow improvements - Dmitry  
https://github.com/cordova/cordova-discuss/pull/11  
4. iOS 4 release - status update - Shazron 5. Browserify  
updates - Steve Gill 6. Cordova plugin npm search - Demo   
next steps - Murat  
https://github.com/cordova/cordova-discuss/issues/7  
 
Feel free to add to this list:  
https://docs.google.com/document/d/1Ig-qAyIbqKPtTCGkYaqJ2VYufP  
weTG  
Dm  
5A  
w-dFGpjRc/edit  
 
I propose we meet in the week of 7/13. Here's the doodle for this:  
http://doodle.com

RE: Cordova July Hangout

2015-07-08 Thread tommy-carlos williams

Thanks, Nikhil.

Looking forward to it.


-- 
tommy-carlos williams

On 9 July 2015 at 08:18:24, Nikhil Khandelwal (nikhi...@microsoft.com) wrote:

I'm closing the doodle now. Thursday July 16th 12 - 2 PM PST has the maximum 
folks. Please add it to your calendars. I will send out a hangout link closer 
to the event.  

Thanks,  
Nikhil  


-Original Message-  
From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]  
Sent: Tuesday, July 7, 2015 1:50 PM  
To: dev@cordova.apache.org  
Subject: RE: Cordova July Hangout  

In case you are interested in this and have not responded. Here's the doodle 
link:  
http://doodle.com/vut5qrb4gy7dtmw9  

I plan to close this by tomorrow and send out the final date/time. Thanks!  

Thanks,  
Nikhil  


-Original Message-  
From: Steven Gill [mailto:stevengil...@gmail.com]  
Sent: Monday, July 6, 2015 10:16 AM  
To: dev@cordova.apache.org  
Subject: Re: Cordova July Hangout  

Let's do it!  
On Jul 1, 2015 10:57 AM, Nikhil Khandelwal nikhi...@microsoft.com wrote:  

 I was wondering if it is a good time for a hangout. Here are few good  
 topics for discussion:  
 1. Re-working cordova-lib - cordova platform interactions.  
 Review new API - Vladimir  
 https://github.com/cordova/cordova-discuss/pull/9  
 2. Status of testing infrastructure - what are the next steps  
 here ? Is there scope for consolidation  fixing failing tests? Better  
 release testing. - Dmitry  
 3. Documentation website and workflow improvements - Dmitry  
 https://github.com/cordova/cordova-discuss/pull/11  
 4. iOS 4 release - status update - Shazron  
 5. Browserify updates - Steve Gill  
 6. Cordova plugin npm search - Demo  next steps - Murat  
 https://github.com/cordova/cordova-discuss/issues/7  
  
 Feel free to add to this list:  
 https://docs.google.com/document/d/1Ig-qAyIbqKPtTCGkYaqJ2VYufPweTGDm5A  
 w-dFGpjRc/edit  
  
 I propose we meet in the week of 7/13. Here's the doodle for this:  
 http://doodle.com/vut5qrb4gy7dtmw9  
  
 Thanks,  
 Nikhil  
  
 (I understand folks for Adobe are out this week - hopefully we can see  
 some responses next week to meet the week after)  
  
 -  
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org  
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [iOS] cordova-ios 4.0.x branch merge to master

2015-06-18 Thread tommy-carlos williams

Agreed

-- 
tommy-carlos williams

On 19 June 2015 at 08:53:24, Steven Gill (stevengil...@gmail.com) wrote:

Do it!  

On Thu, Jun 18, 2015 at 3:29 PM, Shazron shaz...@gmail.com wrote:  

 I intend to merge the cordova-ios 4.0.x branch to master.  
  
 Most of the remaining issues in  
 https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76  
 are related to the CLI or the wkwebview-engine plugin, not platform issues.  
  
 I'll resolve any outstanding PRs first.  
  
 I still intend to implement Workspaces since I think that's important for  
 4.0.x and will do that in another branch.  
  
 Thoughts?

Re: [iOS 8] WKWebView moving forward

2015-06-14 Thread tommy-carlos williams

I would certainly like to see a test to see what the lag is like...

--
tommy-carlos williams

On 11 June 2015 at 02:01:35, Shazron (shaz...@gmail.com) wrote:

Safari View Controller video:
https://developer.apple.com/videos/wwdc/2015/?id=504

What's New in Web Development in WebKit and Safari video:
https://developer.apple.com/videos/wwdc/2015/?id=501

On Tue, Jun 9, 2015 at 3:59 PM, Shazron shaz...@gmail.com wrote:

I definitely will watch.
Just read about ODR
https://developer.apple.com/library/prerelease/ios/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/Chapters/IntroToODR.html#//apple_ref/doc/uid/TP40015083-CH2-SW1

So we could still use the copy method (fast, small app bundle) and have a
solution in Cordova for ODR for app bundles that are huge. For example, in
the CLI prepare step.

Of course this won't be a universal solution and is more complicated.

On Tuesday, June 9, 2015, Carlos Santana csantan...@gmail.com wrote:

What do we loose, I just attended the session.
I think for most uses is a win at least in the security aspect
Watch the session when the video is available and we can discuss later.

On Tue, Jun 9, 2015 at 1:23 PM Shazron shaz...@gmail.com wrote:

We could use it for InAppBrowser but we might lose some features that we
have possibly.

Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
urls
in Library and Documents, but not the app bundle.
https://twitter.com/wkwebview/status/608359163299819521

On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana csantan...@gmail.com
wrote:

Yay !
There is also a new Safari View Controller, don't know if it's
applicable
to replace wkwebview but at least I think it can be use to build the
next
gen inappbrowser since its beats a makeup in iOS anyway.

The session is in 30 minutes so I'm planning attending.
On Mon, Jun 8, 2015 at 2:33 PM Shazron shaz...@gmail.com wrote:

There is a WWDC session: Safari Extensibility: Content Blocking and
Shared
Links. So I'm hopeful for whitelisting

On Mon, Jun 8, 2015 at 1:22 PM, Shazron shaz...@gmail.com wrote:

Moar news https://twitter.com/wkwebview/status/608005652720451584

On Monday, June 8, 2015, Shazron shaz...@gmail.com wrote:

Cordova developers rejoice, iOS 9 includes the API to load pages
from
file:// urls
https://twitter.com/wkwebview/status/608002548151119872

On Mon, Feb 9, 2015 at 2:19 PM, Shazron shaz...@gmail.com
wrote:

Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade
I
suppose for your dev machines and build servers...

On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
to...@devgeeks.org wrote:
Oh, FFS.

I give up on Apple solving this, personally. Most apps don’t
*actually* need it (they think they do, but they don’t). I am
going
to
find
another way to solve it for our apps… maybe I will actually
have to
write a
native plugin for the crypto :(

--
tommy-carlos williams

On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com)
wrote:

In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
contain
the loadFileURL:readAccessURL: selector that we are all
waiting
for
:'(
https://twitter.com/wkwebview/status/564865657225756672

Re: The Apache Cordova Community Slack channel is up!

2015-06-12 Thread tommy-carlos williams

So, is this community in general as well as dev/pmc?

-- 
tommy-carlos williams

On 13 June 2015 at 07:46:16, Steven Gill (stevengil...@gmail.com) wrote:

Love it!  
On Jun 12, 2015 12:36 PM, Murat Sutunc mura...@microsoft.com wrote:  

 Yeah retrying couple times worked for me earlier :)  
  
 Sent from my iPhone  
  
  On Jun 12, 2015, at 12:15 PM, Shazron shaz...@gmail.com wrote:  
   
  We're using a free heroku instance, might be starved. Try again in a bit.  
   
  On Fri, Jun 12, 2015 at 12:07 PM, Dmitry Blotsky dblot...@microsoft.com  
   
  wrote:  
   
  I’m getting a “something went wrong” error. ):  
   
  - Dmitry  
   
  On Jun 12, 2015, at 11:52 AM, Michael Brooks   
 mich...@michaelbrooks.ca  
  wrote:  
   
  Similar to our other supporting services, I've stored our Slackin  
  implementation on cordova-labs under the branch slack-cordova-io.  
   
  Repository:  
  https://github.com/apache/cordova-labs/tree/slack-cordova-io  
   
  Full deployment instructions:  
  https://github.com/apache/cordova-labs/blob/slack-cordova-io/DEPLOY.md  
   
  I used DEPLOY.md instead of README.md so that we can easily upgrade  
  Slackin  
  in the future without destroying our deployment instructions.  
   
  Cheers,  
  Michael  
   
   
  On Fri, Jun 12, 2015 at 11:46 AM, Shazron shaz...@gmail.com wrote:  
   
  All are welcome. Get your invite:  
  http://slack.cordova.io  
   
  This is a replacement for IRC, but not a replacement for decisions and  
  voting, that still needs to be on the list.  
   
   
  
 -  
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org  
 For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [iOS 8] WKWebView moving forward

2015-06-09 Thread tommy-carlos williams

I hadn’t considered the space issue. Mind you, my apps are like 1.7MB. Not
exactly space hogs. At least the camera and downloads issues would be fixed :(

--
tommy-carlos williams

On 10 June 2015 at 07:04:00, Shazron (shaz...@gmail.com) wrote:

+1 to what Kerri said.
If we did it, it would be in Library/Caches since that is not backed up by
iTunes:
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1

On Tue, Jun 9, 2015 at 1:58 PM, Kerri Shotts kerrisho...@gmail.com wrote:

Speaking as a user who has an iPhone that’s always running near the
storage limit: I’d hate to see files be duplicate out of the bundle into
another location… my phone might cry.

I think we went over that when WKWebview was first released. Copying files
was discussed, but it adds an awful lot of complexity to startup, wastes
space, etc. Looks like the local web server might be the best option, still.

But I guess this gives the option of using web content that the app itself
downloads to /Documents or /Library, so that could be nice. Unfortunate
that they hamstrung it regarding bundles tho. Here’s hoping they’ll change
it, but given the track record in iOS 8, I’m not holding my breath.

On June 9, 2015 at 3:50:09 PM, Ross Gerbasi (rgerb...@gmail.com) wrote:

Would it be a horrible idea to copy files into one of those folders?

On Tue, Jun 9, 2015 at 3:22 PM, Shazron shaz...@gmail.com wrote:

We could use it for InAppBrowser but we might lose some features that we
have possibly.

Anyways, one piece of bad news for WKWebView iOS 9 - you can load file
urls
in Library and Documents, but not the app bundle.
https://twitter.com/wkwebview/status/608359163299819521

On Tue, Jun 9, 2015 at 1:02 PM, Carlos Santana csantan...@gmail.com
wrote:

The session is in 30 minutes so I'm planning attending.
On Mon, Jun 8, 2015 at 2:33 PM Shazron shaz...@gmail.com wrote:

There is a WWDC session: Safari Extensibility: Content Blocking and
Shared
Links. So I'm hopeful for whitelisting

On Mon, Jun 8, 2015 at 1:22 PM, Shazron shaz...@gmail.com wrote:

Moar news https://twitter.com/wkwebview/status/608005652720451584

On Monday, June 8, 2015, Shazron shaz...@gmail.com wrote:

Cordova developers rejoice, iOS 9 includes the API to load pages
from
file:// urls
https://twitter.com/wkwebview/status/608002548151119872

On Mon, Feb 9, 2015 at 2:19 PM, Shazron shaz...@gmail.com
wrote:

Also Xcode 6.3 now *requires* Yosemite. Fair warning to upgrade I
suppose for your dev machines and build servers...

On Mon, Feb 9, 2015 at 2:13 PM, tommy-carlos williams
to...@devgeeks.org wrote:
Oh, FFS.

--
tommy-carlos williams

On 10 February 2015 at 08:18:31, Shazron (shaz...@gmail.com)
wrote:

In other news -- the new Xcode 6.3 beta (iOS 8.3) does *not*
contain
the loadFileURL:readAccessURL: selector that we are all waiting
for
:'(
https://twitter.com/wkwebview/status/564865657225756672

Re: Best place to browse plugins

2015-05-27 Thread Tommy-Carlos Williams

+1



 On 26 May 2015, at 21:44, Carlos Santana csantan...@gmail.com wrote:
 
 I would like to see plugin.cordova.io be a page easy to search and filter
 cordova plugins just like gulp [1], grunt [2], yeoman [3] and bower [4]
 
 [1]: http://gulpjs.com/plugins
 [2]: http://gruntjs.com/plugins
 [3]: http://yeoman.io/generators
 [4]: http://bower.io/search
 
 
 
 On Sat, May 2, 2015 at 3:57 PM Michael Brooks mich...@michaelbrooks.ca
 wrote:
 
 
 The mirroring may not help for search, but my worry is that a lot of
 folks
 would still be on 4.3.0 and when cordova plugins registry becomes read
 only, they would not get bug fixes and other plugin updates.
 
 
 My experience is this:
 
 - A developer who is willing to upgrade a platform is also willing to
 upgrading a plugin.
 - A developer who is *not* willing to upgrade a platform is also *not*
 willing in upgrading a plugin.
 
 I think it's reasonable to offer a read-only state for the legacy plugin
 registry. However, it would be helpful for the registry to explain the
 minimum Cordova version required to support the npm registry.
 
 Michael
 
 On Fri, May 1, 2015 at 9:01 AM, Parashuram N (MS OPEN TECH) 
 panar...@microsoft.com wrote:
 
 The mirroring may not help for search, but my worry is that a lot of
 folks
 would still be on 4.3.0 and when cordova plugins registry becomes read
 only, they would not get bug fixes and other plugin updates.
 
 -Original Message-
 From: Victor Sosa [mailto:sosah.vic...@gmail.com]
 Sent: Friday, May 1, 2015 8:59 AM
 To: dev@cordova.apache.org
 Subject: Re: Best place to browse plugins
 
 I don't see a value on mirroring either. Instead I'd like to see a good
 querying mechanism in NPM, but for that we have to wait :/
 
 2015-05-01 10:55 GMT-05:00 Raymond Camden raymondcam...@gmail.com:
 
 I don't know - if npm is the place, then having a mirror just seems
 like noise. I'd say close it down and put a nice text message up on
 the site explaining where it is at NPM and how to search. (Link to npm
 with the search params included.)
 
 Is there a benefit of having it mirrored?
 
 
 
 On Fri, May 1, 2015 at 10:49 AM, Parashuram N (MS OPEN TECH)
 panar...@microsoft.com wrote:
 It would be even better (for backward compatibility reasons) if we
 could
 simply publish on npm, but keep plugins.cordova.io as a
 mirror/redirector, based on the Cordova registry mapper.
 
 -Original Message-
 From: Gorkem Ercan [mailto:gorkem.er...@gmail.com]
 Sent: Friday, May 1, 2015 8:31 AM
 To: dev@cordova.apache.org
 Subject: Re: Best place to browse plugins
 
 
 What is the plan for plugins.cordova.io for after the CPR is closed?
 Without knowing if there is a good way to retrieve the list/details
 of
 the cordova plugins from npm.
 I would love it if we could keep it as it is with the data from npm.
 --
 Gorkem
 
 On 29 Apr 2015, at 10:57, Raymond Camden wrote:
 
 With plugins at npm now, what is the best place for users to
 browse plugins?
 
 Is it at npm, using the search filter?
 https://www.npmjs.com/browse/keyword/ecosystem:cordova
 
 Is it plugins.cordova.io?
 
 If it is npm, will there be text added to plugins.cordova.io to
 tell folks to start using the npm site?
 
 --
 ===
 === = Raymond Camden, Developer Advocate for MobileFirst at IBM
 
 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden
 
 ---
 -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
 
 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
 
 --
 ==
 = Raymond Camden, Developer Advocate for MobileFirst at IBM
 
 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 
 
 --
 Victor Adrian Sosa Herrera
 IBM Software Engineer
 Guadalajara, Jalisco
 

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

Re: Also moving to a new team

2015-05-07 Thread Tommy-Carlos Williams

:(

That is very sad. You will all be missed. 

Good luck with whatever you do next. 




 On 8 May 2015, at 04:04, Marcel Kinard cmarc...@gmail.com wrote:
 
 Staci Cooper and I are also moving to new positions. There already are 
 backfills here coming up to speed: Karen Tran and James Dubee. You'll be 
 seeing more of them here as time moves forward, joining Edna Morales.
 
 This has been an absolutely awesome group to work with. You're smart, 
 talented, passionate, and you deliver. I can't say that I had a single bad 
 experience here. I will definitely miss it, I hope our paths cross again. 
 Best wishes!
 
 I may be tempted to dabble here in my off-hours. ;-)
 
 -- Marcel Kinard
 
 On May 5, 2015, at 11:15 AM, Andrew Grieve agri...@chromium.org wrote:
 
 As with Michal, you'll be seeing less of me around. My new full-time
 project will be on the Android port of Chrome.
 
 Just want to make it clear that us moving to new teams has nothing to do
 with a lack of faith in the project, but rather is due to needing a change
 of scenery and exciting new projects becoming available here.
 
 I'm super excited to see a new wave of committers joining the project! The
 momentum has certainly picked up:
 - Cordova-android 4.0.0 was huge
 - Plugins to npm was huge
 - Win10 and wkwebview will be massive launches as well!
 
 Great time for Cordova! (or a bad one... you know... if you're measuring
 against the goal of becoming obsolete :P)
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
 For additional commands, e-mail: dev-h...@cordova.apache.org
 

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

Re: FYI - Moving to new team, seeing me less around here

2015-05-04 Thread tommy-carlos williams

Congratulations.

Physical Web sounds interesting. I bet your team will miss you.

Enjoy the new funs!

-- 
tommy-carlos williams

On 5 May 2015 at 05:15:58, Jesse (purplecabb...@gmail.com) wrote:

Congrats Michal! Good for you!  

@purplecabbage  
risingj.com  

On Mon, May 4, 2015 at 11:49 AM, Steven Gill stevengil...@gmail.com wrote:  

 It has been great working with you Michal! Learned a lot. Enjoy your new  
 project! I'm sure you will kill it.  
  
 On Mon, May 4, 2015 at 9:49 AM, Brian LeRoux b...@brian.io wrote:  
  
  Scott is awesome and so is the Physical Web. Huge potential and I'm  
 stoked  
  to hear we now have someone on the inside. ;) Congrats Michal!  
   
  On Mon, May 4, 2015 at 9:38 AM, Shazron shaz...@gmail.com wrote:  
   
   Congrats Michal!  
   Super interesting project.  

   On Mon, May 4, 2015 at 7:52 AM, Michal Mocny mmo...@google.com  
 wrote:  
I've moved to a new team here at Google (Physical Web:  
https://google.github.io/physical-web/).  
 
This means I will likely be speaking up less often going forward,  
  though  
I'll still be keeping an eye on these lists for the foreseeable  
 future.  
 
And I'm itching to write some cordova plugins for the Physical Web...  
 
-Michal  

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

RE: Does Cordova have a problem making developers happy?

2015-04-13 Thread tommy-carlos williams

If no one else has time to do something with this list by the time I get free 
of my current stress-pile (say a couple weeks from now), I would love to take a 
crack at it. An FAQ with not just the list, but actual solutions and examples 
would be a great resource.

Even if someone else does it, I might use it as the basis for a series of blog 
posts or something. It’s such a good summary of people’s frustrations. I would 
probably even have one or two to add from the #phonegap IRC channel.. :/

-- 
tommy-carlos williams

On 14 April 2015 at 08:16:56, Josh Soref (jso...@blackberry.com) wrote:

So, I want someone to make this into a FAQ, somehow.  

I don't have time today, but it's a really great list.  

Bonus points for getting it Stickied at the top of StackOverflow.  

(obviously, it should include some explanation of how to correct these things,  
and thankfully most are pretty easy to address.)  

Some are probably asking for samples (e.g. a how to do things slowly/choppily  
w/ left: vs. how to use CSS transitions -- Raymond?)  

Julio wrote an amazing summary of Cordova Stack Overflow posts:  
 I read most of the questions with cordova tag on stackoverflow and the  
 questions on the google group and I see this problems.  
  
 - Some people don't read the docs  
 - Some people read the wrong docs (they use cordova 2.9.1 because it's the  
 latest they can download, but read the edge docs and things don't work as  
 expected)  
 - Some people follow old tutorials instead of reading the docs and the  
 things have changed a lot and don't work.  
 - Some people don't need cordova but use it anyway, they just want a  
 webview to show their website  
 - Some people use j* ** (I don't want to name it either) and blame  
 cordova for the slowness  
 - With cordova everybody can create apps, but configuring the PATH isn't  
 easy for most people, a lot of questions are realated to this, they didn't  
 configure the PATH, they did it but wrong, they don't know they have to set  
 it (see my first point)  
 - People is still confused about the difference between phonegap, cordova  
 and phonegap build service, I see people using phonegap CLI for local  
 development but try to install the plugins putting the phonegap build  
 plugin config line on the config.xml (again, people don't read or don't  
 understand the docs)  
 - People want to use eclipse (now android studio) for the development, they  
 google and see blog post about a plugin, but that plugin is very old and  
 uses phonegap 1.x.x (see my second point)  
 - People is having troubles connecting with the server, some of them  
 because use localhost as the url, others because they don't configure the  
 whitelist properly, others for unknow reasons.  
 - Some of them discover bugs, but instead of reporting them so it can be  
 fixed, just ask on stackoverflow why it doesn't work.  
 - Most people don't know how to debug, then if something doesn't work just  
 complain.  
 - Some people forget to link the cordova.js file, they create the project  
 and replace the index.html with the index.html of their website.  
 - Some people blame cordova when the problem is the webview (old android  
 devices).  
  
  
 About people that used cordova and are now developing in native, I bet most  
 of them tried cordova on android 2.x.x with j* ** and it was slow,  
 they read the articles about facebook and linkedin dropping html5 and  
 switching to native and did the same, and after the effort they put on  
 learning native development they don't wan't to go back and will tell  
 everybody cordova is bad because it was slow when they tried it years ago.

RE: Jira CB-831: File transfer tests crash on Android L

2015-04-13 Thread tommy-carlos williams

There are lots of multi-sim phones available in AU… 

-- 
tommy-carlos williams

On 14 April 2015 at 06:59:56, Josh Soref (jso...@blackberry.com) wrote:

Joe wrote:  
 No idea. Andrew already upped the API level to 22, which is Android 5.1.  

 In related news, It may make sense to create an issue to add support for  
 multi-SIM phones, but of course nobody has one AFAIK since they only exist  
 in India.  

I think Firefox Flame has support for them, and outside of India.  

http://www.zdnet.com/article/meet-flame-mozillas-170-firefox-os-phone-for-devs/

Re: plugins, npm, and package.json …other art

2015-04-03 Thread tommy-carlos williams

I guess that’s because Android hasn’t been released. Maybe they feel they can’t 
reveal much about it yet :(

-- 
tommy-carlos williams

On 3 April 2015 at 17:41:51, Jesse (purplecabb...@gmail.com) wrote:

Yeah, the more I look at these, the more overlap I see.  
I am surprised how narrowly scoped the react discussion is. iOS only? Is  
Android not even on their radar?  

@purplecabbage  
risingj.com  

On Thu, Apr 2, 2015 at 5:51 PM, Brian LeRoux b...@brian.io wrote:  

 both reactnative [1] and nativescript [2] treading into the territory  
  
 fleeting hope we could share work/code but probably good everyone does a  
 bit of homework on the topic  
  
 [1] https://github.com/facebook/react-native/issues/235  
 [2] https://github.com/NativeScript/NativeScript/issues/25

Re: Keyboard plugin

2015-03-30 Thread tommy-carlos williams

+1

Also, looking forward to these posts, Kerri.

:)

-- 
tommy-carlos williams

On 31 March 2015 at 15:07:29, Kerri Shotts (kerrisho...@gmail.com) wrote:

I noticed this, actually, when working on one of my last books — the fix (or, 
hack, rather) was to install the plugin from a specific commit that didn’t bail 
if it thought iOS shrunk the view. It was frustrating at the time, but I have 
since changed my opinion of KeyboardShinksView = true, on iOS anyway: that’s 
just not how most native apps on iOS work.  

Typically, the size of the view never changes when the keyboard appears — if 
you have a view with a tab bar at the bottom of the view and the keyboard pops 
up, the tab bar doesn’t animate upwards — it stays behind the keyboard and 
never budges. Instead the content area compensates by allowing additional 
scrolling. If you have a translucent keyboard (like from the home screen), this 
is most apparent (you can still tell the content exists below the keyboard.  

So although convenient, it might also be why Apple removed this behavior in 
later iOS versions: because it’s not the way native apps usually behave.  

I’m exploring various options, but I’m getting the most native behavior by 
using a combination of the ionic keyboard plugin with scrolling disabled while 
the keyboard is visible. Because the height of the keyboard is passed to the 
event handler, I can then adjust the size of any scroll containers (either by 
adding padding or by adjusting their heights). This was broken in an earlier 
version of the plugin (wrong heights returned), but as of the current version 
of the plugin, the heights appeared to be reported correctly. It’s a bit more 
work on the dev’s part, and the plugin doesn’t work perfectly in all cases 
(having a hardware keyboard attached still returns an incorrect height). But 
the feeling is so much closer to native. I’m working up some examples that I’ll 
post soon that demonstrate how it works.  

So, my personal preference would be to keep this out of core — if a dev wants 
the shrinkView behavior, they can use a plugin that supports it.  




From: Andrew Grieve agri...@chromium.org  
Reply: dev@cordova.apache.org dev@cordova.apache.org  
Date: March 30, 2015 at 7:33:28 PM  
To: dev dev@cordova.apache.org  
Subject:  Re: Keyboard plugin  

I definitely agree that KeyboardShrinksView makes a tonne more sense for  
apps (as opposed to webpages), and it's what we use on Android. Shame they  
reversed the decision (I didn't actually realize that).  

One reason to keep it as a plugin is that the logic seems to be hard to get  
right and so needs to be tweaked frequently. Plugins let you iterate faster  
than if it were built-in.  

Still, I think we're hoping to reduce the number of plugins that we  
maintain as a part of the core Cordova project, since we really don't do a  
great job at giving them the attention that they deserve (just have a look  
at all the unaddressed PRs against them).  

One of the intended goals (at least IMO) of moving plugins to npm and  
npm-style-naming, is to make less distinction between core cordova  
plugins and community-maintained plugins, so that the higher-quality  
community-maintained plugins get more usage.  

Interested in what others think.  

On Mon, Mar 30, 2015 at 1:07 PM, Connor Pearson cjp...@gmail.com wrote:  

 Hi All,  
  
 It's been a while since the keyboard plugin was discussed. As I understand  
 it, the plugin was moved to Cordova labs after iOS 7 made  
 KeyboardShrinksView the default behavior. Since iOS 7.1 and 8 have reversed  
 this decision, could we revisit this?  
  
 I've done some work to re-enable KeyboardShrinksView for iOS  7.0 and fix  
 some bugs, but is there any support for continuing to maintain this plugin?  
 If not, is there any way to merge the KeyboardShrinksView preference back  
 into cordova-ios? I think it's more commonly used and much more stable than  
 the HideKeyboardFormAccessoryBar preference. As a Cordova user, our app  
 depends on the shrink view behavior. Any thoughts?  
  
 Thanks,  
 Connor

RE: Plugin history purged from registry?

2015-02-13 Thread tommy-carlos williams

This is scary. Is this recoverable?

-- 
tommy-carlos williams

On 14 February 2015 at 09:47:46, Chuck Lantz (cla...@microsoft.com) wrote:

Darryl appears to be correct - I just cleared my .plugman cache and any pinned 
plugins stopped working because it was unable to fetch. That's a big problem.  

-Chuck  

-Original Message-  
From: dvpdin...@gmail.com [mailto:dvpdin...@gmail.com] On Behalf Of Darryl 
Pogue  
Sent: Friday, February 13, 2015 2:14 PM  
To: dev@cordova.apache.org  
Subject: Plugin history purged from registry?  

After the plugins update today, all the old versions of the core plugins have 
disappeared from the registry. Anyone that has projects locked to specific 
versions of plugins is now unable to build.  

For me personally, that means potentially missing legal review deadlines for an 
app because I can't get plugins installed on our build server.  


Also, org.apache.cordova.device was published with the version number 0.3.1-dev 
(while the blog post says it should be version 0.3.0).

Re: [iOS] Intent to delete AppDelegate remote and local notification code in 4.0

2015-02-11 Thread tommy-carlos williams

+1

The email currently says “If your app does not use the Apple Push Notification 
service, no action is required”, but it probably freaks new users out. Also, it 
might become a “thing” in the future.


-- 
tommy-carlos williams

On 12 February 2015 at 10:10:59, Shazron (shaz...@gmail.com) wrote:

See: 
https://github.com/apache/cordova-ios/blob/338ee71f966ab7fdc1ccde02e5086febbc82b70c/bin/templates/project/__PROJECT_NAME__/Classes/AppDelegate.m#L110-L135
  

I'd rather do this in 3.8.0, but we would break things for users, so  
in 4.0 it goes.  

Related issue: https://issues.apache.org/jira/browse/CB-8084 -- causes  
Apple to issue a warning (which could be a blocker in the future) when  
you submit an app, if you don't have the correct entitlements.  

Users wanting this functionality will install a plugin, that will do  
method swizzling to provide this functionality. It's an easy plugin to  
do, which will go in the cordova-plugins repo.  

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

Re: Does this plugin support the current platform?

2015-02-10 Thread tommy-carlos williams

Nice

+1

One change in Cordova is a lot bette than expecting all plugins to change ;)


-- 
tommy-carlos williams

On 11 February 2015 at 07:54:17, Andrew Grieve (agri...@chromium.org) wrote:

Strawman:  

If plugin.xml has *any* platforms, then only apply global tags to those  
platforms.  
If plugin.xml has *no* platforms, then apply global tags to all platforms.  

On Tue, Feb 10, 2015 at 2:18 PM, Tommy Williams to...@devgeeks.org wrote:  

 This won't actually help right now, but that feature detection would  
 actually be possible if the plugin's clobbers was always a child of the  
 platform in plugin.xml.  
  
 Right now, most plugins have their clobbers global to all platforms,  
 supported or not. If the clobbers is a child of the platform, then the  
 relevant js function/object would be undefined on an unsupported platform.  
  
 This practice would also help in a situation where you might want different  
 plugins for different platforms, but exposing similar functionality on one  
 clobbered function/object (eg: the popular barcode scanner plugin + the  
 blackberry barcode scanner plugin).  
  
 Unfortunately, most plugins don't do this, even though it is possible.  
 The natural way to determine whether some functionality is available is to  
 use the feature detection pattern. That is, if you want to call some  
 function normally found at myobj.myfunc, you write code like this:  
  
 If (myobj  (typeof myobj.myfunc === 'function')) ...  
  
 For this to work you must take care to remove plugins that don't support  
 your platform before you build for that platform. For example, before you  
 build for firefoxos, you must remove the barcodescanner plugin (and then  
 add it back when you build for supported platforms). Granted, this is  
 awkward, but I think it's worse to read the package.json file.  
  
 Really the CLI should make the feature detection pattern work without  
 having to exclude plugins on unsupported platforms. That is, if a plugin  
 doesn't support a platform, then it should contribute nothing when you  
 build for that platform.  
  
 Julian  
  
 -Original Message-  
 From: Axel Nennker [mailto:ignisvul...@gmail.com]  
 Sent: Tuesday, February 10, 2015 11:48 AM  
 To: dev  
 Subject: Re: Does this plugin support the current platform?  
  
 And then the app has to load that package.json ?  
 On Feb 10, 2015 5:28 PM, Steven Gill stevengil...@gmail.com wrote:  
  
  Plugin.xml has a platforms tag for what platforms it supports. That  
  info gets uploaded to the Cordova plugins registry when publishing.  
   
  Soon this info will be available in package.json file each plugin has.  
  On Feb 10, 2015 7:25 AM, Axel Nennker ignisvul...@gmail.com wrote:  
   
   Hi,  

   is there a way how an app can determine whether a plugin supports  
   the current platform?  

   E.g.: the barcodescanner plugin is not supporting firefoxos How  
   could an app know that which out hardcoding this into the app?  

   If there is a standard way in Cordova then this is a userland question.  
   If not then this is a feature request to add this info to e.g.  
   cordova/plugin_list exports.metadata ?!  

   -Axel

Re: Plugin management ?

2015-01-22 Thread tommy-carlos williams

Personally, we use an npm script:

https://github.com/SpiderOak/SpiderOakMobileClient/blob/master/package.json#L9-L10

Ours is overly complicated as it pins to versions of plugins as well as using a 
local version of the cordova cli. You could have one much simpler just using 
`postinstall`:

https://github.com/devgeeks/Canvas2ImageDemo/blob/master/package.json#L13

But there is also an experimental save feature of some kind… 

-- 
tommy-carlos williams

On 22 January 2015 at 21:36:59, Stéphane Wirtel (steph...@wirtel.be) wrote:

Hi all,  

In my project, I use a lot of plugins.  

So, is there a small tool or a config file where I can specify my  
dependencies (plugins) and just with a command line, install all my  
plugins ?  

I think to grunt (Gruntfile.js), bower (bower.json) and npm  
(package.json)  

Thank you,  

Stephane  
--  
Stéphane Wirtel - http://wirtel.be - @matrixise  

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

Re: Deprecation Wars: ICS vs Gingerbread

2015-01-07 Thread tommy-carlos williams

It seems to me that if we are only going to drop *one*, that it should be 
Gingerbread first, since it is a lower SDK version.

How can an app support GB and *not* ICS?

Having said that, I am also interested in the discussion of better numbers on 
usage than just the Play Store (even if my gut reaction is always “BURN 2.3 
WITH FIRE”).

-- 
tommy-carlos williams

On 8 January 2015 at 10:39:33, Joe Bowser (bows...@gmail.com) wrote:

Hey  

So, 2015 is here, and we have the new Android Pie Chart:  

http://developer.android.com/about/dashboards/index.html#2015  

Due to two percentage points on ICS and three on Gingerbread, we're stuck  
supporting these platforms for the near future, but it looks like we're in  
the bad spot of them reaching the magic 5% at the same time. Since I don't  
like the idea of automatically dropping 10% of devices, I'm wondering what  
we should deprecate first.  

Also, can we get better numbers for what's out there? Right now we still  
have the only single point of reference, which is the Google Play store.  
This doesn't cover China, or any other emerging markets. That said, things  
like Android One, and vendors like Xiaomi are making KitKat and Lolipop the  
standard. I know that I'm once again touching off a flame war between  
developers who know that these platforms don't get the tests they need to  
be actually considered supported, and various business interests who for  
some unknown reason need this support, but we should have this discussion  
again.  

Thoughts?  

Joe

Re: Deprecation Wars: ICS vs Gingerbread

2015-01-07 Thread tommy-carlos williams

I know they are old, but I have always wanted one, heh.

-- 
tommy-carlos williams

On 8 January 2015 at 12:54:24, Joe Bowser (bows...@gmail.com) wrote:

Those stickers are old! I don't go to Android conferences, sine Android  
devs hate us these days.  

On Wed Jan 07 2015 at 5:53:04 PM Brian LeRoux b...@brian.io wrote:  

 !  
  
 On Wed, Jan 7, 2015, 6:49 PM tommy-carlos williams to...@devgeeks.org  
 wrote:  
  
  
 --  
 tommy-carlos williams  
  
 On 8 January 2015 at 12:37:59, Brian LeRoux (b...@brian.io) wrote:  
  
 I say we go 4.x all in and drop everything below. Time to draw a line.  
  
 On Wed, Jan 7, 2015, 6:24 PM Joe Bowser bows...@gmail.com wrote:  
  
  Also, who actually tests on Gingerbread? Please comment on this thread.  
   
  On Wed Jan 07 2015 at 5:09:49 PM Joe Bowser bows...@gmail.com wrote:  
   
   I'm just mentioning it because my only Android 4.0.3 devices are an  
 ASUS  
   Transformer 2 tablet and a Motorola RAZR phone that did weird things  
 to  
  my  
   computer when I tried installing the extra software to upgrade it.  

   However, if we did deprecate 2.3, I can just flash 4.0.3 on the Nexus  
 S  
   and use that.  


   On Wed Jan 07 2015 at 5:07:27 PM tommy-carlos williams   
  to...@devgeeks.org  
   wrote:  

   It seems to me that if we are only going to drop *one*, that it  
 should  
  be  
   Gingerbread first, since it is a lower SDK version.  

   How can an app support GB and *not* ICS?  

   Having said that, I am also interested in the discussion of better  
   numbers on usage than just the Play Store (even if my gut reaction  
 is  
   always “BURN 2.3 WITH FIRE”).  

   --  
   tommy-carlos williams  

   On 8 January 2015 at 10:39:33, Joe Bowser (bows...@gmail.com)  
 wrote:  

   Hey  

   So, 2015 is here, and we have the new Android Pie Chart:  

   http://developer.android.com/about/dashboards/index.html#2015  

   Due to two percentage points on ICS and three on Gingerbread, we're  
  stuck  
   supporting these platforms for the near future, but it looks like  
 we're  
  in  
   the bad spot of them reaching the magic 5% at the same time. Since I  
  don't  
   like the idea of automatically dropping 10% of devices, I'm  
 wondering  
  what  
   we should deprecate first.  

   Also, can we get better numbers for what's out there? Right now we  
 still  
   have the only single point of reference, which is the Google Play  
 store.  
   This doesn't cover China, or any other emerging markets. That said,  
  things  
   like Android One, and vendors like Xiaomi are making KitKat and  
 Lolipop  
   the  
   standard. I know that I'm once again touching off a flame war  
 between  
   developers who know that these platforms don't get the tests they  
 need  
  to  
   be actually considered supported, and various business interests who  
 for  
   some unknown reason need this support, but we should have this  
  discussion  
   again.  

   Thoughts?  

   Joe

Re: Reason for node_modules in Platform Repos

2014-12-19 Thread tommy-carlos williams

This.

+1


-- 
tommy-carlos williams

On 20 December 2014 at 08:05:53, Brian LeRoux (b...@brian.io) wrote:

yeh, we've been through this in other threads. pin the dep in 
package.json to a version or sha and your problem is solved. the only time 
a node_modules should be checked in, maybe, is in a deployment scenario for 
hosted service type things.

Re: [iOS 8] WKWebView moving forward

2014-11-19 Thread tommy-carlos williams

Shazron,

I just noticed this in the README for the plugin:

However, since requests are made over http, your app's activity may be visible 
to others on the name wi-fi network.”

Is this actually true? Why would traffic to localhost leave the device and be 
visible over the wifi?



-- 
tommy-carlos williams

On 20 November 2014 at 08:18:28, Homer, Tony (tony.ho...@intel.com) wrote:

Ugh. Thanks for the additional information, Shazron.  

I had previously proposed adding a hook (by which I meant a delegate  
method) to CDVPluginResult (that would be called from -  
(CDVPluginResult*)initWithStatus:(CDVCommandStatus)statusOrdinal  
message:(id)theMessage) so that LocalWebServer could (blindly) detect and  
transform urls.  

It seems like it would help with this case, but not be generally useful  
for anything else…  

Tony  

On 11/19/14, 3:23 PM, Shazron shaz...@gmail.com wrote:  

Ideally a general solution like you proposed should work, but I forgot to  
mention that in this case, since we are talking about WKWebView, we can't  
use NSURLProtocol since it is not supported in that framework [1][2]  
  
The only other general way I can see is to require explicit support in  
plugins, they may have to call something in the  
commandDelegate/viewController to transform a url, that can be set by  
another plugin, in this case LocalWebServer (my revised proposal was a  
'push' this is a 'pull').  
  
  
[1] https://issues.apache.org/jira/browse/CB-7049  
[2] http://www.openradar.me/18492325  
  
On Wed, Nov 19, 2014 at 12:00 PM, Homer, Tony tony.ho...@intel.com  
wrote:  
  
 If we are just talking about CB-8032, then I can see that this approach  
is  
 cleaner for the file plugin.  
  
 Regarding local web server plugin in general - what about other plugins  
 such as camera?  
 Doesn¹t there need to be a general solution that will provide  
 compatibility between local web server plugin and any plugin that  
returns  
 a file protocol URL?  
  
 Tony  
  
 On 11/19/14, 12:19 PM, Shazron shaz...@gmail.com wrote:  
  
 I commented on Ian's comment on CB-8032:  
   
  
https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403p  
a  
  
ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm  
en  
 t-14216403  
   
 My goal was to have a loose coupling of this functionality (CDVFile  
need  
 not know about LocalWebServer at all) -- and Ian's comment of this  
change  
 is that would impact all CDVFileSystem instances makes this not an  
ideal  
 solution, what if you have two Cordova WebView instances, etc.  
   
 My revised proposal requires CDVFileSystem to have a delegate that can  
be  
 set. Any class can set it to override the nativeURL behaviour, and  
 CDVFileSystem will call this method in the delegate if available. It  
 achieves the same goal without the potentially undefined behaviour of  
an  
 Obj-C Category.  
   
 The LocalWebServer gets the currently installed File plugin, enumerates  
 all  
 available filesystems, and sets this delegate on each, to its own  
 implementation.  
   
 Tony - I think this is approach is cleaner, and is more maintainable.  
   
 On Wed, Nov 19, 2014 at 6:20 AM, Ian Clelland iclell...@chromium.org  
 wrote:  
   
  On Tue Nov 18 2014 at 2:00:34 PM Jesse purplecabb...@gmail.com  
wrote:  
   
   Shaz's solution has less impact and seems more elegant.  

   // if ([self respondsToSelector:@selector(nativeFullPath:)]) {  

   If no-one ( generically ) has provided the nativeFullPath method,  
then  
  use  
   it as is, otherwise call it.  
   No need for any (direct) dependency between File + LocalServer.  

   
  My first instinct, looking at the code, was that it was wrong,  
exactly  
  because there *is* a dependency. You don't normally add code to a  
base  
  class to change its behaviour when there is a category defined on it.  
  Normally that goes the other way: when you add a category to a base  
 class,  
  all of the code that's relevant to that category is *in the  
category*,  
 and  
  the base class needs to know nothing at all about it, including its  
  existence.  
   
  As I said in the PR, it may be that this really is the cleanest and  
best  
  way to go forward with this; I just wanted to have this discussion  
and  
  figure it out with the community before committing to any  
  hard-to-change-later technical debt. It does become an API surface,  
and  
 we  
  will have to maintain whatever we adopt.  
   
  Ian  
   
   

   @purplecabbage  
   risingj.com  

   On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve  
agri...@chromium.org  
   
   wrote:  

Having the localserver plugin add behaviour to file plugin feels  
 like  
  the  
dependency is in the wrong direction to me.  
 
How about having CDVFile.m do something like:  
 
CDVPlugin* p = [commandDelegate  
getCommandInstance:@LocalServer];  
if (p != nil) {  
nativeURL = [p

Re: Cordova Plugins

2014-11-17 Thread tommy-carlos williams

Cordova / PhoneGap plugin repositories:

http://plugins.cordova.io/
http://plugins.telerik.com/
https://build.phonegap.com/plugins
http://plugreg.com/plugins



-- 
tommy-carlos williams

On 18 November 2014 at 11:03:40, Ryan Finnesey (r...@finnesey.com) wrote:

Where can I find a list of Cordova Plugins? I would like to find out if I can 
interact with the scanner/ imager on Motorola Solutions scanners running 
Windows Embedded Handheld 6.5.  

Sent from my Windows Phone

Re: [iOS 8] WKWebView moving forward

2014-11-10 Thread tommy-carlos williams

I had much less success… it doesn’t play well with other legacy plugins, does 
it?



-- 
tommy-carlos williams

On 11 November 2014 at 03:00:30, Michal Mocny (mmo...@chromium.org) wrote:

Success! I did indeed have to add the framework manually.  

Thanks for instructions.  

On Thu, Nov 6, 2014 at 7:49 PM, Shazron shaz...@gmail.com wrote:  

 There have been major changes to the `wkwebview` branch of `cordova-ios`.  
 The `WKWebView` functionality has been moved to a plugin in the  
 `cordova-plugins` repo.  
  
 So, for now you can do:  
  
 cordova create wkwvtest test.project wkwvtest  
 cd wkwvtest  
 cordova platform add ios@wkwebview --usegit  
 cordova plugin add  
 https://github.com/apache/cordova-plugins.git#master:wkwebview-engine  
  
 Modify the root `config.xml` and edit this value to:  
  
 content src=http://localhost:0; /  
  
 Then:  
  
 cordova emulate  
  
 You might get a build error, this is a `plugman` bug that doesn't install  
 `WebKit.framework` properly even though it is defined in plugin.xml. You  
 might have to do a:  
  
 open -a Xcode platforms/ios  
  
 ...and add the framework manually.  
  
 On Thu, Nov 6, 2014 at 11:15 AM, Shazron shaz...@gmail.com wrote:  
  
  Thanks Tony - I'll look at that PR when I have some time.  
   
  Yesterday I did some major work to isolate the webviews into plugins  
  (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk  
  by extracting the WKWebView items into a plugin, and the core has no  
  dependency on WebKit.framework anymore, plus speedy (well, speedier)  
  updates if it needs updating. The CDVUIWebViewEngine will remain in the  
  core as the default engine. I'm still working on this, but it already  
 works  
  currently. I'm abstracting things out more, and removing code from the  
  CDVViewController which has become unwieldy.  
   
  Swapping out engines would use the preference:  
  preference name=CordovaWebViewEngine value=CDVWKWebViewEngine /  
   
  Any new web engine needs to implement the new CDVWebViewEngineProtocol  
  protocol, and installed as a plugin.  
   
  On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony tony.ho...@intel.com  
 wrote:  
   
  I have already forked it and made the changes in a topic branch.  
  I was originally thinking that I would make 2 topic branches: 1 for  
  localhost-only and 1 for auth tokens.  
  However, after I finished the first set of changes I realized that the  
  second set would be dependent on the first.  
  I’ll submit a pull request tomorrow for you to look at - I’ll be happy  
 to  
  redo it as multiple branches if that makes sense.  
   
  I got a little sidetracked with local web server plugin, but I’ve also  
  forked cordova-ios and made a topic branch from wkwebview.  
  I'll start working on some of the changes I proposed earlier in this  
  thread tomorrow (for plugins like camera that return file:// urls,  
 etc.).  
   
  Tony  
   
  On 11/3/14, 7:23 PM, Shazron shaz...@gmail.com wrote:  
   
  Thanks Tony for all the investigation. Please do fork the local web  
  server  
  plugin and put all your work in topic branches for eventual pull  
 requests  
  to the main repo.  

  This is precisely why the local web server is a plugin, and not in the  
  core. I don't profess to be a security expert, and we can update this  
  plugin to cover most of the security cases or someone else can provide  
  their better plugin. I don't think this needs to be bulletproof, not  
 that  
  we can entirely be (has there ever been a Security Update by Apple that  
  *didn't* include a WebKit vulnerability?)  

  I'd like to get the cordova-ios/wkwebview branch back into the mainline  
  as  
  soon as possible, but under an experimental flag (--experimental ?)  
 for  
  bin/create. This will choose a new template that has WebKit.framework  
 in  
  it, which will also define a macro to conditionally compile the new  
 bits  
  in  
  (I haven't added the macros yet in the topic branch).  




  On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony tony.ho...@intel.com  
  wrote:  

   I spent a lot of time thinking about ways to avoid replay attacks for  
  the  
   local web server plugin this weekend.  

   Specifically, I felt like there should be a way to take advantage of  
  the  
   fact that the client and the server are running in the same process.  
   I thought this might enable some kind of sideband (non-http)  
   authentication possibility.  
   The 2 possibilities I was most interested in, but eventually  
 concluded  
  are  
   not practical were:  
   1. unique token per http request - not practical because there is no  
  per  
   http request event available  
   2. a whitelist of “remote” ports - not practical because there is no  
   simple way to get a list of ports in use by WKWebView  

   After going down this rathole and coming up empty, I reconsidered the  
   original problem and came to the following

Re: [iOS 8] WKWebView moving forward

2014-11-10 Thread tommy-carlos williams

Yeah… I’ll try to report some of it and get back to you.

-- 
tommy-carlos williams

On 11 November 2014 at 09:50:55, Shazron (shaz...@gmail.com) wrote:

Bug report? Or email me personally. Which ones besides the ones that will  
have problems as we discussed on this thread.  

On Mon, Nov 10, 2014 at 2:41 PM, tommy-carlos williams to...@devgeeks.org  
wrote:  

 I had much less success… it doesn’t play well with other legacy plugins,  
 does it?  
  
  
  
 --  
 tommy-carlos williams  
  
 On 11 November 2014 at 03:00:30, Michal Mocny (mmo...@chromium.org) wrote:  
  
 Success! I did indeed have to add the framework manually.  
  
 Thanks for instructions.  
  
 On Thu, Nov 6, 2014 at 7:49 PM, Shazron shaz...@gmail.com wrote:  
  
  There have been major changes to the `wkwebview` branch of `cordova-ios`.  
  The `WKWebView` functionality has been moved to a plugin in the  
  `cordova-plugins` repo.  
   
  So, for now you can do:  
   
  cordova create wkwvtest test.project wkwvtest  
  cd wkwvtest  
  cordova platform add ios@wkwebview --usegit  
  cordova plugin add  
  https://github.com/apache/cordova-plugins.git#master:wkwebview-engine  
   
  Modify the root `config.xml` and edit this value to:  
   
  content src=http://localhost:0; /  
   
  Then:  
   
  cordova emulate  
   
  You might get a build error, this is a `plugman` bug that doesn't install  
  `WebKit.framework` properly even though it is defined in plugin.xml. You  
  might have to do a:  
   
  open -a Xcode platforms/ios  
   
  ...and add the framework manually.  
   
  On Thu, Nov 6, 2014 at 11:15 AM, Shazron shaz...@gmail.com wrote:  
   
   Thanks Tony - I'll look at that PR when I have some time.  

   Yesterday I did some major work to isolate the webviews into plugins  
   (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the  
 risk  
   by extracting the WKWebView items into a plugin, and the core has no  
   dependency on WebKit.framework anymore, plus speedy (well, speedier)  
   updates if it needs updating. The CDVUIWebViewEngine will remain in the  
   core as the default engine. I'm still working on this, but it already  
  works  
   currently. I'm abstracting things out more, and removing code from the  
   CDVViewController which has become unwieldy.  

   Swapping out engines would use the preference:  
   preference name=CordovaWebViewEngine value=CDVWKWebViewEngine /  

   Any new web engine needs to implement the new CDVWebViewEngineProtocol  
   protocol, and installed as a plugin.  

   On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony tony.ho...@intel.com  
  wrote:  

   I have already forked it and made the changes in a topic branch.  
   I was originally thinking that I would make 2 topic branches: 1 for  
   localhost-only and 1 for auth tokens.  
   However, after I finished the first set of changes I realized that the  
   second set would be dependent on the first.  
   I’ll submit a pull request tomorrow for you to look at - I’ll be happy  
  to  
   redo it as multiple branches if that makes sense.  

   I got a little sidetracked with local web server plugin, but I’ve also  
   forked cordova-ios and made a topic branch from wkwebview.  
   I'll start working on some of the changes I proposed earlier in this  
   thread tomorrow (for plugins like camera that return file:// urls,  
  etc.).  

   Tony  

   On 11/3/14, 7:23 PM, Shazron shaz...@gmail.com wrote:  

   Thanks Tony for all the investigation. Please do fork the local web  
   server  
   plugin and put all your work in topic branches for eventual pull  
  requests  
   to the main repo.  
 
   This is precisely why the local web server is a plugin, and not in  
 the  
   core. I don't profess to be a security expert, and we can update this  
   plugin to cover most of the security cases or someone else can  
 provide  
   their better plugin. I don't think this needs to be bulletproof, not  
  that  
   we can entirely be (has there ever been a Security Update by Apple  
 that  
   *didn't* include a WebKit vulnerability?)  
 
   I'd like to get the cordova-ios/wkwebview branch back into the  
 mainline  
   as  
   soon as possible, but under an experimental flag (--experimental ?)  
  for  
   bin/create. This will choose a new template that has WebKit.framework  
  in  
   it, which will also define a macro to conditionally compile the new  
  bits  
   in  
   (I haven't added the macros yet in the topic branch).  
 
 
 
 
   On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony tony.ho...@intel.com  
   wrote:  
 
I spent a lot of time thinking about ways to avoid replay attacks  
 for  
   the  
local web server plugin this weekend.  
 
Specifically, I felt like there should be a way to take advantage  
 of  
   the  
fact that the client and the server are running in the same  
 process.  
I thought this might enable some kind of sideband

Re: adding push notifications to core plugins

2014-10-20 Thread tommy-carlos williams

This



On 20 October 2014 at 11:49:21, Brian LeRoux (b...@brian.io) wrote:

for me its about acknowledging the importance of push notifications to the  
platform and making it a first class citizen  


On Mon, Oct 20, 2014 at 5:13 AM, Gorkem Ercan gorkem.er...@gmail.com  
wrote:  

 On Thu, Oct 16, 2014 at 03:24:26PM -0700, Jesse wrote:  
  Core, or no core, the plugin already exists:  
  https://github.com/phonegap-build/PushPlugin/  
  It works on iOS, Android, BB10, WP8, Windows8, and Amazon Fire OS.  
   
  In my mind, the fact that every device uses it's own messaging service  
  makes this a non-starter. At least for moving to core, and/or adding to  
 the  
  API.  
   
  
 What is the expected benefit of moving a plugin this much mature to  
 core plugins?  
  
  
   
  @purplecabbage  
  risingj.com  
   
  On Thu, Oct 16, 2014 at 1:41 PM, Joe Bowser bows...@gmail.com wrote:  
   
   I bet you that the Android Camera is more terrible than the iOS camera.  

   The big problem with a lot of the plugins is that we make promises  
 that we  
   can't keep. For example, the Android camera only supports JPG, but our  
   docs say that you can take PNG photos, which not only makes very little  
   sense, but isn't possible with the current code without a really big  
   refactor. There's also the whole memory restriction problem that has  
   creeped its ugly head with the Moto G and Moto E, which are lower end  
   devices with a lot of users. The Battery Spec is another example,  
 where  
   the current Android implemntation is unusable, and the W3C Proposal is  
   absolute garbage and unimplementable.  

   I don't want any more core plugins until we finally do our long  
 promised,  
   but forever pushed forward API audit. I know that a push notifications  
   plugin is super tempting, but this is like us adopting another puppy  
 when  
   we have a dead hamster, fish and turtle in our room stinking up the  
 place.  

   On Thu, Oct 16, 2014 at 1:35 PM, Shazron shaz...@gmail.com wrote:  

The Camera (esp iOS) is terrible IMO, we should replace with some  
   standard  
API, like we've talked about before (not sure which spec).  
 
On Thu, Oct 16, 2014 at 1:33 PM, Brian LeRoux b...@brian.io wrote:  
 
 I'm all for code removal. Which plugins tho?  
  
  
 On Thu, Oct 16, 2014 at 1:23 PM, Joe Bowser bows...@gmail.com  
 wrote:  
  
  Do we need more core plugins? We're already pretty terrible at  
supporting  
  what we have on our plate now. I would rather we have less core  
plugins  
  than more.  
   
  On Thu, Oct 16, 2014 at 12:27 PM, Jesse purplecabb...@gmail.com  
   
wrote:  
   
   This one supports everything:  

   https://github.com/phonegap-build/PushPlugin/blob/master/plugin.xml  

   and it is MIT  

   @purplecabbage  
   risingj.com  

   On Thu, Oct 16, 2014 at 12:10 PM, Lorin Beer   
 lorin.b...@gmail.com  
 
  wrote:  

I've been asked about this from multiple sources over the  
 last  
   few  
  weeks.  
Given how important push notifications are for mobile  
 projects, a  
 core  
   push  
notification plugin would be a great addition and another  
   argument  
 for  
   why  
you should use cordova.  
 
On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux b...@brian.io  
   wrote:  
 
 just was discussing w/ Shaz and Jesse…thoughts?  
  
 

   
  
 

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

Re: PhoneGap day

2014-10-17 Thread tommy-carlos williams

I will certainly be there. 




On 18 October 2014 at 12:08:49, Jesse (purplecabb...@gmail.com) wrote:

Who all is coming?  

I will be there for my first ever phonegap day. I've only been working with  
phonegap since 2008 ...  

Cheers,  
Jesse  


@purplecabbage  
risingj.com

Re: Build signed archives using CLI

2014-10-07 Thread tommy-carlos williams

Frederico’s workflow is the same as ours. I would love to see something happen 
To improve this, the less time I spend in Xcode, the happier I am ;)



On 7 October 2014 at 8:48:40, Frederico Galvão 
(frederico.gal...@pontoget.com.br) wrote:

I can already get the ultimate .apk through cordova build android  
--release, but I already have the required .properties properly configured  
in my platform/android folder, specifying the path and name to my  
keystores. The cordova build android --release already gives me the  
signed and ready .apk, all I have to do is upload it to play.google.com.  

I have never, however, used cordova's CLI to build the final artifact for  
iOS (IPA) for iTunes. All I do is run cordova prepare, and use xCode from  
then on to build, package, sign, and upload.  

2014-10-06 16:52 GMT-03:00 Parashuram Narasimhan (MS OPEN TECH)   
panar...@microsoft.com:  

 How about a cordova package command, that would be for packaging the app  
 for the store? Note that different platforms may have different  
 requirements for certs, signing etc. So it may make sense to promote this  
 to a different command and let each command take care of packaging the app  
 for the store. This command will also mean that developers don’t have to go  
 over to the native projects when they finally want to publish their apps to  
 the store.  
  
 -Original Message-  
 From: Josh Soref [mailto:jso...@blackberry.com]  
 Sent: Monday, October 6, 2014 12:46 PM  
 To: dev  
 Subject: Re: Build signed archives using CLI  
  
 if you do:  
 Cordova build --release,  
 The blackberry10 platform will generate a signed image...  
  
 On 10/6/14, 3:18 PM, Andrew Grieve agri...@chromium.org wrote:  
  
 AFAIK, I don't think there's any technical roadblocks. Just need a  
 proposal for how it should look, and then a patch  docs to add it!  
   
 For Android's hot-off-the-press gradle support, you can set an  
 environment variable that points to a .properties file for signing  
 builds. This shows one way to go about it, but I'm not in love with the  
 .properties idea.  
   
 On Mon, Oct 6, 2014 at 2:48 PM, Victor Sosa sosah.vic...@gmail.com  
 wrote:  
   
  Hi community.  
   
  Been looking at this topic and wondering why the build command does  
 not create signed archives. Digging a little bit found a lot of  
 differences in the platforms to create these archives.  
   
  For instance, in Android you need to  
  1. Export your APK in release mode (--release flag) 2. Sign your APK  
  (you already need a RSA key)  
   
  In iOS, you need to:  
  1. Export your APP using --device flag (--release seems to export for  
 emulator only) 2. Either use XCode (UI-based) and sign the archive or  
 use xcrun (headless  
  process)  
   
  Besides these differences, what is preventing Cordova from providing  
  a generic one-way to build these signed, ready-to-publish archives?  
   
  Perhaps I'm missing something here...? I really appreciate your  
 insights on this topic  
   
  Thanks!  
   
  --  
  Victor Adrian Sosa Herrera  
  IBM Software Engineer  
  Guadalajara, Jalisco  
   
  
  
 -  
 To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org  
 For additional commands, e-mail: dev-h...@cordova.apache.org  
  



--  

*Frederico Galvão*  

Diretor de Tecnologia  

PontoGet Inovação Web  


( +55(62) 8131-5720  

* www.pontoget.com.br http://www.pontoget.com/

Re: [iOS 8] Status of WKWebView work

2014-09-09 Thread tommy-carlos williams

OK. I think it’s time to start thinking about workarounds.

On 10 September 2014 at 5:50:00, Shazron (shaz...@gmail.com) wrote:

Well, bad news. I just installed the iOS 8 GM firmware on an iPhone 5 and  
used Xcode 6 GM, and the file:// url bug (assuming it is a bug and not by  
design) is still there.  

http://www.openradar.me/radar?id=5839348817723392  

On Fri, Sep 5, 2014 at 12:48 PM, Shazron shaz...@gmail.com wrote:  

 Clarification:  
 When I said The bridge works great, and plugins work great. this was  
 for loading a html page and plugins using the file:// protocol using  
 WKWebView (as the title of the report implies). The bug I reported was on  
 Device ( iOS beta 4), on Simulator it is *fine* (this info was in the bug  
 report as well).  
  
 *Nothing* has been done using the local web server and proxy (at least  
 nothing checked in). An implementation on how the proxy works can be seen  
 in the PhoneGap Developer App:  
 https://github.com/phonegap/phonegap-app-developer  
  
 See CB-7043 for progress on tasks regarding this.  
  
  
  
 On Fri, Sep 5, 2014 at 11:40 AM, Shazron shaz...@gmail.com wrote:  
  
 I figure I will write this all up before the official release of iOS 8  
 next week (probability high) and everyone asking about support.  
  
 It has stalled because the WKWebView cannot load files using the file://  
 protocol since iOS 8 beta 4.  
  
 This bug has been filed with Apple weeks ago:  
 http://www.openradar.me/radar?id=5839348817723392  
  
 I even checked WebKit check-ins if there was any progress, so far, no:  
  
 http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=datedesc=1
   
 (but it's entirely possible the loading code is in another part of the  
 tree).  
  
 The alternative is to run a local web server, which works great. However,  
 this will open up a can of worms possibly with Apple, I'm not sure.  
  
 The other interesting tidbit is, with WKWebView, for locally loaded files  
 using the file:// protocol, cross-domain restrictions now apply, unlike  
 UIWebView's behaviour. To have the same behaviour as UIWebView, we would  
 need to proxy these requests (modify xhr.open to go to our proxy, which  
 requires the local web server).  
  
 The bridge works great, and plugins work great.

Re: meteor for mobile !

2014-08-21 Thread tommy-carlos williams

Interesting.

I wonder how Apple will be about the Hot Push?

- tommy

On 22 August 2014 at 13:45:24, Carlos Santana (csantan...@gmail.com) wrote:

Glad to see meteorjs supporting Cordova 

https://www.youtube.com/watch?feature=player_detailpagev=zzNoXbv1DX4#t=1496 

https://meteor.hackpad.com/Getting-Started-With-Cordova-Z5n6zkVB1xq 


-- 
Carlos Santana 
csantan...@gmail.com

Re: [iOS 8] Please duplicate this Apple bug report for WKWebView use in Cordova

2014-08-17 Thread tommy-carlos williams

Oh man :(

Also done…

*fingers crossed*

On 17 August 2014 at 7:33:11, Marc Weiner (mhweiner...@gmail.com) wrote:

Done  


On Sat, Aug 16, 2014 at 3:46 AM, julio cesar sanchez jcesarmob...@gmail.com  
 wrote:  

 Done  
  
  
 2014-08-16 4:08 GMT+02:00 Shazron shaz...@gmail.com:  
  
  As you know the more dupes the more attention a bug gets. So if you  
  have an Apple ID, please go to:  
  http://bugreporter.apple.com  
   
  and essentially copy my report:  
  http://openradar.appspot.com/radar?id=5839348817723392  
   
  The test project is here (just point them to the URL):  
  https://github.com/shazron/WKWebViewFIleUrlTest

Re: [iOS 8] Please duplicate this Apple bug report for WKWebView use in Cordova

2014-08-17 Thread tommy-carlos williams

assuming it’s a bug, not a calculated decision...

On 18 August 2014 at 8:21:18, Hazem Saleh (haz...@apache.org) wrote:

Done (problem #18044595).  

Hopefully, iOS team will fix this ugly bug ASAP.  


On Sun, Aug 17, 2014 at 4:24 PM, tommy-carlos williams to...@devgeeks.org  
wrote:  

 Oh man :(  
  
 Also done…  
  
 *fingers crossed*  
  
 On 17 August 2014 at 7:33:11, Marc Weiner (mhweiner...@gmail.com) wrote:  
  
 Done  
  
  
 On Sat, Aug 16, 2014 at 3:46 AM, julio cesar sanchez   
 jcesarmob...@gmail.com  
  wrote:  
  
  Done  
   
   
  2014-08-16 4:08 GMT+02:00 Shazron shaz...@gmail.com:  
   
   As you know the more dupes the more attention a bug gets. So if you  
   have an Apple ID, please go to:  
   http://bugreporter.apple.com  

   and essentially copy my report:  
   http://openradar.appspot.com/radar?id=5839348817723392  

   The test project is here (just point them to the URL):  
   https://github.com/shazron/WKWebViewFIleUrlTest  

   
  
  


--  
Hazem Saleh  

Author of Pro JSF and HTML5 book:  
http://www.amazon.com/Pro-JSF-HTML5-Building-Components/dp/1430250100/  

Author of JavaScript Unit Testing book:  
http://www.amazon.com/dp/1782160620/  

Co-author of (The Definitive Guide to Apache MyFaces and Facelets) book:  
http://www.amazon.com/-/e/B002M052KY  

DeveloperWorks Contributing Author  
https://www.ibm.com/developerworks/mydeveloperworks/blogs/hazem/entry/ibm_developerworks_contributing_author?lang=en_us
  

An Apache committer, IBMer, and a technical speaker  

Twitter: http://www.twitter.com/hazems

Re: Hello Cordova!

2014-08-17 Thread tommy-carlos williams

Welcome!

On 18 August 2014 at 8:59:55, Nikolai Kotchetkov (moto...@gmail.com) wrote:

Hello Cordova! 

My name is Nikolai, and I've been taking part in several Cordova projects 
already mostly by writing plugins for Android. 

At this time I'd like to contribute a small feature to make a plugin 
handling a bit easier :) 
https://github.com/apache/cordova-lib/pull/63 

My ICLA is on it's way to secretary :) 

Best regards, 
Nikolai

Re: Reminder: Cordova Hangout Today @4pm EST, 1pm PST

2014-07-28 Thread tommy-carlos williams

SGTM

On 29 July 2014 at 3:47:57, Jesse (purplecabb...@gmail.com) wrote:

Sounds good! 

@purplecabbage 
risingj.com 


On Mon, Jul 28, 2014 at 10:32 AM, Michal Mocny mmo...@chromium.org wrote: 

 The time worked well for us here, and that Tuesday looks open for me. That 
 next meetup will come quick, but we'll just cut it short if theres nothing 
 to discuss. 
 
 -Michal 
 
 
 On Mon, Jul 28, 2014 at 12:37 PM, Marcel Kinard cmarc...@gmail.com 
 wrote: 
 
  I just posted the YouTube playback link to the wiki. 
  
  For the next Hangout, how about Tuesday August 19th at same time (4pm EST 
  / 1pm PDT)?

Re: Monthly Cordova hangouts

2014-07-17 Thread tommy-carlos williams

+1

On 18 July 2014 at 14:00:59, Marcel Kinard (cmarc...@gmail.com) wrote:

So is the consensus 1pm PDT / 4pm EDT on Friday July 25? 

On Jul 16, 2014, at 6:04 PM, Tommy Williams to...@devgeeks.org wrote: 

 Absolutely. 1pm/4pm in the USA is just 6am here. Barely even have to get up 
 early. :)

Re: One platform development vs. Cordova CLI

2014-07-15 Thread tommy-carlos williams

Assuming that splash screens and icons finally work in 3.5.x (so, only as of a 
few weeks ago… not everyone’s projects are that new) –


Android:

AndroidManifest.xml:
android:versionCode
(and possibly) android:minSdkVersion

ant.properties
android signing info


This is just off the top of my head.

There are more in iOS as well (mostly the same ones, but others depending on 
features… like provisioning profiles, etc)

Then there are the platforms outside the “big two”… plenty there.

- tommy


On 15 July 2014 at 14:44:05, Axel Nennker (ignisvul...@gmail.com) wrote:

Could you please give an example which files you need to change and why?  
(Preferably Android)  

Thanks  
Axel  
Am 15.07.2014 02:23 schrieb tommy-carlos williams to...@devgeeks.org:  

 Sooo.. translation:  
  
 “If you aren’t just making a test / example app…”  
  
 ??  
  
 Unless a lot has changed that I don’t know about, it is still impossible  
 to make an app all the way to market without modifying those non-www files  
 using the CLI.  
  
 There are fantastic workarounds available (mostly hooks, etc) for the CLI  
 until we get it to the point where the platforms/* and plugins/* folders  
 are build artefacts.  
  
 - tommy  
  
 On 15 July 2014 at 9:14:12, Anis KADRI (anis.ka...@gmail.com) wrote:  
  
 If you're touching any non-www project files (that is *.xml, *.plist, *.m,  
 *.java etc...) or are using an IDE you should not be using cordova-cli and  
 switch to single platform development. Browse the documentation and there  
 is always the equivalent platform command available to you. Example:  
 cordova build becomes ./cordova/build etc...You can then modify all your  
 files at will but will loose the benefit of a shared www/ across platforms.  
  
  
 On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão   
 frederico.gal...@pontoget.com.br wrote:  
  
  I agree with the core message from Axel, but I'd refrase that last line  
 as:  
   
  The bottom line is: either use Cordova CLI or not.  
   
  Cordova can still be used without the CLI portion just as well, which  
  should suffice Jan for his needs.  
   
  However, I'll add that you can still use Cordova with the CLI (and thus  
  following the directory structure and rules the CLI gives you) and still  
 be  
  efficient even if it's only one target platform.  
  What made you think that it is better to change platform project  
  config.xml instead of whole project config.xml should be clarified  
 better  
  if you can, so that the Cordova team can improve the tool.  
   
   
  2014-07-14 5:35 GMT-03:00 Axel Nennker ignisvul...@gmail.com:  
   
   My experience with Cordova (and other tools for that matter) is that it  
   makes no sense to change tool generated files.  
   If the tool is improved you do not benefit from this improvement  
 because  
   your modified files will be changed by the new version.  
   If you change a tool generated file you are out.  
   When we started using Cordova me and other colleagues thought that our  
   project needs to change Cordova generated files too.  
   In each case this turned out to be wrong.  
   Most of the times writing a Cordova plugin is the solution.  

   The bottom line is: either use Cordova or not. (or send a pull request  
 to  
   improve it)  

   -Axel  




   2014-07-13 22:18 GMT+02:00 Jan Velecký vve...@seznam.cz:  

Hello,  
there is serious backlog when using CLI in case one platform  
  development.  
In  
this case is better to change platform project config.xml instead of  
   whole  
project config.xml. Problem is what prepare should do, and what  
 prepare  
actually do. (And prepare is also run if we do build.) At this  
 moment,  
prepare in CLI does clean  copy...  
Also prepare does it in different way in Android, than in iOS.  
On Android, config.xml and androidmanifest.xml is probably recreated  
(destroy previous formatting, what a feature...) and then probably  
 add  
differences, so changes and new options are preserved, however nobody  
   wanna  
read it...  
On iOS, config.xml is completely recreated, no any option is  
  preserved...  
 
So, there are 2 questions...  
If is Android CLI too clever to do preserve changes created by user,  
  why  
   it  
ruins my formatting (new lines, maybe also tabulators)?  
Why is iOS CLI such a stupid? Why it is not able to do it like  
 Android  
   CLI  
(at least)?  

   
   
   
  --  
   
  *Frederico Galvão*  
   
  Diretor de Tecnologia  
   
  PontoGet Inovação Web  
   
   
  ( +55(62) 8131-5720  
   
  * www.pontoget.com.br http://www.pontoget.com/

Re: One platform development vs. Cordova CLI

2014-07-15 Thread tommy-carlos williams

+1 This

On 15 July 2014 at 20:31:07, purplecabbage (purplecabb...@gmail.com) wrote:

There are numerous last mile steps we are not involved in, which is why I wish 
more committers were submitting apps to more stores, at least to see the 
process.

Re: One platform development vs. Cordova CLI

2014-07-15 Thread tommy-carlos williams

Never said this stuff couldn’t be fixed.

I have been actively advocating for it to be fixed.

Only wanted to spread some light on this statement:

If you're touching any non-www project files (that is *.xml, *.plist, *.m,
*.java etc...) or are using an IDE you should not be using cordova-cli and
switch to single platform development.
- tommy

On 15 July 2014 at 22:11:24, Axel Nennker (ignisvul...@gmail.com) wrote:

From looking at the code it seems that versionCode is handled on Android:
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js#L225

There is a email thread about minSdkVersion and an quite recent issue:
https://issues.apache.org/jira/browse/CB-7114?jql=text%20~%20%22minSdkVersion%22

So these could be fixed.

Regarding signing info: I am using ant on top of cordova like: e.g.: create
app from my template; install plugins, run
Ant modifies ant.properties too. Currently not to include signing info but
to modify the classpath because I need a lib at compile time that is not
included into the apk (openmobileapi).
Not sure wheter these two requirements (signing info, noexportlib) should
be of config.xml...
At least I am not doing this stuff manually.

2014-07-15 12:11 GMT+02:00 tommy-carlos williams to...@devgeeks.org:

Assuming that splash screens and icons finally work in 3.5.x (so, only as
of a few weeks ago… not everyone’s projects are that new) –

Android:

AndroidManifest.xml:
android:versionCode
(and possibly) android:minSdkVersion

ant.properties
android signing info

This is just off the top of my head.

There are more in iOS as well (mostly the same ones, but others depending
on features… like provisioning profiles, etc)

Then there are the platforms outside the “big two”… plenty there.

- tommy

On 15 July 2014 at 14:44:05, Axel Nennker (ignisvul...@gmail.com) wrote:

Could you please give an example which files you need to change and why?
(Preferably Android)

Thanks
Axel
Am 15.07.2014 02:23 schrieb tommy-carlos williams to...@devgeeks.org:

Sooo.. translation:

“If you aren’t just making a test / example app…”

Unless a lot has changed that I don’t know about, it is still impossible
to make an app all the way to market without modifying those non-www
files
using the CLI.

There are fantastic workarounds available (mostly hooks, etc) for the CLI
until we get it to the point where the platforms/* and plugins/* folders
are build artefacts.

- tommy

On 15 July 2014 at 9:14:12, Anis KADRI (anis.ka...@gmail.com) wrote:

If you're touching any non-www project files (that is *.xml, *.plist,
*.m,
*.java etc...) or are using an IDE you should not be using cordova-cli
and
switch to single platform development. Browse the documentation and there
is always the equivalent platform command available to you. Example:
cordova build becomes ./cordova/build etc...You can then modify all your
files at will but will loose the benefit of a shared www/ across
platforms.

On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão
frederico.gal...@pontoget.com.br wrote:

I agree with the core message from Axel, but I'd refrase that last line
as:

The bottom line is: either use Cordova CLI or not.

Cordova can still be used without the CLI portion just as well, which
should suffice Jan for his needs.

However, I'll add that you can still use Cordova with the CLI (and thus
following the directory structure and rules the CLI gives you) and
still
be
efficient even if it's only one target platform.
What made you think that it is better to change platform project
config.xml instead of whole project config.xml should be clarified
better
if you can, so that the Cordova team can improve the tool.

2014-07-14 5:35 GMT-03:00 Axel Nennker ignisvul...@gmail.com:

My experience with Cordova (and other tools for that matter) is that
it
makes no sense to change tool generated files.
If the tool is improved you do not benefit from this improvement
because
your modified files will be changed by the new version.
If you change a tool generated file you are out.
When we started using Cordova me and other colleagues thought that
our
project needs to change Cordova generated files too.
In each case this turned out to be wrong.
Most of the times writing a Cordova plugin is the solution.

The bottom line is: either use Cordova or not. (or send a pull
request
to
improve it)

-Axel

2014-07-13 22:18 GMT+02:00 Jan Velecký vve...@seznam.cz:

Hello,
there is serious backlog when using CLI in case one platform

Re: Monthly Cordova hangouts

2014-07-15 Thread tommy-carlos williams

Is it actually my fault it’s on this late for y’all?

I honestly don’t mind getting up early once a month, heh.

- tommy

On 16 July 2014 at 6:53:45, Brian LeRoux (b...@brian.io) wrote:

I won't be able to make this evening (and suspect many in the same boat)  


On Tue, Jul 15, 2014 at 1:43 PM, Michal Mocny mmo...@chromium.org wrote:  

 Event link: https://plus.google.com/events/c2cqjqfkkppsealikav2tm37dik  
 Alternative YouTube link: http://www.youtube.com/watch?v=Wpx91MxV-DA  
  
 I've also enabled QA which I don't think we've used before, which should  
 give a way for anyone streaming to somehow participate in the hangout. We  
 can experiment with this  other features at the tail end of the hangout  
 for next time if anyone would like.  
  
 I'll send out the join link closer to 7pm when I actually start the  
 hangout.  
  
  
  
  
 On Tue, Jul 15, 2014 at 3:01 PM, Mike Billau mike.bil...@gmail.com  
 wrote:  
  
  Joe, I thought about it today and agree with you, we can wait to talk  
 about  
  the whitelist later or just finish off that thread.  
   
   
  On Tue, Jul 15, 2014 at 1:56 PM, Joe Bowser bows...@gmail.com wrote:  
   
   I don't think we should talk about security on the hangout, as per the  
   Apache Security Policy.  

   On Mon, Jul 14, 2014 at 2:08 PM, Mike Billau mike.bil...@gmail.com  
   wrote:  
I added something about a default secure configuration: no whitelist,  
  no  
permissions, etc., that hopefully plays into the  
 whitelist-as-a-plugin  
topic that I don't think was ever resolved. Maybe this can be a more  
general discussion about security but probably not.  
 
 
On Mon, Jul 14, 2014 at 4:16 PM, Jesse purplecabb...@gmail.com  
  wrote:  
 
 
 http://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes  
 
7PM EST  
 
@purplecabbage  
risingj.com  
 
 
On Mon, Jul 14, 2014 at 1:11 PM, Tommy Williams to...@devgeeks.org  
   
wrote:  
 
 Which time slot is this one?  
 On 15 Jul 2014 05:49, Joe Bowser bows...@gmail.com wrote:  
  
  No, I'm actually back this week. I'll be in Portland next week  
  for  
  OSCON, so my availability will be even more sporatic than it is  
  now.  
  I'll be available for the hangout tomorrow.  
   
  On Mon, Jul 14, 2014 at 10:56 AM, Brian LeRoux b...@brian.io  
  wrote:  
   Joe is still PTO (and hopefully enjoying the shit out of it)  
 so  
that'll  
   have to wait  


   On Mon, Jul 14, 2014 at 10:48 AM, Parashuram Narasimhan (MS  
 OPEN  
TECH)  
   
   panar...@microsoft.com wrote:  

   I added a couple of items for 3.6.0 release for Windows  
  Universal  
 apps.  
  We  
   also decided to talk about the min/max Android and iOS  
 versions  
right  
   (Joe's questions about this) ?  

   @Lisa, would this be too early to talk about configurable  
   folders in  
 the  
   CLI?  

   -Original Message-  
   From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com]  
  On  
 Behalf  
  Of  
   Brian LeRoux  
   Sent: Monday, July 14, 2014 10:31 AM  
   To: dev@cordova.apache.org  
   Subject: Re: Monthly Cordova hangouts  

   anyone want to take a stab at an agenda? (no major  
   blockers/issues  
for  
  us  
   in Vancouver/SF atm)  


   On Mon, Jul 14, 2014 at 8:49 AM, David Kemp   
  drk...@chromium.org  
 
  wrote:  

The call is scheduled for tomorrow evening.  
On 14 Jul 2014 11:44, Parashuram Narasimhan (MS OPEN  
 TECH)  

panar...@microsoft.com wrote:  
 
 Just wondering if we already had the Monthly hangouts for  
   this  
 month. We usually have it on 15th every month, right ?  
 Also, I remember that from the last hangout, we had  
 trouble  
 getting  
 more than 10 people into the hangout. Do we want to try  
alternate  
 solutions (Webex, Lync, or a conference bridge) that can  
  let  
more  
 people  
participate?

Re: Monthly Cordova hangouts

2014-07-15 Thread tommy-carlos williams

Should we postpone this? This is looking like it’s missing some key ingredients


On 16 July 2014 at 8:41:33, Shazron (shaz...@gmail.com) wrote:

thought I could make it, but something's come up.  

On Tue, Jul 15, 2014 at 2:17 PM, Josh Soref jso...@blackberry.com wrote:  
 Brian wrote:  
 I won't be able to make this evening (and suspect many in the same boat)  
  
 nor will I

Re: Monthly Cordova hangouts

2014-07-15 Thread tommy-carlos williams

Don’t worry about me… I’ll get up whenever.



On 16 July 2014 at 8:44:25, Joe Bowser (bows...@gmail.com) wrote:

Yes, I think we should definitely postpone this.  

On Tue, Jul 15, 2014 at 3:42 PM, tommy-carlos williams  
to...@devgeeks.org wrote:  
 Should we postpone this? This is looking like it’s missing some key 
 ingredients  
  
  
 On 16 July 2014 at 8:41:33, Shazron (shaz...@gmail.com) wrote:  
  
 thought I could make it, but something's come up.  
  
 On Tue, Jul 15, 2014 at 2:17 PM, Josh Soref jso...@blackberry.com wrote:  
 Brian wrote:  
 I won't be able to make this evening (and suspect many in the same boat)  
  
 nor will I

Re: One platform development vs. Cordova CLI

2014-07-14 Thread tommy-carlos williams

Sooo.. translation:

“If you aren’t just making a test / example app…”

??

Unless a lot has changed that I don’t know about, it is still impossible to 
make an app all the way to market without modifying those non-www files using 
the CLI.

There are fantastic workarounds available (mostly hooks, etc) for the CLI until 
we get it to the point where the platforms/* and plugins/* folders are build 
artefacts.

- tommy

On 15 July 2014 at 9:14:12, Anis KADRI (anis.ka...@gmail.com) wrote:

If you're touching any non-www project files (that is *.xml, *.plist, *.m,  
*.java etc...) or are using an IDE you should not be using cordova-cli and  
switch to single platform development. Browse the documentation and there  
is always the equivalent platform command available to you. Example:  
cordova build becomes ./cordova/build etc...You can then modify all your  
files at will but will loose the benefit of a shared www/ across platforms.  


On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão   
frederico.gal...@pontoget.com.br wrote:  

 I agree with the core message from Axel, but I'd refrase that last line as:  
  
 The bottom line is: either use Cordova CLI or not.  
  
 Cordova can still be used without the CLI portion just as well, which  
 should suffice Jan for his needs.  
  
 However, I'll add that you can still use Cordova with the CLI (and thus  
 following the directory structure and rules the CLI gives you) and still be  
 efficient even if it's only one target platform.  
 What made you think that it is better to change platform project  
 config.xml instead of whole project config.xml should be clarified better  
 if you can, so that the Cordova team can improve the tool.  
  
  
 2014-07-14 5:35 GMT-03:00 Axel Nennker ignisvul...@gmail.com:  
  
  My experience with Cordova (and other tools for that matter) is that it  
  makes no sense to change tool generated files.  
  If the tool is improved you do not benefit from this improvement because  
  your modified files will be changed by the new version.  
  If you change a tool generated file you are out.  
  When we started using Cordova me and other colleagues thought that our  
  project needs to change Cordova generated files too.  
  In each case this turned out to be wrong.  
  Most of the times writing a Cordova plugin is the solution.  
   
  The bottom line is: either use Cordova or not. (or send a pull request to  
  improve it)  
   
  -Axel  
   
   
   
   
  2014-07-13 22:18 GMT+02:00 Jan Velecký vve...@seznam.cz:  
   
   Hello,  
   there is serious backlog when using CLI in case one platform  
 development.  
   In  
   this case is better to change platform project config.xml instead of  
  whole  
   project config.xml. Problem is what prepare should do, and what prepare  
   actually do. (And prepare is also run if we do build.) At this moment,  
   prepare in CLI does clean  copy...  
   Also prepare does it in different way in Android, than in iOS.  
   On Android, config.xml and androidmanifest.xml is probably recreated  
   (destroy previous formatting, what a feature...) and then probably add  
   differences, so changes and new options are preserved, however nobody  
  wanna  
   read it...  
   On iOS, config.xml is completely recreated, no any option is  
 preserved...  

   So, there are 2 questions...  
   If is Android CLI too clever to do preserve changes created by user,  
 why  
  it  
   ruins my formatting (new lines, maybe also tabulators)?  
   Why is iOS CLI such a stupid? Why it is not able to do it like Android  
  CLI  
   (at least)?  
   
  
  
  
 --  
  
 *Frederico Galvão*  
  
 Diretor de Tecnologia  
  
 PontoGet Inovação Web  
  
  
 ( +55(62) 8131-5720  
  
 * www.pontoget.com.br http://www.pontoget.com/

Re: Verified Plugins Marketplace

2014-07-11 Thread tommy-carlos williams

Rob,

Is there a reason the plugins are all forked to your org instead of being 
listed from their original locations?

Is it to freeze the plugin in time to where it has been curated?



On 12 July 2014 at 1:12:34, Brian LeRoux (b...@brian.io) wrote:

this would be a good time to talk about the federation capabilities in 
Plugman and the Cordova/CLI then =) 

time for: 

`cordova registry add telerik http://plugins.telerik.com/  cordova set 
registry telerik` 

(or something like that) 



On Fri, Jul 11, 2014 at 7:51 AM, Rob Lauer rob.la...@telerik.com wrote: 

 Hi Cordova Team, 
 
 My name is Rob Lauer and I'm the Product Manager for AppBuilder here at 
 Telerik. I'm writing to let you know that we just released our brand new 
 Verified Plugins Marketplace for custom Cordova plugins. It's available 
 today, for free of course, at plugins.telerik.com 
 http://plugins.telerik.com/. 
 
 This site is meant to serve as a curated list of high value Cordova 
 plugins that we have tested, verified, documented, and used to create 
 simple sample apps (with Kendo UI) for hybrid developers. Our primary goal 
 for this site is to ease some of the pain developers experience when 
 choosing and implementing custom plugins - and thereby boosting the profile 
 of hybrid development in general. We are not trying to compete with 
 plugins.cordova.io or other existing plugin catalogs - we expect to 
 maintain a smaller, maintainable, set of plugins. There is more information 
 available at this blog post 
 http://blogs.telerik.com/blogs/14-07-11/verified-plugins-marketplace-your-source-for-verified-cordova-phonegap-plugins
  
 if you are curious. 
 
 We also have a UserVoice portal 
 http://telerik-verified-plugins.uservoice.com/ to solicit opinions on 
 which plugins we should include next. Please try it all out and let me know 
 what you think! 
 
 Thanks, 
 Rob Lauer | Product Manager at Telerik 
 @rdlauerhttp://twitter.com/rdlauer

Re: Android: add support of min/max/target SDK to config.xml

2014-07-07 Thread tommy-carlos williams

+1

Another step towards build-artefact-land.



On 7 July 2014 at 23:29:25, Andrew Grieve (agri...@chromium.org) wrote:

I'd love to see this added. 


On Mon, Jul 7, 2014 at 7:29 AM, Sergey Grebnov (Akvelon)  
v-seg...@microsoft.com wrote: 

 Propose to add support of the following Android specific settings to 
 config.xml similar to PG Build[2]. Optional, could be used to override 
 default template values. I think this could be very useful and will 
 implement this if we agree. Thoughts? 
 
 preference name=android-minSdkVersion value=10 / 
 preference name=android-targetSdkVersion value=19 / 
 preference name=android-maxSdkVersion value=20 / 
 
 [1] 
 http://developer.android.com/guide/topics/manifest/uses-sdk-element.html 
 [2] 
 http://docs.build.phonegap.com/en_US/configuring_preferences.md.html#_android_only
  
 
 Thx! 
 Sergey

Re: iOS: add target-device and MinimumOSVersion support to config.xml

2014-07-07 Thread tommy-carlos williams

+1

On 7 July 2014 at 23:29:46, Andrew Grieve (agri...@chromium.org) wrote:

+1 


On Mon, Jul 7, 2014 at 8:39 AM, Sergey Grebnov (Akvelon)  
v-seg...@microsoft.com wrote: 

 Phonegap build already supports[2] preferences below and we could make 
 this a part of Cordova. I can implement this if we agree. Thoughts? 
 
 #1 target-device 
 For targeting a specific device; possible values are handset, tablet, or 
 universal (default). 
 Example: 
 preference name=target-device value=universal / 
 
 #2 deployment-target 
 This sets the IPHONEOS_DEPLOYMENT_TARGET in the build, which tranlsates to 
 the MinimumOSVersion in the ipa Propertly List. 
 Example: 
 preference name=deployment-target value=7.0 / 
 
 [2] 
 http://docs.build.phonegap.com/en_US/configuring_preferences.md.html#_ios_only
  
 
 Thx! 
 Sergey

Re: WKWebView for iOS8

2014-06-14 Thread tommy-carlos williams


This looks promising.

Thanks for the update, Shazron.

- tommy

On Sun, Jun 15, 2014 at 7:48 AM, Shazron shaz...@gmail.com wrote:
Rev log: 
http://trac.webkit.org/log/trunk/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm

for potential WKWebView updates in beta 2.

On Sat, Jun 14, 2014 at 2:46 PM, Shazron shaz...@gmail.com wrote:
 Some potential good news. Updated 4 days ago, hopefully its in beta 
2:

 http://trac.webkit.org/changeset/169765

 Add -[WKWebView evaluateJavaScript:completionHandler:]

 Updated: https://issues.apache.org/jira/browse/CB-6884


 On Sat, Jun 7, 2014 at 10:06 PM, Carlos Santana 
csantan...@gmail.com wrote:
 ok, was a bit confuse with api doc, I assumed that there was a way 
to
 specify a time other than documentstart, documentend, and no 
passing

 something will do it immediately.

 Will open a radar too, we need wkwebview to officialy support for 
objc-js,

 postMessage seems kind of half working if only can do js-objc


 On Sat, Jun 7, 2014 at 10:48 PM, Shazron shaz...@gmail.com wrote:

 No it's not. That is precisely what we discussed, it's the 
limitation in

 WKUserScript.

 On Saturday, June 7, 2014, Carlos Santana csantan...@gmail.com 
wrote:


  Shaz
I think the closest replacement is [1] - (void)addUserScript:(
  WKUserScript *)*userScript *
 
  I have not tried my self, but looking forward on helping out.
 
  [1]:
 
 
 
https://developer.apple.com/library/prerelease/ios/documentation/WebKit/Reference/WKUserContentController_Ref/index.html#//apple_ref/occ/instm/WKUserContentController/addUserScript

  :
 
 
  On Fri, Jun 6, 2014 at 12:47 AM, Shazron shaz...@gmail.com 
wrote:

 
   No use in polling if we can't write anything back to JS from 
Obj-C.

  
   There's a private API to do so:
  
  
 
 
https://github.com/WebKit/webkit/commit/adb4c60064b38b5ab3d6e78422325f35f0b7fe2b
   only landed a few months ago, we'll have to do some advocacy 
through

   whatever channels we have to get it in the public API (radars,
   connections), since it is a deficiency in their API losing 
something

   like stringByEvaluatingJavaScriptFromString
  
  
  
   On Thu, Jun 5, 2014 at 6:09 PM, Michal Mocny 
mmo...@chromium.org

  wrote:
Oh wow.  I totally assumed that you can postMessage in 
either

 direction
   at
any time.  Wouldn't the alternative be polling from JS?
   
-Michal
   
   
On Thu, Jun 5, 2014 at 6:46 PM, Shazron shaz...@gmail.com 
wrote:

   
Well seems like the answer in iOS 8 beta 1 is -- no 
arbitrary

 sending
of JS, so no Obj-C - JS communication, which leaves 
Cordova

handcuffed. Please everyone file radars for this.
https://devforums.apple.com/message/975230#975230
   
On Thu, Jun 5, 2014 at 3:40 PM, Shazron 
shaz...@gmail.com wrote:

 Thanks Tommy - I sure will.

 I think injecting JavaScript at arbitrary times -- you 
would just

  use
 WKUserScriptInjectionTimeAtDocumentEnd for WKUserScript 
--

 although
  I
 haven't tested it. If setting JS at arbitrary times is 
taken away

 -
 yikes.

 Anyways, on the bridge front, I've posted my approach 
for the new

   bridge:
 https://issues.apache.org/jira/browse/CB-6884

 On Thu, Jun 5, 2014 at 2:06 PM, Tommy Williams 
 to...@devgeeks.org
wrote:
 I am sure you won't need it, but if I can help, let me 
know.


 I think the biggest hurdle will be firing user scripts 
at

 arbitrary
times
 instead of only on page load.. There seems to be an API 
that

 hasn't
   been
 exposed :/
 On 6 Jun 2014 04:59, Shazron shaz...@gmail.com 
wrote:


 My intent is to work on this today, in a branch for 
cordova-ios:

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

 On Wed, Jun 4, 2014 at 10:15 AM, Shazron 
shaz...@gmail.com

  wrote:
  Use Safari to watch Introducing the Modern WebKit 
API (no

  login
 required):
  https://developer.apple.com/videos/wwdc/2014/
 
  On Wed, Jun 4, 2014 at 8:25 AM, Michal Mocny 
  mmo...@chromium.org
   
 wrote:
  You can probably bet on it.
 
  But this is really fresh news, we're as excited as 
you are,

   trying
to
  figure out the details.
 
 
  On Wed, J--
  Carlos Santana
  csantan...@gmail.com javascript:;
 





 --
 Carlos Santana
 csantan...@gmail.com

Re: Cordova hooks always verbose.

2014-06-13 Thread tommy-carlos williams

My personal preference would be (but this is overall, not just for hooks):

cordova (no flags): gives minimal stage info – preparing blah, compiling foo, 
running after_prepare hook, etc. I would only have the “running after_prepare 
hook” if there actually *is* an after_prepare hook to run.

cordova (—verbose or -d): full output of all scripts as well as stage info 
above. 

cordova (—silent or -s): completely silent unless there is an error. This would 
be best for CI or build slave environments where you only want to be notified 
if something goes wrong








On 14 June 2014 at 7:06:05, Michal Mocny (mmo...@chromium.org) wrote:

Landed the change to make this verbose only since the current behaviour is  
certainly not a great default. We can add subsequent improvements to how  
we report on hooks firing as need arises (though honestly no one complained  
about this so far, perhaps hooks are not all that commonly used).  


On Fri, Jun 13, 2014 at 5:00 PM, Michal Mocny mmo...@chromium.org wrote:  

 running X hooks is not trivial to implement given how it works today.  
 You would have to pre-calculate how many scripts will run in response to  
 any action, and some actions are compound. I.e. cordova run you have to  
 count before/after from all of {prepare, build, run} (and more?), and we  
 just don't do that sort of accounting right now.  
  
 Its not that difficult to add and we should file a feature request to  
 better manage how hooks run, but I'm pretty sure there are better uses of  
 effort short-term.  
  
 -Michal  
  
  
 On Fri, Jun 13, 2014 at 4:08 PM, Lorin Beer lorin.b...@gmail.com wrote:  
  
 as someone who uses hooks, I think that's a good idea  
  
 1. non verbose mode should simply output something like running X hooks  
 2. verbose mode can output more details of the scripts being run  
  
 On Fri, Jun 13, 2014 at 1:05 PM, Michal Mocny mmo...@google.com wrote:  
  https://issues.apache.org/jira/browse/CB-6942  
   
   
  On Fri, Jun 13, 2014 at 3:51 PM, Michal Mocny mmo...@google.com  
 wrote:  
   
  Hey all,  
   
  I'd like to change cordova-cli to not always print multiple messages  
 like  
  Running command: ... when it runs hooks. I'd like this to happen  
 only if  
  you have verbose logging on (with -d or --verbose).  
   
  I think this was a regression added in February, but since its been in  
 a  
  few releases with no complaints (likely because most projects don't use  
  hooks), I wonder if others feel this is a useful default (I don't  
 think it  
  is)?  
   
  Tommy: you guys use hooks in your projects a lot, what do you think?  
   
  If it is a useful default, I'll instead add a way to opt-out without  
  disabling absolutely all logging with --silent.  
   
  -Michal

Re: Hangout

2014-06-10 Thread tommy-carlos williams

Sadly, it’s actually 6am at this time of year, but I’ll be there ;)

On 10 June 2014 at 2:03:41, Michal Mocny (mmo...@chromium.org) wrote:

Sounds great, thanks for the agenda.  

Note, there are already some beefy items on the list and we always run  
short on time -- so before adding more please triple consider if items are  
important and cannot just be discussed on the lists.  

-Michal  


On Mon, Jun 9, 2014 at 10:55 AM, Marcel Kinard cmarc...@gmail.com wrote:  

 Assuming we will be doing the Hangout tomorrow, I created a draft agenda  
 and notes placeholder as a Google Doc, and it is linked from the wiki:  
 https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes  
  
 Is the previously-scheduled time of 4pm EDT good? I think that maps to 8am  
 for Tommy.

Re: WKWebView for iOS8

2014-06-05 Thread tommy-carlos williams


Yeah, I was afraid of that...

:(

On Fri, Jun 6, 2014 at 11:09 AM, Michal Mocny mmo...@chromium.org 
wrote:
Oh wow.  I totally assumed that you can postMessage in either 
direction at

any time.  Wouldn't the alternative be polling from JS?

-Michal


On Thu, Jun 5, 2014 at 6:46 PM, Shazron shaz...@gmail.com wrote:

 Well seems like the answer in iOS 8 beta 1 is -- no arbitrary 
sending

 of JS, so no Obj-C - JS communication, which leaves Cordova
 handcuffed. Please everyone file radars for this.
 https://devforums.apple.com/message/975230#975230

 On Thu, Jun 5, 2014 at 3:40 PM, Shazron shaz...@gmail.com wrote:
  Thanks Tommy - I sure will.
 
  I think injecting JavaScript at arbitrary times -- you would just 
use
  WKUserScriptInjectionTimeAtDocumentEnd for WKUserScript -- 
although I
  haven't tested it. If setting JS at arbitrary times is taken away 
-

  yikes.
 
  Anyways, on the bridge front, I've posted my approach for the new 
bridge:

  https://issues.apache.org/jira/browse/CB-6884
 
  On Thu, Jun 5, 2014 at 2:06 PM, Tommy Williams 
to...@devgeeks.org

 wrote:
  I am sure you won't need it, but if I can help, let me know.
 
  I think the biggest hurdle will be firing user scripts at 
arbitrary

 times
  instead of only on page load.. There seems to be an API that 
hasn't been

  exposed :/
  On 6 Jun 2014 04:59, Shazron shaz...@gmail.com wrote:
 
  My intent is to work on this today, in a branch for cordova-ios:
  https://issues.apache.org/jira/browse/CB-6863
 
  On Wed, Jun 4, 2014 at 10:15 AM, Shazron shaz...@gmail.com 
wrote:
   Use Safari to watch Introducing the Modern WebKit API (no 
login

  required):
   https://developer.apple.com/videos/wwdc/2014/
  
   On Wed, Jun 4, 2014 at 8:25 AM, Michal Mocny 
mmo...@chromium.org

  wrote:
   You can probably bet on it.
  
   But this is really fresh news, we're as excited as you are, 
trying

 to
   figure out the details.
  
  
   On Wed, Jun 4, 2014 at 11:05 AM, Matthew David 
 matthewada...@gmail.com
  
   wrote:
  
   I am sure I am not the first to ask for this, but the new 
WebView

 for
  iOS
   is now WKWebView with support for Nitro JS engine. Will 
WKWebView

 be a
   selectable option in future builds of PhoneGap for iOS 
along with

  support
   for iOS7 and earlier?
  
   Matt

Re: adding platforms to npm for dependency sanity

2014-06-04 Thread tommy-carlos williams

 of the files added to the Xcode project are in the platforms/ios  
 directory.  
  
 -Terence  
  
  
  
 On 6/4/2014 10:10 AM, Carlos Santana wrote:  
  
 I think regardless how much sugar we use to make it easy, I think  
  
 the  
  
 under  
 the hood foundation/architecture should be something like:  
  
 LocalProject/www/  
 LocalProject/config.xml  
 LocalProject/package.json  
 LocalProject/node_module/.bin/cordova  
  
 config.xml (manages the cordova app)  
 package.json (manages the cordova project)  
  
 pacakge.json (will specify all dependencies and npm will take care  
  
 of  
  
 fulfill them)  
 {  
 cordova: 3.6,  
 cordova-ios: 3.6.1,  
 cordova-android: 3.6.2,  
 cordova-plugin-device: *,  
 cordova-plugin-file: ^0.2.4  
 }  
 npm install will take care of making everything available locally.  
  
 I know that we don't have plugins in npm, but something to think  
  
 about,  
  
 in  
  
 terms of just a secondary repository to download the files and  
  
 caching.  
  
 a global @cordova-cli, can be available like grunt-cli, to look  
  
 first  
  
 in  
  
 local directory (i.e. findup)  
  
 like someone mentioned npm installs hooks can run the cordova  
  
 platform  
  
 add  
  
 this way minimal set of files can be put a dev repo, and reproduce  
  
 by  
  
 another developer very easy both getting same resulting project.  
  
 git clone https://github.com/myuser/cordovapp  cd cordovapp   
  
 npm  
  
 install  cordova run android  
  
  
  
 On Tue, Jun 3, 2014 at 6:35 PM, Terence M. Bandoian   
  
 tere...@tmbsw.com  
  
 wrote:  
  
 I still consider myself a relative newcomer to Cordova but, from a  
  
 development standpoint, it would be easiest for me if I could  
  
 manage  
  
 each  
  
 platform of a project independently - including plugins. Creating  
  
 a  
  
 parallel project to make sure that the plugins and Cordova base  
  
 don't  
  
 change for one platform while I work on another isn't ideal but it  
  
 isn't  
  
 completely unmanageable either. It just makes the workflow a  
  
 little  
  
 more  
  
 complex.  
  
 -Terence  
  
  
  
 On 6/3/2014 7:12 PM, Michal Mocny wrote:  
  
 We don't do platform-plugin version matching *at all* today.  
  
 Everyone  
  
 uses  
 the latest plugins and any platform version they want, and its  
  
 been  
  
 fine.  
 So using different platform versions isn't as hard as you guys  
  
 are  
  
 making  
 it out to be.  
  
 Still, I've already said its not necessarily a complexity that  
  
 needs  
  
 to  
  
 be  
 addressed in a world where you can create multiple projects and  
  
 use  
  
 --link-to or whatever, so long as your platforms aren't installed  
 globally.  
  
  
 Anyway, thanks for posting your instructions Brian/Tommy. As I  
 mentioned  
 it would be, thats a different workflow than we have now. I'm  
  
 going  
  
 to  
  
 sleep on it before I comment, but it certainly isn't just like  
  
 You  
  
 know  
  
 how we do it today.  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 7:59 PM, tommy-carlos williams   
 to...@devgeeks.org  
 wrote:  
  
 I don’t think you really can forget about plugins for a second.  
  
 In my personal opinion, the entire ./platforms folder should be a  
  
 build  
  
 artefact. If you want to freeze iOS, then use a branch or a new  
  
 clone  
  
 of  
 the project.  
  
 It’s not that I can think of no scenarios where supporting  
  
 multiple  
  
 platform versions would be needed, it’s just that I think it’s  
 needlessly  
 complex vs using a dev workflow to solve those problems.  
  
 I already version cordova within a project… I have a local  
  
 version  
  
 of  
  
 cordova installed into ./node_modules for each project and use  
  
 Grunt  
  
 to  
  
 call ./node_modules/.bin/cordova rather than the global cordova  
  
 cli.  
  
 On 4 June 2014 at 9:46:29, Terence M. Bandoian (  
  
 tere...@tmbsw.com)  
  
 wrote:  
  
 Forgetting about plugins for a second, what if:  
  
 - I complete a project for iOS  
 - six months later the client decides to port to Android and:  
 - I want the latest fixes for Android  
 - I want to keep the iOS version frozen for the time being  
  
 I would expect releases for each platform to be on different  
  
 schedules.  
  
 -Terence  
  
  
 On 6/3/2014 6:17 PM, Michal Mocny wrote:  
  
 Most plugins will work across a wide range of platform versions,  
  
 so  
  
 often  
 it would work to have disparate platform versions even with  
  
 plugins.  
  
 However, I do concede that in general this isn't a complexity we  
  
 focus  
  
 on.  
  
 Interested in your thoughts about the other points.  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams   
  
 to...@devgeeks.org  
  
 wrote:  
  
 You can’t have version x of a plugin for iOS and version y of  
  
 that  
  
 same  
  
 plugin for Android, so multiple platform versions seems like a  
  
 complexity  
  
 for complexity’s

Re: adding platforms to npm for dependency sanity

2014-06-03 Thread tommy-carlos williams

You can’t have version x of a plugin for iOS and version y of that same plugin 
for Android, so multiple platform versions seems like a complexity for 
complexity’s sake.

It’s true that different apps need to support different platform versions, but 
I would suspect that the greatest majority of those would want the same version 
of iOS and Android in app x.



On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote:

That is the thing: you do not EVER want to have disparate versions of  
platforms. Plugins negate this potential fantasy.  

You want version locked deps. You want to use package.json to do that b/c  
that is what the runtime we use has standardized itself on.  


On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian tere...@tmbsw.com  
wrote:  

 A typical use case might be:  
  
 -project1  
 -project1-ios  
 -project1-android  
 -project1-windows  
 ...  
 -projectN  
 -projectN-ios  
 -projectN-android  
 -projectN-windows  
  
 with a different platform version for each sub-project.  
  
 Would CLI be installed globally? Locally for each sub-project? Would a  
 project-platform have to be re-built if a plugin were added?  
  
 -Terence  
  
  
 On 6/3/2014 1:47 PM, Michal Mocny wrote:  
  
 Okay, so I think that implies:  
  
 (a) CLI versions tied to very specific platform versions == to switch  
 platform versions you must switching CLI versions == switching one  
 platform version switches all platform versions.  
 - Andrew pointed out this is currently the case, and is a problem that  
 leads to users not updating CLI as often as they otherwise would  
 - I think this basically implies platforms cannot be independently  
 versioned (sure the semver numbers may differ, but for all practical  
 purposes, you would use platforms from the same release date, based on CLI  
 version).  
  
 (b) Require apps to depend on specific CLI version, assuming you mean with  
 a local package.json:  
 - Now all cordova projects must be node projects, which they currently are  
 not.  
 - Currently the cordova-cli creates apps, so we have a globally installed  
 bootstrapping cordova-cli, and a locally installed specific version  
 cordova-cli, a-la grunt/gulp. (this idea was thrown around before).  
 - Quite a dramatic change for cordova workflow, surely larger than the  
 current proposal.  
 - Or we drop cordova-cli entirely and just publish grunt/gulp plugins to  
 add cordova to your existing web app. Thats an even more radical  
 departure and significant work.  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux b...@brian.io wrote:  
  
 No, at least not how I'd see it done.  
  
 1.) Updating is important. Staying current: encouraged.  
 2.) I'd make my App depend on a specific CLI version. I'd call into that  
 using npm scripts.  
  
  
  
  
 On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny mmo...@chromium.org  
 wrote:  
  
 Thinking it through, if cordova platforms are deps of the CLI, to  
  
 install a  
  
 specific version you wouldn't just do:  
  
 npm install -g cordova-ios@3.4.1  
  
 you would actually need to:  
  
 cd $(npm config get prefix)/lib/node_modules/cordova  
 npm install --save cordova-ios@3.4.1  
  
 ..and then remember to do that again whenever you `npm update -g`  
 ..and its harder to have multiple platform versions for different  
  
 projects  
  
 (questionable if this is useful for devs outside of cordova  
 contributors,  
 but may be useful at last test upgrades when we ship new platform  
 versions).  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 1:28 PM, Brian LeRoux b...@brian.io wrote:  
  
 NIH: not invented here  
  
  
  
 On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve agri...@chromium.org  
 wrote:  
  
 On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux b...@brian.io wrote:  
  
 Actually that was 0 LOC which is a fine argument if you ask me.  
  
 And  
  
 we  
  
 both know there is much more to it than just that. lazy_load…for  
  
 example.  
  
  
 If you're concerned about code, there is a tonne of much  
  
 lower-hanging  
  
 fruit.  
  
  
 Bundling platforms is bundling a dep that we require to operate. We  
  
 do  
  
 not  
  
 require plugins to operate. You cannot build a project without  
  
 having a  
  
 platform and, indeed, you probably want more than one.  
  
 I don't require blackberry to create an iOS project. But I do  
 require  
  
 some  
  
 plugins. We use npm cache add to download plugins, I don't see how  
 platforms would not work just as easily.  
  
  
 Agree that we need discreet versioning: hence why I'm advocating we  
  
 use  
  
 well understood, maintained, and effectively standard system for  
  
 doing  
  
 this. We do not need NIH dependencies that is what package.json is  
  
 for!  
  
 I don't know what NIH dependencies are. Googling suggests you're  
  
 talking  
  
 about drugs...  
  
 We *are* using npm for downloading, we're just not making the user  
  
 type  
  
 it

Re: Attending WWDC 2014?

2014-06-03 Thread tommy-carlos williams

We need to be all over this, as early as possible. 

Happy to finally put code where my mouth is to help make this happen (assuming 
it’s true)

;)



On 4 June 2014 at 8:58:34, Shazron (shaz...@gmail.com) wrote:

https://twitter.com/vickimurley/status/473955064629829632  

On Tue, Jun 3, 2014 at 2:47 PM, Jesse purplecabb...@gmail.com wrote:  
 Wow, that's new! Has the whole world gone sane?  
  
 @purplecabbage  
 risingj.com  
  
  
 On Tue, Jun 3, 2014 at 2:17 PM, Shazron shaz...@gmail.com wrote:  
  
 Actually - this is a breath of fresh air -- we can talk about the  
 Apple pre-release stuff with certain conditions:  
 http://oleb.net/blog/2014/06/apple-lifted-beta-nda/  
  
 On Tue, Jun 3, 2014 at 12:58 PM, Shazron shaz...@gmail.com wrote:  
  Hmm. I thought the link was under a login. Turns out it isn't - oh well  
 :P  
  I think the main difference I saw is it opens up a lot more interfaces  
  (delegates) for us to fix some of our workarounds with.  
   
  On Tue, Jun 3, 2014 at 12:55 PM, Kerri Shotts ke...@photokandy.com  
 wrote:  
  Ooooh, those diffs have some *very interesting* things going on  
 there.  
  ;-)  
   
   
   
   
  ___  
  Kerri Shotts  
  photoKandy Studios, LLC  
   
  On the Web: http://www.photokandy.com/  
   
  Social Media:  
  Twitter: @photokandy, http://twitter.com/photokandy  
  Tumblr: http://photokandy.tumblr.com/  
  Github: https://github.com/kerrishotts  
   
 https://github.com/organizations/photokandyStudios  
  CoderWall: https://coderwall.com/kerrishotts  
   
  Apps on the Apple Store:  
   
  https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828  
   
  Books:  
   
 http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book  
  http://www.packtpub.com/phonegap-social-app-development/book  
   
   
  On Tue, Jun 3, 2014 at 2:37 PM, Marc Weiner mhweiner...@gmail.com  
 wrote:  
   
  WOW! Really?? That sounds promising!  
   
   
  On Tue, Jun 3, 2014 at 3:23 PM, Michal Mocny mmo...@chromium.org  
 wrote:  
   
   WKWebView?!  


   On Tue, Jun 3, 2014 at 3:14 PM, Shazron shaz...@gmail.com wrote:  

See API diffs:  
 

   
 https://developer.apple.com/library/prerelease/ios/releasenotes/General/iOS80APIDiffs/index.html
   
Some random search terms: UIWebView, Tofu, Rice Pilaf, WebKit,  
 Curry,  
Green Beans  
 
 
On Tue, Jun 3, 2014 at 10:05 AM, purplecabbage   
  purplecabb...@gmail.com  
wrote:  
 The sessions will all be nda, but the docs should be available  
 now,  
  and  
videos to come.  
 So I recommend you don't live tweet.  
  
 Sent from my iPhone  
  
 On Jun 3, 2014, at 2:47 AM, tommy-carlos williams   
  to...@devgeeks.org  
 
wrote:  
  
 Carlos,  
  
 PLEASE tell me you are going to “Introducing the Modern WebKit  
 API”  
   and  
live tweeting it, or something?!  
  
 “...advanced bridging between JavaScript and Objective-C,  
 increased  
JavaScript performance via WebKit's super-fast JIT, and more  
  
 Is that saying what I THINK it’s saying?  
  
 - tommy  
  
 On 3 June 2014 at 17:39:57, Steven Gill (stevengil...@gmail.com  
 )  
   wrote:  
  
 Interested in meeting at beerjs?  
 http://www.meetup.com/beerjs/events/180505862/  
  
  
 On Mon, Jun 2, 2014 at 2:12 PM, Joe Bowser bows...@gmail.com  
   wrote:  
  
 I'm also in SF Monday-Wednesday.  
  
 On Mon, Jun 2, 2014 at 10:47 AM, Michael Brooks  
 mich...@michaelbrooks.ca wrote:  
 I'm in SF Monday-Wednesday as well (not for WWDC). It would be  
  great  
to  
 meet up!  
  
  
 On Mon, Jun 2, 2014 at 9:28 AM, Ken Wallis   
  kwal...@blackberry.com  
 
 wrote:  
  
 I am at the Tizen dev conf tomorrow and Wednesday, would be  
interested  
 in  
 a cordova meet as well!  
 --  
 Ken Wallis  
 Senior Product Manager - WebWorks  
 BlackBerry  
 925-931-6024  
  
  
  
  
  
 -Original Message-  
 From: Brian LeRoux b...@brian.io  
 Reply-To: dev@cordova.apache.org dev@cordova.apache.org  
 Date: Monday, June 2, 2014 at 9:09 AM  
 To: dev@cordova.apache.org dev@cordova.apache.org  
 Subject: Re: Attending WWDC 2014?  
  
 Cordova dinner this week works for me!  
 On May 30, 2014 12:49 PM, Carlos Santana   
  csantan...@gmail.com  
 wrote:  
  
 I will be attending wwdc next week, I was wondering if any  
 one  
   else  
 is  
 also  
 attending and want to setup a meetup.  
  
 --  
 Carlos Santana  
 csantan...@gmail.com

Re: adding platforms to npm for dependency sanity

2014-06-03 Thread tommy-carlos williams

+1

On 4 June 2014 at 9:17:09, Brian LeRoux (b...@brian.io) wrote:

…and use package.json to achieve a frictionless env swap on a per project  
basis, eventually making the CLI a thin shell that calls into node_modules  
ala Grunt, Gulp, etc.  


On Tue, Jun 3, 2014 at 4:07 PM, tommy-carlos williams to...@devgeeks.org  
wrote:  

 You can’t have version x of a plugin for iOS and version y of that same  
 plugin for Android, so multiple platform versions seems like a complexity  
 for complexity’s sake.  
  
 It’s true that different apps need to support different platform versions,  
 but I would suspect that the greatest majority of those would want the same  
 version of iOS and Android in app x.  
  
  
  
 On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote:  
  
 That is the thing: you do not EVER want to have disparate versions of  
 platforms. Plugins negate this potential fantasy.  
  
 You want version locked deps. You want to use package.json to do that b/c  
 that is what the runtime we use has standardized itself on.  
  
  
 On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian tere...@tmbsw.com  
 wrote:  
  
  A typical use case might be:  
   
  -project1  
  -project1-ios  
  -project1-android  
  -project1-windows  
  ...  
  -projectN  
  -projectN-ios  
  -projectN-android  
  -projectN-windows  
   
  with a different platform version for each sub-project.  
   
  Would CLI be installed globally? Locally for each sub-project? Would a  
  project-platform have to be re-built if a plugin were added?  
   
  -Terence  
   
   
  On 6/3/2014 1:47 PM, Michal Mocny wrote:  
   
  Okay, so I think that implies:  
   
  (a) CLI versions tied to very specific platform versions == to switch  
  platform versions you must switching CLI versions == switching one  
  platform version switches all platform versions.  
  - Andrew pointed out this is currently the case, and is a problem that  
  leads to users not updating CLI as often as they otherwise would  
  - I think this basically implies platforms cannot be independently  
  versioned (sure the semver numbers may differ, but for all practical  
  purposes, you would use platforms from the same release date, based on  
 CLI  
  version).  
   
  (b) Require apps to depend on specific CLI version, assuming you mean  
 with  
  a local package.json:  
  - Now all cordova projects must be node projects, which they currently  
 are  
  not.  
  - Currently the cordova-cli creates apps, so we have a globally  
 installed  
  bootstrapping cordova-cli, and a locally installed specific version  
  cordova-cli, a-la grunt/gulp. (this idea was thrown around before).  
  - Quite a dramatic change for cordova workflow, surely larger than the  
  current proposal.  
  - Or we drop cordova-cli entirely and just publish grunt/gulp plugins to  
  add cordova to your existing web app. Thats an even more radical  
  departure and significant work.  
   
  -Michal  
   
   
  On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux b...@brian.io wrote:  
   
  No, at least not how I'd see it done.  
   
  1.) Updating is important. Staying current: encouraged.  
  2.) I'd make my App depend on a specific CLI version. I'd call into  
 that  
  using npm scripts.  
   
   
   
   
  On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny mmo...@chromium.org  
  wrote:  
   
  Thinking it through, if cordova platforms are deps of the CLI, to  
   
  install a  
   
  specific version you wouldn't just do:  
   
  npm install -g cordova-ios@3.4.1  
   
  you would actually need to:  
   
  cd $(npm config get prefix)/lib/node_modules/cordova  
  npm install --save cordova-ios@3.4.1  
   
  ..and then remember to do that again whenever you `npm update -g`  
  ..and its harder to have multiple platform versions for different  
   
  projects  
   
  (questionable if this is useful for devs outside of cordova  
  contributors,  
  but may be useful at last test upgrades when we ship new platform  
  versions).  
   
  -Michal  
   
   
  On Tue, Jun 3, 2014 at 1:28 PM, Brian LeRoux b...@brian.io wrote:  
   
  NIH: not invented here  
   
   
   
  On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve agri...@chromium.org  
   
  wrote:  
   
  On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux b...@brian.io wrote:  
   
  Actually that was 0 LOC which is a fine argument if you ask me.  
   
  And  
   
  we  
   
  both know there is much more to it than just that. lazy_load…for  
   
  example.  
   
   
  If you're concerned about code, there is a tonne of much  
   
  lower-hanging  
   
  fruit.  
   
   
  Bundling platforms is bundling a dep that we require to operate. We  
   
  do  
   
  not  
   
  require plugins to operate. You cannot build a project without  
   
  having a  
   
  platform and, indeed, you probably want more than one.  
   
  I don't require blackberry to create an iOS project. But I do  
  require  
   
  some  
   
  plugins. We use npm cache add to download

Re: adding platforms to npm for dependency sanity

2014-06-03 Thread tommy-carlos williams

If the cordova cli was globally installed, but basically a thin wrapper like 
grunt-cli… 

create:

cordova create foo
cd foo
npm install —save cordova@x.y.z
cordova platform add android
cordova platform add ios

cordova create bar
cd bar
npm install —save cordova@x.y.n
cordova platform add ios
cordova platform add android

update:

cd bar
npm install —save cordova@x.y.z
cordova update ios
cordova update android

??
On 4 June 2014 at 9:23:50, Brian LeRoux (b...@brian.io) wrote:

You know how we do it today? Just like that.  


On Tue, Jun 3, 2014 at 4:20 PM, Michal Mocny mmo...@chromium.org wrote:  

 Brian/Tommy, may you please write out the complete set of CLI commands you  
 envision for:  
 (a) create a new project and add 2 platforms  
 (b) upgrade an existing project to a specific version  
  
 I worry the current package.json proposal is more complex than we realize.  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 7:17 PM, tommy-carlos williams to...@devgeeks.org  
 wrote:  
  
 +1  
  
  
 On 4 June 2014 at 9:17:09, Brian LeRoux (b...@brian.io) wrote:  
  
 …and use package.json to achieve a frictionless env swap on a per project  
 basis, eventually making the CLI a thin shell that calls into node_modules  
 ala Grunt, Gulp, etc.  
  
  
 On Tue, Jun 3, 2014 at 4:07 PM, tommy-carlos williams to...@devgeeks.org  
   
 wrote:  
  
  You can’t have version x of a plugin for iOS and version y of that same  
  plugin for Android, so multiple platform versions seems like a  
 complexity  
  for complexity’s sake.  
   
  It’s true that different apps need to support different platform  
 versions,  
  but I would suspect that the greatest majority of those would want the  
 same  
  version of iOS and Android in app x.  
   
   
   
  On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote:  
   
  That is the thing: you do not EVER want to have disparate versions of  
  platforms. Plugins negate this potential fantasy.  
   
  You want version locked deps. You want to use package.json to do that  
 b/c  
  that is what the runtime we use has standardized itself on.  
   
   
  On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian tere...@tmbsw.com  
  wrote:  
   
   A typical use case might be:  

   -project1  
   -project1-ios  
   -project1-android  
   -project1-windows  
   ...  
   -projectN  
   -projectN-ios  
   -projectN-android  
   -projectN-windows  

   with a different platform version for each sub-project.  

   Would CLI be installed globally? Locally for each sub-project? Would a  
   project-platform have to be re-built if a plugin were added?  

   -Terence  


   On 6/3/2014 1:47 PM, Michal Mocny wrote:  

   Okay, so I think that implies:  

   (a) CLI versions tied to very specific platform versions == to  
 switch  
   platform versions you must switching CLI versions == switching one  
   platform version switches all platform versions.  
   - Andrew pointed out this is currently the case, and is a problem  
 that  
   leads to users not updating CLI as often as they otherwise would  
   - I think this basically implies platforms cannot be independently  
   versioned (sure the semver numbers may differ, but for all practical  
   purposes, you would use platforms from the same release date, based  
 on  
  CLI  
   version).  

   (b) Require apps to depend on specific CLI version, assuming you mean  
  with  
   a local package.json:  
   - Now all cordova projects must be node projects, which they  
 currently  
  are  
   not.  
   - Currently the cordova-cli creates apps, so we have a globally  
  installed  
   bootstrapping cordova-cli, and a locally installed specific version  
   cordova-cli, a-la grunt/gulp. (this idea was thrown around before).  
   - Quite a dramatic change for cordova workflow, surely larger than  
 the  
   current proposal.  
   - Or we drop cordova-cli entirely and just publish grunt/gulp  
 plugins to  
   add cordova to your existing web app. Thats an even more radical  
   departure and significant work.  

   -Michal  


   On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux b...@brian.io wrote:  

   No, at least not how I'd see it done.  

   1.) Updating is important. Staying current: encouraged.  
   2.) I'd make my App depend on a specific CLI version. I'd call into  
  that  
   using npm scripts.  




   On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny mmo...@chromium.org  
   wrote:  

   Thinking it through, if cordova platforms are deps of the CLI, to  

   install a  

   specific version you wouldn't just do:  

   npm install -g cordova-ios@3.4.1  

   you would actually need to:  

   cd $(npm config get prefix)/lib/node_modules/cordova  
   npm install --save cordova-ios@3.4.1  

   ..and then remember to do that again whenever you `npm update -g`  
   ..and its harder to have multiple platform versions for different

Re: iOS 8 Release Notes - PhoneGap/Cordova mention

2014-06-03 Thread tommy-carlos williams

Apple actually mentioning Cordova?

Wow. heh.

On 4 June 2014 at 9:36:58, Shazron (shaz...@gmail.com) wrote:

No login required due to Apple's reforms: 
https://developer.apple.com/library/prerelease/ios/releasenotes/General/RN-iOSSDK-8.0/index.html
 

WebKit 
- Known Issues 
-- Applications that use Apache Cordova/PhoneGap are broken due to a 
bug that causes the window.navigator.userAgent object to become 
undefined when window.navigator is replaced by a pure JavaScript 
wrapper object. 

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

Re: adding platforms to npm for dependency sanity

2014-06-03 Thread tommy-carlos williams

I don’t think you really can forget about plugins for a second. 

In my personal opinion, the entire ./platforms folder should be a build 
artefact. If you want to freeze iOS, then use a branch or a new clone of the 
project. 

It’s not that I can think of no scenarios where supporting multiple platform 
versions would be needed, it’s just that I think it’s needlessly complex vs 
using a dev workflow to solve those problems.

I already version cordova within a project… I have a local version of cordova 
installed into ./node_modules for each project and use Grunt to call 
./node_modules/.bin/cordova rather than the global cordova cli.

On 4 June 2014 at 9:46:29, Terence M. Bandoian (tere...@tmbsw.com) wrote:

Forgetting about plugins for a second, what if:  

- I complete a project for iOS  
- six months later the client decides to port to Android and:  
- I want the latest fixes for Android  
- I want to keep the iOS version frozen for the time being  

I would expect releases for each platform to be on different schedules.  

-Terence  


On 6/3/2014 6:17 PM, Michal Mocny wrote:  
 Most plugins will work across a wide range of platform versions, so often  
 it would work to have disparate platform versions even with plugins.  
 However, I do concede that in general this isn't a complexity we focus on.  
  
 Interested in your thoughts about the other points.  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams to...@devgeeks.org  
 wrote:  
  
 You can’t have version x of a plugin for iOS and version y of that same  
 plugin for Android, so multiple platform versions seems like a complexity  
 for complexity’s sake.  
  
 It’s true that different apps need to support different platform versions,  
 but I would suspect that the greatest majority of those would want the same  
 version of iOS and Android in app x.  
  
  
  
 On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote:  
  
 That is the thing: you do not EVER want to have disparate versions of  
 platforms. Plugins negate this potential fantasy.  
  
 You want version locked deps. You want to use package.json to do that b/c  
 that is what the runtime we use has standardized itself on.  
  
  
 On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian tere...@tmbsw.com  
 wrote:  
  
 A typical use case might be:  
  
 -project1  
 -project1-ios  
 -project1-android  
 -project1-windows  
 ...  
 -projectN  
 -projectN-ios  
 -projectN-android  
 -projectN-windows  
  
 with a different platform version for each sub-project.  
  
 Would CLI be installed globally? Locally for each sub-project? Would a  
 project-platform have to be re-built if a plugin were added?  
  
 -Terence  
  
  
 On 6/3/2014 1:47 PM, Michal Mocny wrote:  
  
 Okay, so I think that implies:  
  
 (a) CLI versions tied to very specific platform versions == to switch  
 platform versions you must switching CLI versions == switching one  
 platform version switches all platform versions.  
 - Andrew pointed out this is currently the case, and is a problem that  
 leads to users not updating CLI as often as they otherwise would  
 - I think this basically implies platforms cannot be independently  
 versioned (sure the semver numbers may differ, but for all practical  
 purposes, you would use platforms from the same release date, based on  
 CLI  
 version).  
  
 (b) Require apps to depend on specific CLI version, assuming you mean  
 with  
 a local package.json:  
 - Now all cordova projects must be node projects, which they currently  
 are  
 not.  
 - Currently the cordova-cli creates apps, so we have a globally  
 installed  
 bootstrapping cordova-cli, and a locally installed specific version  
 cordova-cli, a-la grunt/gulp. (this idea was thrown around before).  
 - Quite a dramatic change for cordova workflow, surely larger than the  
 current proposal.  
 - Or we drop cordova-cli entirely and just publish grunt/gulp plugins to  
 add cordova to your existing web app. Thats an even more radical  
 departure and significant work.  
  
 -Michal  
  
  
 On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux b...@brian.io wrote:  
  
 No, at least not how I'd see it done.  
 1.) Updating is important. Staying current: encouraged.  
 2.) I'd make my App depend on a specific CLI version. I'd call into  
 that  
 using npm scripts.  
  
  
  
  
 On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny mmo...@chromium.org  
 wrote:  
  
 Thinking it through, if cordova platforms are deps of the CLI, to  
 install a  
  
 specific version you wouldn't just do:  
  
 npm install -g cordova-ios@3.4.1  
  
 you would actually need to:  
  
 cd $(npm config get prefix)/lib/node_modules/cordova  
 npm install --save cordova-ios@3.4.1  
  
 ..and then remember to do that again whenever you `npm update -g`  
 ..and its harder to have multiple platform versions for different  
  
 projects  
  
 (questionable if this is useful for devs outside of cordova  
 contributors

Re: Hangout Today?

2014-05-13 Thread tommy-carlos williams

+1 Skip

On 14 May 2014 at 6:22:02 am, Shazron (shaz...@gmail.com) wrote:

+1 Skip  


On Tue, May 13, 2014 at 8:00 AM, Andrew Grieve agri...@chromium.org wrote:  

 I won't be able to make it tonight. Unless someone else wants to start it  
 up, we can just skip this month's.  
  
  
 On Tue, May 13, 2014 at 9:18 AM, Marcel Kinard cmarc...@gmail.com wrote:  
  
  Although I find the hangouts incredibly useful, I’d suggest to reschedule  
  since there is no agenda.  
   
  On May 13, 2014, at 8:11 AM, Michal Mocny mmo...@chromium.org wrote:  
   
   I'm not sure that we have an agenda, and its pretty short notice.  

   I'd be fine to reschedule.  


   On Tue, May 13, 2014 at 7:04 AM, Wargo, John john.wa...@sap.com  
 wrote:  

   Is there still a hangout scheduled for today? I've not seen any emails  
   about it lately.

Re: First stab at Next Steps article

2014-04-30 Thread tommy-carlos williams

Ray,

This looks great. 

Interesting choice to both link Brock’s “you half-assed it” article *and* list 
jQM first in the list of UI libs...

:)

On 1 May 2014 at 6:50:53 am, Ray Camden (rayca...@adobe.com) wrote:

I had 3 hours here at the airport so I took at stab at writing content for the 
Next Steps document. You can find (and edit) the document here:

https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit#

The main thing missing now (imo) is the Upgrade section. I think with that 
added - this is in a good place (at least initially).  

Thoughts, opinions, etc?

Any volunteers ready to write out the upgrade section?

Re: Proposal for cli and plugman code rearrangement

2014-04-16 Thread tommy-carlos williams

Cruel.

The only difference in the Doodle between 2pm PST and 4pm+ PST is Jesse and 
Brian.

This won’t be forgotten. You two are on my list now ;)

4am on Good Friday, here I come. Yay?

- tommy

On 17 April 2014 at 6:51:47 am, Mark Koudritsky (kam...@google.com) wrote:

Ok, according to the doodle http://doodle.com/uvyr9454pvepz3a3 tomorrow  
14:00 Eastern = 11:00 Pacific seems to be an ok time. (I hope I got the  
time zones right).  
Let's organized a hangout tomorrow.  

For the calendars:  
Thursday, April 17, 14:00 ET  
Thursday, April 17, 11:00 PT  



On Wed, Apr 16, 2014 at 4:23 PM, Brian LeRoux b...@brian.io wrote:  

 To clear up my intent, I'm proposing  
  
 1. Keep the Plugman and Cordova/CLI as separate repos that we publish as  
 discreet modules (and use npm / package.json to manage deps)  
 2. Create a new placeholder repo for staging common module extraction  
 called cordova-lib  
 3. Publish many modules from this one git repo called cordova-lib and  
 prefix any module from it with `cordova-lib` (for example  
 cordova-lib-app-create would be a great module for sharing)  
 4. Evaluate if any modules can graduate from cordova-lib to more generally  
 useful status and get their own git repos  
  
 Thoughts?  
  
  
  
 On Wed, Apr 16, 2014 at 12:28 PM, Carlos Santana csantan...@gmail.com  
 wrote:  
  
  Brian  
  yep I agree with directory cordova-lib, node_modules, common.  
  common-lib  
  I think we are on the same page.  
   
  What do you mean by published? in -package.json (published as  
  cordova-lib-plugin-install)  
   
  no actually publishing to npm registry, but just having a convention for  
  the naming of the modules all starting with cordova-lib-* and matching  
  location within repo?  
   
  {  
  version: 0.0.1,  
  name: cordova-lib-plugin-install,  
  ..  
  }  
   
  {  
  version: 0.0.1,  
  name: cordova-lib-util-a,  
  ..  
  }  
   
   
   
   
   
  On Wed, Apr 16, 2014 at 3:11 PM, Brian LeRoux b...@brian.io wrote:  
   
   I'm thinking a clean path might look something like this:  

   plugman  
   '-package.json - cordova-lib-plugin-install  

   cordova-cli  
   '-package.json - cordova-lib-plugin-install  

   cordova-lib  
   |-plugin-install  
   | '-package.json (published as cordova-lib-plugin-install)  
   etc  

   Wherein all the 'meat' ends up in cordova-lib and plugman/cordova-cli  
   become light CLI wrappers. I don't see any reason we change/remove the  
   already extracted repos for the CLI and Plugman.  




   On Wed, Apr 16, 2014 at 11:58 AM, Carlos Santana csantan...@gmail.com  
   wrote:  

I was going to suggest node_modules but I think it doesn't work for  
 us  
since we have two top level npm pacakges. If one top level npm  
 pacakge  
  in  
the repo then its fine.  
 
|cli  
| '-package.json  
| '-node_modules/util_a  
|plugman  
| '-package.json  
| '-node_modules/util_a  
 
means util_a will be duplicated in repo  
plugman/node_modules/util_a  
cli/node_modules/util_a  
 
or  
if you have  
node_module/util_a at the root, npm link ../node_modules/util_a still  
   needs  
to be done for cli and plugman node modules.  
 
that's why I suggested to do the node_modules at dev/publish time to  
populate the both node_modules one for cli and one for plugman  
 
Or maybe I missed something.  
 
The tag for smaller modules, might be tricky but at the same time not  
necessary if they are consider bundle/private and living in same repo  
 
Thanks Brian for putting the question out there on twitter  
 interesting  
feedback.  
 
--Carlos  
 
 
On Wed, Apr 16, 2014 at 2:10 PM, Brian LeRoux b...@brian.io wrote:  
 
 I thought the node_modules comment might have been cheeky.  
  (Suggesting  
   we  
 use npm to manage deps.)  
  
 Crap. Totally forgot about Good Friday. I have a one hour window  
 open  
   on  
 Thu. =(  
  
  
 On Wed, Apr 16, 2014 at 10:51 AM, Mark Koudritsky   
 kam...@google.com  

 wrote:  
  
  The tip about placing the deps under node_modules right away  
 sounds  
very  
  useful. This way the dev environment will be ready right after  
 git  
clone;  
  npm install with no extra magic.  
   
  This Friday is a holiday in Canada (Good Friday).  
   
   
  On Wed, Apr 16, 2014 at 1:45 PM, Steven Gill   
  stevengil...@gmail.com  
 
  wrote:  
   
   Git tags are not something we have talked about yet. Thanks for  
sharing  
   Brian!  




   On Wed, Apr 16, 2014 at 10:39 AM, Brian LeRoux b...@brian.io  
  wrote:  

hey guys could we add Fri to that doodle?  
 
 
I asked around for opinions and got some interesting  
 responses  
  to  
add

Re: support on phonegap/cordova? ---- Request for Cordova User Group Mailing List

2014-04-12 Thread tommy-carlos williams

+1 

This

Absolutely this.

Also, the #phonegap IRC channel on Freenode...

I do as much as I can, and there are others that help, but it’s fairly skewed 
towards the AU timezone ;)


- tommy

On 12 April 2014 at 6:44:09 am, Jesse (purplecabb...@gmail.com) wrote:

Generally though, I think everyone should spend some time on the 'phonegap' 
mailing list so they can familiarize yourself with the problems that real 
users have everyday.

issues.cordova.io down

2014-03-25 Thread tommy-carlos williams

http://brianleroux.damn-u-dave.jit.su/ is currently stopped

:/

Re: issues.cordova.io down

2014-03-25 Thread tommy-carlos williams

+1

On 26 March 2014 at 8:04:23 am, Steven Gill (stevengil...@gmail.com) wrote:

lets blame dave 


On Tue, Mar 25, 2014 at 2:01 PM, tommy-carlos williams 
to...@devgeeks.orgwrote: 

 http://brianleroux.damn-u-dave.jit.su/ is currently stopped 
 
 :/

Re: Android File and Camera plugins

2014-03-19 Thread tommy-carlos williams

Temporary is as temporary does.

My only expectation of temp files sticking around is a fear that they will stay 
around longer than I want ;)



On 20 March 2014 at 7:23:26 am, Ian Clelland (iclell...@chromium.org) wrote:

Some people are having problems working with the Camera plugin, since the 
new version of File sandboxed things. Camera sometimes creates files that 
File won't access. 

(See CB-6300 for the issue I'm thinking of specifically) 

I think that the issue comes down to Camera and File independently picking 
a temp directory to use, and sometimes picking different ones. 

I think that Camera is doing the more correct thing, by using 
Activity.getCacheDir(), rather than hard-coding /data/data/app/cache, 
but I could be convinced otherwise. My instinct is to change the temporary 
path in the File plugin, and leave camera alone. 

Does anyone have any good reasons why one would be better than the other? 
Or why one would be particularly harder to change than the other? 

I think that, being temporary and cache files anyway, it should be okay to 
change either of these locations. There shouldn't be any expectations that 
the files in either place stick around forever. Again, though, I'm willing 
to be convinced if someone has a good reason not to change one of them. 

Ian

Re: Releasing Platforms Independently

2014-03-13 Thread tommy-carlos williams

+1 for docs.

Pretty big pain point for devs.

On 14 March 2014 at 7:01:18 am, Brian LeRoux (b...@brian.io) wrote:

I definitely love the idea of making this part of the machine move faster, 
and treating platforms as a dependency of the CLI in theory should not have 
any cross cutting impacts *unless* we decide to change the plugin 
interface. Our CLI version effectively becomes the 'Cordova' version. Docs 
needs an overhaul regardless so I see no issue there. 

How do you guys think we go about tackling this? Should we consider 
starting w/ the Docs since that seems to be the squeakiest wheel? 


On Thu, Mar 13, 2014 at 9:55 AM, Michal Mocny mmo...@chromium.org wrote: 

 On Thu, Mar 13, 2014 at 11:38 AM, Andrew Grieve agri...@chromium.org 
 wrote: 
 
  I think it would be beneficial if we could release updates to platforms 
  independent from others. Why? 
  - Far easier to do one-off platform releases (e.g. quick turn-around on a 
  security update, quick turn around on iOS is broken on the latest Xcode) 
  - Platforms can release on their own schedule (big new features will get 
  released sooner) 
  
  
  This doesn't come without bumps though. I'd like to use this thread to 
  explore the idea and to enumerate what would have to change to get there. 
  
  Here are some things I can think of: 
  
  Cordova-docs: 
  - We have a version drop-down in the top-right corner. 
  - I think this would mean getting rid of the version drop down (or 
 rather, 
  not adding new entries to it). 
  - Always have people pointed at edge 
  - For things that refer to specific versions, put them inline 
  - E.g. like we do for upgrade guides 
  - When a new API is introduced  is documented, we'll have to be better 
 at 
  annotating what version it showed up in. 
  
 
 Huge +1. This is a bit of an effort, sure, but every single damn time I 
 search for a cordova question I end up on docs for cordova 2.3 or 
 something, the version switcher takes me to home, and manually editing for 
 edge doesn't always match urls. 
 
 
  
  
  Blog posts: 
  - We currently do one release announcement for all the platforms. 
  - I think it'll actually be a good thing to have shorter  more focused 
  release announcements (one post per platform) 
  
 
 I'm fine with this, but I do still think we want some special outlet to be 
 louder about larger changes much like we have been with monthly cadence 
 releases. 
 
 
  
  
  Mobile-spec: 
  - This is on the way out anyway I think, with moving tests into plugins. 
  - Even so, not a big deal to not have this strictly versioned. 
 
 
  
  cordova-js: 
  - Platforms will have cordova-js cut at different times. 
  - I don't think this is a good or a bad thing. 
  - JS versioning stamped at the top of the file: 
  - Change to have both platform version as well as JS version available 
  at runtime. 
  - JS version will just be a git describe 
  
  CLI versioning: 
  - It won't make sense to version it as CadVer-SemVer anymore 
  - This essentially kills off the idea of CadVer. 
  - That scheme wasn't working well anyways since you can't actually 
 depend 
  on the SemVer part of it in a SemVer way (you can't say 
  dependency=x.x.x-0.2) 
  - CadVer-SemVer, I think, is causing people to not update their tools 
 if 
  they aren't ready to update their platforms. 
  - With this change, we should just have CLI be SemVer only. 
  - If we move platforms to NPM, we wouldn't even need to push CLI 
 updates 
  with platforms. 
  
 
 This is another huge benefit, I think. 
 
 
  
  
  
  Anything else? Please feel free to add inline here on things I've missed 
  out, or on things you'd be concerned about changing. 
  
 
 Thanks for going over this. Sounds to me like this is almost entirely 
 upside.

Re: UX / UI: New Splash Screens Icons

2014-03-11 Thread Tommy-Carlos Williams

+1


On 12 Mar 2014, at 9:32 am, Carlos Santana csantan...@gmail.com wrote:

 Blue for mobile-spec
 
 On Tuesday, March 11, 2014, Brian LeRoux b...@brian.io wrote:
 
 omg yes
 
 
 On Tue, Mar 11, 2014 at 1:59 PM, Michal Mocny 
 mmo...@chromium.orgjavascript:;
 wrote:
 
 Idea: use one set to replace our default hello world, and another set to
 replace mobile-spec.
 
 I have a bunch of small sample apps on my phone, and can never locate
 mobile spec ;)
 
 
 On Tue, Mar 11, 2014 at 10:23 AM, Andrew Grieve 
 agri...@chromium.orgjavascript:;
 wrote:
 
 They look really good! Thanks for creating them!
 
 
 On Mon, Mar 10, 2014 at 3:35 PM, Brian LeRoux b...@brian.iojavascript:;
 wrote:
 
 hey those are sweet! I guess they could be contributed to our website
 [1]
 for others to incorporate, and again in the default example app that
 we
 generate [2]
 
 you'll need send apache a cla [3] and to follow the steps here [4]
 
 [1] http://cordova.io/artwork.html
 [2] https://github.com/apache/cordova-app-hello-world
 [3] https://www.apache.org/licenses/icla.txt
 [4] http://wiki.apache.org/cordova/ContributorWorkflow
 
 
 
 On Sun, Mar 9, 2014 at 3:26 AM, Sidney Bofah 
 sidney.bo...@neofonie.de javascript:;
 wrote:
 
 Dear team,
 
 As this is my first post here, a short intro: I'm a project manager
 from
 a
 Berlin-based, larger development company and a Hybrid/HTML5
 evangelist.
 
 I'd like to contribute something here and as a first-off, i
 reworked
 Cordovas' dated splash screen and icons and created 2 variants. I
 think
 the
 proposal fares well on all platforms.
 
 Splashscreen: https://i.cloudup.com/1PTrAENWqI.png
 
 Icon: https://i.cloudup.com/GZugN48eBF.png
 
 Of course, source PSDs with auto-export slices for all native
 sizes 
 platforms will be made available. Which one do you like more?
 
 Best Regards, Sidney
 
 --
 
 
 
 
 
 
 
 -- 
 Carlos Santana
 csantan...@gmail.com

Re: [cordova-plugins/statusbar] Publishing as core

2014-03-10 Thread Tommy-Carlos Williams

+1


On 11 Mar 2014, at 5:52 am, Brian LeRoux b...@brian.io wrote:

 While I wholeheartedly agree plugins, clean separation of concerns,
 discreet repos, all have big benefits if every single developer installs a
 plugin on day 1 that is specific to a particular platform I feel that might
 be a good indication the platform should conditionally roll that plugin in.
 I think the statusbar might quality.
 
 
 
 
 On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron 
 jbo...@gdesolutions.com wrote:
 
 On Mon Mar 10 12:51 PM, Michal Mocny wrote:
 
 I think we can solve that problem using a plethora of better
 alternatives, including
 install scripts (perhaps with a generator
 like yeoman, perhaps my just pasting
 snippets in tutorials), by
 supporting plugin dependencies for platforms, or just by
 hard coding
 a list of default plugins in cordova-cli (we do this in cca for
 example).
 Many alternatives exist.
 
 
 Kind of agree, I like the idea of keeping plugins outside of platforms.
 
 What Cordova needs is better default workflows, e.g.
 
 cordova platform add android
 cordova plugin add chrome-web-dev  (install script sets up what you need +
 dependencies)
 
 cordova platform add windows8
 cordova plugin add microsoft.net-dev  (install script sets up what you
 need + dependencies)
 
 With this in mind, I think it's a little more obvious how upstream
 distributions could diverge from cordova.
 
 In that sense, I'm -1 to:
 supporting plugin dependencies for platforms

Re: Delete some undocumented Android things?

2014-03-03 Thread Tommy-Carlos Williams

My suggestion would be that it’s a preference and that the Media plugin sets it.

So, if you have an app without the Media API, it controls the phone volume, but 
if you add the Media API it starts controlling the media volume unless you 
explicitly go in and change it.

- tommy



On 4 Mar 2014, at 7:46 am, Andrew Grieve agri...@chromium.org wrote:

 Maybe we could even go as far as making the media plugin change the media
 volume only when a sound is playing?

Re: Monthly Hangouts!

2014-03-01 Thread Tommy-Carlos Williams

 Also might be neat if everyone could share 1 or 2 bugs that they think are
 important to fix.


I think at the moment, the number one bug for me is the icons and splash 
screens. I know there has been work on this, but I’d love to know where we are 
at with it and see if there is anything we still need to bang out for it to 
happen.

It’s starting to get a bit embarrassing to answer questions about :/

 I've picked out mid-month Tuesdays and have alternated how early Tommy has
 to wake up to attend:

You are the best :)

Re: Introduction

2014-02-18 Thread Tommy-Carlos Williams

Maybe some kind of IndexedDBShim[1] of sorts? ;)

https://github.com/axemclion/IndexedDBShim

On 19 Feb 2014, at 8:56 am, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Personally, I think our time would be better served adding an indexedDB 
 polyfil to iOS, that would be backed by WebSQL

Re: Need to revert a CLI breaking change causing CB-5957

2014-02-05 Thread Tommy-Carlos Williams

Andrew,

Didn’t you get a phone at PhoneGap Day?

Were you too much of a “presenter” at the workshop to get one? ;)

If I ever get around to getting set up for WP8 I will try and help test… will 
probably happen after I finish our Blackberry10 port.

- tommy

On 6 Feb 2014, at 9:00 am, Andrew Grieve agri...@chromium.org wrote:

 Just to be clear - it's not enough to test on windows, this breaks only for
 windows phone / win8 I think.
 
 That said, I've recently got set up with VMs and modern.ie. Is that enough
 to test out Hello World on a WP emulator?
 
 
 On Wed, Feb 5, 2014 at 4:03 PM, Michal Mocny mmo...@chromium.org wrote:
 
 First off, Jesse I appreciate your respectable tone here, thank you.
 
 I agree, this is a sign that we generally don't test nearly enough on
 windows, and should fix that.  As someone who also reviewed the work Mark
 was doing here, sorry this wasn't caught.
 
 I'll just add that I think the tests should have been run before the
 *tooling release* (and even better, on a regular basis with CI as stated),
 not necessarily before every patch to tip of tree lands.  The majority of
 changes do not affect specific platforms in subtle ways -- and while we
 should absolutely have process to catch those that do -- any process that
 involves manually testing in multiple configurations for every single patch
 is prohibitive and I think unrealistic.
 
 That change was committed a month ago -- how did we not catch it before
 release?
 
 To decrease the odds of this happening again, perhaps we need to amend the
 steps for tooling release (
 http://wiki.apache.org/cordova/StepsForToolsRelease) to ensure testing on
 all the platforms?
 
 -Michal
 
 
 On Wed, Feb 5, 2014 at 2:34 PM, Jesse purplecabb...@gmail.com wrote:
 
 I would think it would be enough to just make sure that :
 1. our tests catch the issue
 2. the tests are run on windows/mac/linux before an npm publish
 
 I agree Mark, the change is valuable, and I don't mean to single you
 out. I
 am just concerned about how it made it to npm while obviously broken on
 windows devices.
 
 @purplecabbage
 risingj.com
 
 
 On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky kam...@google.com
 wrote:
 
 Some CI for plugman and CLI on Windows would be extremely useful. I
 just
 looked briefly at Travis-CI
 http://docs.travis-ci.com/user/getting-started/,
 but they only have Linux and OS
 Xhttp://docs.travis-ci.com/user/osx-ci-environment/.
 Here is a random Windows based service I just found
 http://www.appveyor.com/,
 didn't check if it's usable for our case. Of course, this solution
 would
 only be for the host side tools, not for on-device tests which are the
 most
 important ones.
 
 That commit was part of this review
 https://reviews.apache.org/r/15775/ dealing
 with CB-4153 https://issues.apache.org/jira/browse/CB-4153. But
 since
 the
 patch (probably prepared with git format-patch) contained two separate
 commits and the second one didn't have a reference to the bug, there is
 no
 way to deduce that reference. The lesson for me is to add CB-:
 prefix
 to each commit message in a series of related commits. The check was
 added
 to verity that config.xml does look like it's a Cordova related
 config.xlmbecause with the new --link-to tag a random file named
 config.xml by chance could be sitting in that www dir.
 
 
 On Wed, Feb 5, 2014 at 2:14 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
 I'm going to agree with Jesse. That commit should not have made it
 out
 to
 the wild without a platform tag increase. It is fine to go out for
 3.4.
 
 Either we take the commit out and release the CLI again or we revert
 the
 CLI to two versions ago (3.3.1-0.2.0) and focus on getting 3.4.0.
 
 Thoughts?
 
 
 On Wed, Feb 5, 2014 at 10:41 AM, Parashuram Narasimhan (MS OPEN
 TECH) 
 panar...@microsoft.com wrote:
 
 Is there a way we could have a continuous integration process for
 the
 CLI
 too ?
 
 -Original Message-
 From: Jesse [mailto:purplecabb...@gmail.com]
 Sent: Wednesday, February 5, 2014 9:54 AM
 To: dev@cordova.apache.org
 Subject: Need to revert a CLI breaking change causing CB-5957
 
 WP8+7 and Windows8 users are currently unable to create new
 projects
 WP8+with
 the CLI because this commit [1] has shipped.
 
 Here is an issue raised on the subject [2] While I have addressed
 the
 issue by adding the namespace to the widget tag in the platform
 create
 templates for the affected platforms, until
 3.4.0 ships this will continue to break.
 
 I am unhappy about how this landed without discussion, or an issue
 in
 jira, but ultimately this is just a symptom of the fact that not
 enough
 people test on WP7+8 and Windows 8.
 Please try to test all platforms before landing changes to
 cordova-cli,
 cordova-plugman and cordova-js or at least tread lightly and try to
 aware
 of the impact outside of your pet platforms.  I am always available
 to
 discuss possible impacts.
 
 Cheers,
  Jesse
 
 [1]

Re: Adding SSL Certificate Pinning to Cordova

2014-01-23 Thread Tommy-Carlos Williams

Marcel,

Are you saying that CordovaWebviewClient.onReceivedSslError can’t get the
actual cert?

Oh… the SslCertificate object returned by SslError.getCertificate is mostly
about the DN.

*sigh*

I’ll have a look and see if I can come up with something. Back to the
proverbial.

- tommy

On 24 Jan 2014, at 4:34 am, Marcel Kinard cmarc...@gmail.com wrote:

Although Moxie's point may be a bit radical, I think it is a valid scenario.

It would be nice implement this. I'd even be willing to do it, since I have a
customer that wants this too. I'm familiar only with Android, but I'm still
struggling to see a way to do this there: the
CordovaWebViewClient.onReceivedSslError method will get called only for
self-signed certs (so it doesn't cover the full pinning scenario that has a
valid CA), but even if you are OK with that the cert data available doesn't
include the server's public key (the self DN and issuer DN isn't
authoritative enough to do the pin comparison).

If there are implementation alternatives I'm missing, I'm all ears.

On Jan 22, 2014, at 8:08 PM, Tommy-Carlos Williams to...@devgeeks.org wrote:

I am reconsidering the “deal breaker” status of only working with
self-signed certs.

In one of the articles I have been using as a reference[1], Moxie
Marlinspike actually prefers the option of doing away with the CAs entirely
for mobile apps and doing exactly that[2].

I can certainly think of a way that it would work better for our use case.
The only use case harmed would be wanting to pin the certs of third party
services like Parse, etc.

I guess it comes down to… is it better to do something for some people than
nothing for anyone. If it could be done in a way that only impacted those
that opted in, surely the former beats the latter.

- tommy

1.
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
2.
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/#option_1_wipe_the_page_clean

Re: Adding SSL Certificate Pinning to Cordova

2014-01-22 Thread Tommy-Carlos Williams

I am reconsidering the “deal breaker” status of only working with self-signed
certs.

In one of the articles I have been using as a reference[1], Moxie Marlinspike
actually prefers the option of doing away with the CAs entirely for mobile apps
and doing exactly that[2].

I can certainly think of a way that it would work better for our use case. The
only use case harmed would be wanting to pin the certs of third party services
like Parse, etc.

I guess it comes down to… is it better to do something for some people than
nothing for anyone. If it could be done in a way that only impacted those that
opted in, surely the former beats the latter.

- tommy

1.
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
2.
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/#option_1_wipe_the_page_clean

On 15 Jan 2014, at 7:30 am, Tommy Williams to...@devgeeks.org wrote:

Yeah, only working with self-signed certs is kind of a deal breaker.

Most apps consume an api/server that is also consumed by webapps.

Thanks for still thinking about this...

On 15/01/2014 3:41 am, Marcel Kinard cmarc...@gmail.com wrote:
And onReceivedSslError would cover the self-signed scenario, but it wouldn't
cover the real pinning scenario with a properly signed cert, because it gets
invoked only on a handshake failure, not a handshake success.

On Jan 14, 2014, at 11:38 AM, Marcel Kinard cmarc...@gmail.com wrote:

I've played with that recently, and it may do most of what you want.

The method CordovaWebViewClient.onReceivedSslError does get called when
attempting an SSL handshake with a server that has a self-signed cert. I
tested this using a href and window.open(_self).

When setting the app to debuggable=true in AndroidManifest.xml, the
onReceivedSslError() method will treat this as a special case, and
basically ignore the SSL error by always calling SslErrorHandler.proceed().
Once proceed() has been called, subsequent SSL connections to that server
will not result in onReceivedSslError() getting called - once that
self-signed cert has been accepted, subsequent requests are considered
accepted also. This acceptance is persistent only for the duration of a
single application execution - if the application is restarted, it forgets
the acceptance. According to the docs, WebView.clearSslPreferences() might
reset that.

When using debuggable=false, it takes a different path in
onReceivedSslError() and it doesn't eat the error, and the connection
fails. I think at this point what you'd want to do is inspect the cert to
see if it matches what you want, and then call proceed() if it is good.
However, I think the last sticking point (from what I see in the javadocs)
is that although you are handed an SslCertificate object in
onReceivedSslError, the methods on SslCertificate will get you only the
human-readable info (self DN, issuer DN, valid date) and not the actual
public key. So all you can check is the DN, which I don't think is good
enough. I don't see a way to work around that by getting the raw pem or
similar.

On Jan 14, 2014, at 10:42 AM, Andrew Grieve agri...@chromium.org wrote:

Actually, looking again, there's a custom API just for SSL certs that
will provide you the cert to check: onReceivedSslError().

Re: 2014 planning F2F / Google Hangout

2014-01-16 Thread Tommy-Carlos Williams

I can make it… maybe… omg4:30am… I can do it, no promises I’ll be smart though 
;)



On 17 Jan 2014, at 6:29 am, Brian LeRoux b...@brian.io wrote:

 Lets go w/ 9:30am Wed 29th
 
 I'll send an email reminder to the list.
 
 (Only person who can't make it is Axe / sorry dude!)
 
 
 On Thu, Jan 16, 2014 at 11:01 AM, Joe Bowser bows...@gmail.com wrote:
 
 So, when is this happening?
 
 On Tue, Jan 14, 2014 at 6:33 PM, Andrew Grieve agri...@chromium.org
 wrote:
 If anyone wants to take ownership of an agenda item, I think that
 would help keep things more organized. Maybe put your name next to the
 item on the wiki page?
 
 On Tue, Jan 14, 2014 at 5:04 PM, Parashuram Narasimhan (MS OPEN TECH)
 panar...@microsoft.com wrote:
 MS Open Tech would be hosting this in Seattle/Redmond. Could not edit
 the wiki page for some reason.
 
 -Original Message-
 From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf
 Of Brian LeRoux
 Sent: Tuesday, January 14, 2014 1:54 PM
 To: dev@cordova.apache.org
 Subject: Re: 2014 planning F2F / Google Hangout
 
 Sadly ya. We could spin up an afternoon (PST) recap?
 
 
 On Tue, Jan 14, 2014 at 1:32 PM, Tommy-Carlos Williams
 to...@devgeeks.orgwrote:
 
 ugh... 4:30-6:30 am ;)
 
 
 On 14/01/2014, at 6:17 AM, Brian LeRoux b...@brian.io wrote:
 
 I put together a doodle of potential dates/times to have the hangout
 [1] and a wiki page for planning the agenda [2].
 
 We can host in Adobe San Francisco (if you can host pls add your
 office
 to
 the wiki page.)
 
 [1] http://doodle.com/87ksdqnpi5aeebmd
 [2] https://wiki.apache.org/cordova/2014%20Kickoff%20Hangout

Re: 2014 planning F2F / Google Hangout

2014-01-16 Thread Tommy-Carlos Williams

Brian,

Let’s see if I can wake up :)


On 17 Jan 2014, at 11:03 am, Brian LeRoux b...@brian.io wrote:

 Tommy we could do a recap meeting in the afternoon too. Planning for an
 entire day. (Also we'll update the list of course.)
 
 
 On Thu, Jan 16, 2014 at 1:20 PM, Tommy-Carlos Williams
 to...@devgeeks.orgwrote:
 
 I can make it… maybe… omg4:30am… I can do it, no promises I’ll be smart
 though ;)
 
 
 
 On 17 Jan 2014, at 6:29 am, Brian LeRoux b...@brian.io wrote:
 
 Lets go w/ 9:30am Wed 29th
 
 I'll send an email reminder to the list.
 
 (Only person who can't make it is Axe / sorry dude!)
 
 
 On Thu, Jan 16, 2014 at 11:01 AM, Joe Bowser bows...@gmail.com wrote:
 
 So, when is this happening?
 
 On Tue, Jan 14, 2014 at 6:33 PM, Andrew Grieve agri...@chromium.org
 wrote:
 If anyone wants to take ownership of an agenda item, I think that
 would help keep things more organized. Maybe put your name next to the
 item on the wiki page?
 
 On Tue, Jan 14, 2014 at 5:04 PM, Parashuram Narasimhan (MS OPEN TECH)
 panar...@microsoft.com wrote:
 MS Open Tech would be hosting this in Seattle/Redmond. Could not edit
 the wiki page for some reason.
 
 -Original Message-
 From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On
 Behalf
 Of Brian LeRoux
 Sent: Tuesday, January 14, 2014 1:54 PM
 To: dev@cordova.apache.org
 Subject: Re: 2014 planning F2F / Google Hangout
 
 Sadly ya. We could spin up an afternoon (PST) recap?
 
 
 On Tue, Jan 14, 2014 at 1:32 PM, Tommy-Carlos Williams
 to...@devgeeks.orgwrote:
 
 ugh... 4:30-6:30 am ;)
 
 
 On 14/01/2014, at 6:17 AM, Brian LeRoux b...@brian.io wrote:
 
 I put together a doodle of potential dates/times to have the hangout
 [1] and a wiki page for planning the agenda [2].
 
 We can host in Adobe San Francisco (if you can host pls add your
 office
 to
 the wiki page.)
 
 [1] http://doodle.com/87ksdqnpi5aeebmd
 [2] https://wiki.apache.org/cordova/2014%20Kickoff%20Hangout

Re: Configuring the File plugin

2014-01-14 Thread Tommy-Carlos Williams

Sorry…

I have been trying not to chicken-little this thread, but I just need some 
clarification on some things.

My understanding, please correct me if I am wrong:

The “old location on iOS is not the best location for files the dev doesn’t 
want exposed, but it *is* where they should be if the dev wants them accessible 
via iTunes

Assuming this is correct, I have some questions:

1. What if that’s where the dev *wants* the files to go?
2. Could files still be backed up by iCloud if they were in the new location?


It feels like making assumptions about what kinds of files developers are using 
the File API for.

:/

- tommy 



On 15 Jan 2014, at 7:09 am, Ian Clelland iclell...@chromium.org wrote:

 On Tue, Jan 14, 2014 at 2:52 PM, Brian LeRoux b...@brian.io wrote:
 
 Wait, users lose data IF they upgrade the plugin. Is that correct?
 
 
 *If* we change the default storage location, and *if* a developer upgrades
 the file plugin without looking too closely (because, hey, newer is always
 better, right?) and pushes a new version of the app to existing users, then
 yes, users will lose access to the data that they previously had stored.
 
 Technically, they aren't losing the data; it's still possible to get to it,
 someday, maybe, if the developer does a lot of work to fix the app, and it
 hasn't ended up in some inconsistent state -- it's not deleted, though.
 
 And I do believe that developers will do that, too. Maybe not the good ones
 :) But people will gloss over the upgrade instructions, read the warnings
 without thinking oh, that affects my users, and publish away.
 
 
 
 
 On Tue, Jan 14, 2014 at 10:53 AM, Ian Clelland iclell...@chromium.org
 wrote:
 
 On Tue, Jan 14, 2014 at 1:44 PM, Brian LeRoux b...@brian.io wrote:
 
 So, to be clear and terse: what are the use cases / why are we adding
 more
 config?
 
 
 1. NSDocumentsDirectory is a stupid place to put the HTML filesystem on
 iOS. NSLibraryDirectory is a more sensible place, and I'd love to change
 it
 as part of this rollout, *but*
 2. If we change it unilaterally, real users are going to lose access to
 real data.
 
 Also,
 3. The File plugin is much more modular now, and we could potentially
 have
 a whole ecosystem of Filesystem providers making filesystem-shaped
 things,
 but it needs to be configurable to be useful.
 
 #3 is less important at the moment, but becomes more compelling if we
 provide the machinery for other devs to take advantage of it.
 
 
 
 
 On Tue, Jan 14, 2014 at 10:34 AM, Ian Clelland iclell...@chromium.org
 wrote:
 
 On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve 
 agri...@chromium.org
 wrote:
 
 On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland 
 iclell...@chromium.org
 
 wrote:
 On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve 
 agri...@chromium.org
 
 wrote:
 
 I think we need two things for transitioning to different
 PERSISTENT /
 TEMPORARY locations:
 1. The ability for the user to retrieve the files at the old
 location
 (so they can be moved to the new location)
 2. The ability to turn turn on the change with a switch (e.g.
 preference name=IosUseLegacyFileSystemPath value=true /)
 
 I'd love for the default to be the new locations so that new
 apps
 don't forget to turn on the preference and find out they need to
 migrate later on.
 
 
 This is the really dangerous bit, though. If we make the default
 anything
 but the current behaviour, then devs *will* update their plugins
 and
 push,
 and users *will* lose the ability to access old saved files. We
 will
 absolutely encounter the situation where developers test their
 app
 with
 blank filesystems, and everything works fine, but data is
 rendered
 inaccessible to users who upgrade from an old version. And I'm
 sure
 it'll
 happen no matter how loudly we announce the change.
 
 I would sooner make the new plugin be broken by default, so
 that
 the
 app
 doesn't even start until you add a configuration preference, one
 way
 or
 the
 other. Then we could recommend at that time, if you have an
 existing
 app
 with users, then use the old value; if this is a brand new app,
 use
 the
 new
 one.
 
 I really like this idea!
 
 
 Also - the simpler our instructions can be, the better. I don't
 think
 most devs even realize that they are doing a foolish thing with
 the
 way things are set up right now, so telling them to configure
 their
 own paths might put too much of a burden on them (they'd have to
 learn
 where files should go, and then also figure out how our config
 syntax
 works).
 
 
 True. The simple case should be as simple as possible. Ideally,
 doing
 nothing at all should get them some reasonable behaviour,
 compatible
 with
 previous versions.
 
 
 
 The case of adding new FS roots is compelling, but I think most
 users
 would appreciate FS roots for content, assets, sdcard, etc to be
 pre-built-in rather than have to wire them up themselves.
 
 
 Agreed. Those ones should be available out-of-the-box, either as
 part
 of
 File, or as part of a related

Re: Adding SSL Certificate Pinning to Cordova

2014-01-13 Thread Tommy-Carlos Williams

Well, I blathered on for all of that and didn’t actually really describe what
cert pinning is.

Sorry about that.

This [1] is a pretty decent tl;dr version from stack exchange.

“Typically certificates are validated by checking the signature hierarchy;
MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert
is listed in my computer's certificates to trust store.
Certificate Pinning is where you ignore that whole thing, and say trust this
certificate only or perhaps trust only certificates signed by this certificate.

So for example, if you go to google.com, your browser will trust the
certificate if it's signed by Verisign, Digicert, Thawte, or the Hongkong Post
Office (and dozens others). But if you use (on newer versions) Microsoft
Windows Update, it will ONLY trust certificates signed by Microsoft. No
Verisign, no Digicert, No Hongkong Post office.”

The concept of a Man in the Middle attack is that the attacker can pretend to
be the server your app is trying to connect to securely or even sit in between
passing traffic to the server after inspecting it unsecured (passwords, credit
card or banking details, etc). One of the ways they do this is with a SSL
certificate signed by a different authority to the one your server’s
certificate is signed by. Still valid as far as the browser (or webView) is
concerned, just not YOUR server’s certificate.

This OWASP article [2] is a much more in depth look at the issue, and there is
also a good article by Moxie Marlinspike [3] about securing mobile apps that
mentions certificate pinning [4] as one of the solutions.

1. http://security.stackexchange.com/a/29990
2. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
3.
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
4.
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/#option_2_trust_but_verify

On 14 Jan 2014, at 6:29 am, Brian LeRoux b...@brian.io wrote:

So, sort of like CRSF tokens except the other way around. ???

I might be misunderstanding but would it not be better to treat the server
as trusted and the client generally as untrusted. Given there is no cross
platform key stores the certs are effectively plaintext (but I could be
misunderstanding the impl).

On Sun, Jan 12, 2014 at 3:21 AM, Tommy-Carlos Williams
to...@devgeeks.orgwrote:

TL;DR: I am proposing to add certificate pinning at least to iOS and
Android, and help on any implementations for other platforms in any way I
can.

(Longer version)

There is an existing issue for certificate pinning [1] from back in May of
2013 and it's something that I need for all of our apps and even any I
might make for myself in the future.

The last year or two have seen a pretty serious rise in both actual
exploits and awareness around the topic of security. There was an article
tweeted around recently about someone auditing mobile bank apps and found
that 40% of the audited apps did not validate the authenticity of SSL
certificates presented. This makes them susceptible to Man in The Middle
(MiTM) attacks [2].

If certificate pinning is something good, and we can make it easy to
implement, surely that would be a good thing? The whitelist is all well and
good, but most people are probably leaving the default * and even if they
didn't, it wouldn't protect them from MitM attacks.

There *is* an existing plugin that attempts to do this for Cordova /
PhoneGap [3][4], but it has a pretty massive and fairly obvious flaw. It
simply checks the certificate then reports back in its callback. At first
this might seem OK, but as someone pointed out in an issue [5], an attacker
could wait until the server is validated before adding the MITM server,
circumventing the security check. I am no security expert, so if I could
think of a way to get around this, then it's not very secure.

What I am proposing, is adding certificate pinning to Cordova itself so
that the *actual* requests are checked (much like the whitelist). Not some
initial request, or having to try and do two requests for every request
(still leaving open the hole I spoke of above).

I am looking for buy-in from the list, but I am also interested in
discussion on the best way to do it (and test it).

My initial proposal is to use SHA1 fingerprints (much like Eddy's plugin
above [6]) as opposed to trying to get devs to embed an entire cert file in
their app. The easier it is to use the more likely people are to use it. If
they can get the fingerprint from any site they want to safely access by
simply using Chrome/Safari/etc, or a basic cli command, that would be best.
I envisage devs being able to even pin the certs for third party services
like Parse etc.

A simple config.xml directive with key/value pairs of any
hosts/fingerprints should be all a dev needs to use this feature.

- tommy

1. https://issues.apache.org/jira/browse

Re: Adding SSL Certificate Pinning to Cordova

2014-01-13 Thread Tommy-Carlos Williams

It’s not just for self-signed certs either.

Google Chrome already does a variation of this (hardcoded) for Google’s certs.

I envisage developers being able to pin the certs for their own servers, but
even for services they use over SSL like parse.com and other BaaS provides.

The reason I am proposing the SHA1 fingerprint over the .cer file is that it’s
easier to get the fingerprint and include a string in a config.xml directive
than it is to include a .cer file. The easier it is to use, the more likely
devs will use it.

- tommy

On 14 Jan 2014, at 8:16 am, Andrew Grieve agri...@chromium.org wrote:

I think the proposal is to include a white-list of self-signed certs
within apps (or is it to use *only* the whitelist and reject otherwise
valid certs?).

I think it'd be great to have this feature. It's certainly been asked
for several times.

The referenced plugin certainly is a good reference to how to get at
the certificates. I don't know whether use the SHA1 of the public
certificate, or just a .cer file is easier, but I think they are both
easy-enough and I don't believe you lose any security by using a SHA1.

So, this all sounds great to me!

On Mon, Jan 13, 2014 at 2:29 PM, Brian LeRoux b...@brian.io wrote:
So, sort of like CRSF tokens except the other way around. ???

On Sun, Jan 12, 2014 at 3:21 AM, Tommy-Carlos Williams
to...@devgeeks.orgwrote:

TL;DR: I am proposing to add certificate pinning at least to iOS and
Android, and help on any implementations for other platforms in any way I
can.

(Longer version)

There is an existing issue for certificate pinning [1] from back in May of
2013 and it's something that I need for all of our apps and even any I
might make for myself in the future.

I am looking for buy-in from the list, but I am also interested in
discussion on the best way to do it (and test it).

A simple config.xml directive with key/value pairs of any
hosts/fingerprints should be all a dev needs to use this feature.

- tommy

1. https://issues.apache.org/jira/browse/CB-3498
2.
http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-through.html
3.
http://www.x-services.nl/certificate-pinning-plugin-for-phonegap-to-prevent-man-in-the-middle-attacks/734
4. https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin
5.
https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin/issues/5
6.
https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin#3-usage

Re: Adding SSL Certificate Pinning to Cordova

2014-01-13 Thread Tommy-Carlos Williams

Marcel,

Well, I was hoping it would not come down to custom TrustManagers. I was hoping 
to hook into the CordovaWebViewClient’s shouldInterceptRequest().

I realise this is in API 11+, but don’t know of another way off the top of my 
head (was hoping this thread could help, yay).

Is the issue related to that “security hole” thread where the whitelist isn’t 
checked with ajax/xhr on API  11 ?




On 14 Jan 2014, at 8:53 am, Marcel Kinard cmarc...@gmail.com wrote:

 I am curious how this would be implemented on Android. If you construct an 
 SSLSocketFactory with your private TrustManager that contains the pinned 
 cert, how do you get the Android webview to use that SSLSocketFactory?

Re: Adding SSL Certificate Pinning to Cordova

2014-01-13 Thread Tommy-Carlos Williams

I guess the answer for core would then lie in custom trust managers after all?

Would a custom X509TrustManager even be consulted by the webView?


On 14 Jan 2014, at 1:28 pm, Andrew Grieve agri...@chromium.org wrote:

 Implementation notes that come to mind:
 
 Android:
 I think this will actually be impossible to do on Android :(.
 shouldInterceptRequest is the closest thing you'd need, as it's your
 hook for overriding network requests. However, it exposes only the URL
 that is being requests. Not the HTTP method, not any request headers,
 not the request payload. :(. You could add it in for FileTransfer
 though. You could also add it in using a strange different API (e.g.
 set headers, method, payload using exec(), then use an XHR to fire the
 request). For GET requests, it matters less since you can get the
 Cookies for it, but still are lacking custom headers.
 
 iOS:
 URLProtocol is the way to go. As long as the URL is whitelisted,
 Cordova's won't touch it and your registered protocol will pick it up.
 CDVProtocol should at least provide a helper method for mapping a
 request to a UIWebView though. But I do think multiple URLProtocol
 handlers will work fine.
 From past experience, if you use NSURLConnection to implement all
 UIWebView requests, then it will work just fine... except for hanging
 gets. NSURLConnection buffers responses and so won't trickle data down
 to you as it comes, which hanging gets require. Not a big deal...
 unless you want to use a hanging get.
 
 
 
 
 
 
 
 On Mon, Jan 13, 2014 at 5:13 PM, Joe Bowser bows...@gmail.com wrote:
 On Mon, Jan 13, 2014 at 2:00 PM, Tommy-Carlos Williams
 to...@devgeeks.org wrote:
 Marcel,
 
 Well, I was hoping it would not come down to custom TrustManagers. I was 
 hoping to hook into the CordovaWebViewClient’s shouldInterceptRequest().
 
 I realise this is in API 11+, but don’t know of another way off the top of 
 my head (was hoping this thread could help, yay).
 
 Is the issue related to that “security hole” thread where the whitelist 
 isn’t checked with ajax/xhr on API  11 ?
 
 
 Yup.  There's no such thing as shouldInterceptRequest() in
 Gingerbread.  I think we should just assume that anyone who owns a
 Gingerbread phone is already owned based on the tons of other known
 security flaws on that device and just move on.
 
 
 
 
 On 14 Jan 2014, at 8:53 am, Marcel Kinard cmarc...@gmail.com wrote:
 
 I am curious how this would be implemented on Android. If you construct an 
 SSLSocketFactory with your private TrustManager that contains the pinned 
 cert, how do you get the Android webview to use that SSLSocketFactory?

Adding SSL Certificate Pinning to Cordova

2014-01-12 Thread Tommy-Carlos Williams

TL;DR: I am proposing to add certificate pinning at least to iOS and Android,
and help on any implementations for other platforms in any way I can.

(Longer version)

There is an existing issue for certificate pinning [1] from back in May of 2013
and it's something that I need for all of our apps and even any I might make
for myself in the future.

The last year or two have seen a pretty serious rise in both actual exploits
and awareness around the topic of security. There was an article tweeted around
recently about someone auditing mobile bank apps and found that 40% of the
audited apps did not validate the authenticity of SSL certificates presented.
This makes them susceptible to Man in The Middle (MiTM) attacks [2].

If certificate pinning is something good, and we can make it easy to implement,
surely that would be a good thing? The whitelist is all well and good, but most
people are probably leaving the default * and even if they didn't, it
wouldn't protect them from MitM attacks.

There *is* an existing plugin that attempts to do this for Cordova / PhoneGap
[3][4], but it has a pretty massive and fairly obvious flaw. It simply checks
the certificate then reports back in its callback. At first this might seem OK,
but as someone pointed out in an issue [5], an attacker could wait until the
server is validated before adding the MITM server, circumventing the security
check. I am no security expert, so if I could think of a way to get around
this, then it's not very secure.

What I am proposing, is adding certificate pinning to Cordova itself so that
the *actual* requests are checked (much like the whitelist). Not some initial
request, or having to try and do two requests for every request (still leaving
open the hole I spoke of above).

I am looking for buy-in from the list, but I am also interested in discussion
on the best way to do it (and test it).

My initial proposal is to use SHA1 fingerprints (much like Eddy's plugin above
[6]) as opposed to trying to get devs to embed an entire cert file in their
app. The easier it is to use the more likely people are to use it. If they can
get the fingerprint from any site they want to safely access by simply using
Chrome/Safari/etc, or a basic cli command, that would be best. I envisage devs
being able to even pin the certs for third party services like Parse etc.

A simple config.xml directive with key/value pairs of any hosts/fingerprints
should be all a dev needs to use this feature.

- tommy

1. https://issues.apache.org/jira/browse/CB-3498
2. http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-through.html
3.
http://www.x-services.nl/certificate-pinning-plugin-for-phonegap-to-prevent-man-in-the-middle-attacks/734
4. https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin
5.
https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin/issues/5
6.
https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin#3-usage

Re: Dropping iOS 5.0 support

2013-12-19 Thread Tommy-Carlos Williams

+1


On 20 Dec 2013, at 4:32 am, Shazron shaz...@gmail.com wrote:

 Starting Feb 1st, 2014, Xcode 5 is required:
 https://developer.apple.com/news/index.php?id=12172013a
 
 This is the perfect time to drop iOS 5.0 support, and support arm64. I
 would say the Jan 2014 release should have this change.
 
 See:
 https://issues.apache.org/jira/browse/CB-4863
 https://issues.apache.org/jira/browse/CB-5286
 
 
 
 On Tue, Sep 17, 2013 at 3:45 PM, Shazron shaz...@gmail.com wrote:
 
 On the eve of the launch of iOS 7, I filed this issue:
 https://issues.apache.org/jira/browse/CB-4863
 
 I left the Fix version empty for now...

Re: [android] How to remove the automatic default of access origin=*/

2013-12-04 Thread Tommy-Carlos Williams

+1 

This is all sounding great and no matter how much I love the CLI, supporting 
both workflows is important.




On 5 Dec 2013, at 6:13 am, Michal Mocny mmo...@chromium.org wrote:

 Yes, there is no need to change the tools, which is why I like this
 approach.  I forgot to mention that part :P
 
 I did not think we previously discussed supplying both config files with
 different default settings.  I had previously imagined we would ship
 platforms with only one defaults file (defaults.xml/config.xml whichever
 name) that was consumed by both flows.  The function of a defaults.xml was
 as an implementation detail of CLI to help us treat config.xml as a build
 artifact.  Now I am proposing using it as a first class config file that
 gets maintained along with config.xml in platform releases.
 
 -Michal
 
 
 On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson bra...@google.comwrote:
 
 It's possible I'm misunderstanding something here, but the flow you
 described here is exactly the one we intended when designing how
 details.xml was going to work. Platforms ship both files, cli uses
 defaults.xml where available, and config.xml where not. Platform scripts
 use config.xml always.
 
 I don't think any (many?) Changes to the tools will be necessary to support
 this.
 
 Braden
 On Dec 4, 2013 8:25 AM, Michal Mocny mmo...@chromium.org wrote:
 
 Alright,  Andrew and I discussed this and think we have a resolution that
 works with all the use cases (yay for options).
 
 TLDR; I think we already (accidentally?) support using a different
 default
 platform config file for each of our two workflows.  This means we can
 have
 the access origin=* tag live inside the platform config for
 platform-centric workflow, and inside the app config for app-centric
 workflow.  This means users less surprise for end users, and downstream
 distributions can more sensibly override these types of defaults should
 they chose to.
 
 
 
 Most platforms don't ship with a defaults.xml file yet (except for BB;
 because Jeff did this work, he followed through for that platform).
 There
 are open bugs to add these (ie, CB-5047).
 
 Jeff also added a nice fallback to the CLI: if there does not exist a
 defaults.xml when running prepare, backup the initial config.xml to a
 defaults.xml file before we go messing everything up with plugin / app
 settings.  Effectively the config.xml that ships with platforms is the
 defaults.xml for platforms that don't have one explicitly added.  This
 is a
 great default.
 
 However, if there actually were a defaults.xml, the CLI would consume
 that
 for its initial input in the prepare process, and completely ignore the
 platform config.xml.  The bin/create script would completely ignore the
 defaults.xml file and use only the config.xml file.
 
 So, if we shipped both a config.xml *and* defaults.xml, we could choose
 which settings to set for each workflow.  I don't actually think the
 settings should generally differ, and its mildly annoying that we would
 have mostly duplicated files, but it means we can move such optional
 settings as access or dependency etc out of the platform config, and
 into the default app config which lives in cordova-cli, since that is
 where
 users of the CLI expect them to be.
 
 Note that I think this is important  good because for users of the
 platform workflow, they expect to make changes directly to platform
 config.xml, but for users of the CLI, we keep harping at them to never
 edit
 those files, yet thats the only way at the moment to remove these
 optional
 defaults we inject for them.
 
 WDYT?  I'm working on a prototype and will report back if the theory
 works
 in practice.
 
 -Michal
 
 
 
 On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve agri...@chromium.org
 wrote:
 
 Michal - I'm not s
 
 
 On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams 
 to...@devgeeks.org
 wrote:
 
 Absolutely agree.
 
 +1 for * as default, but just as importantly, +1 for never having to
 hax
 inside ./platforms/**/* for this stuff.
 
 We are already forced to use hooks to enforce ./platforms as a build
 artefact. Any progress towards the great goal of being able to safely
 .gitignore the platforms make me feel warm and fuzzy. ;)
 
 
 
 On 4 Dec 2013, at 7:09 am, Michal Mocny mmo...@chromium.org wrote:
 
 Tommy, absolutely the default should remain *, as I said.
 
 But I hope we can agree that it should also be possible to override
 the
 default without requiring hacks.  iOS already supports this, so
 its a
 matter of feature parity.
 
 -Michal
 
 
 On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams to...@devgeeks.org
 
 wrote:
 
 Please don't go back to when every new dev had to struggle with
 the
 Google
 group or irc to find out why their ajax requests didn't work.
 
 There was a hge discussion at the time that we chose to
 default
 to *
 On 04/12/2013 6:03 am, Michal Mocny mmo...@chromium.org
 wrote:
 
 On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson 
 bra...@chromium.org

Re: proposal to simplify hello world

2013-12-04 Thread Tommy-Carlos Williams

I have been thinking about this, and happy to start a new thread if needed, but 
is there a valid reason to have DisallowOverscroll default to false?

I think we can all agree on getting rid of the nonexistent ‘webviewbounce’ that 
is misleadingly in the default config.xml now… but what about what the default 
should be on the real preference? Is there actually a use case for apps looking 
more like web pages and less like apps? I admit to being fairly 
platform-ignorant outside of the “big two”, so it might be that one of the 
other platforms needs this (though, I hope not, as that would raise a whole 
other issue around different platforms needing different values for a given 
preference since iOS nearly always needs this turned on).

- tommy



On 30 Nov 2013, at 3:33 am, Andrew Grieve agri...@chromium.org wrote:

 (plus webviewbounce doesn't exist)

Re: FYI: yo dude, a generator of generators for cordova Apps

2013-12-02 Thread Tommy-Carlos Williams

totally should be `yo dawg`[1]

[1]: https://dl.dropboxusercontent.com/u/1456226/photos/yo-dawg-generator.png

On 3 Dec 2013, at 7:07 am, Carlos Santana csantan...@gmail.com wrote:

 Just in case you know someone that might benefit
 
 yo dude [1] first it prompts to select a Web App Generator (dapp,
 mobile(topcoat, foundation,bootstrap), angular, polymer, backbone, webapp,
 etc..).
 
 Then runs the the generator-cordovacli prompts for name, id, platforms, and
 plugins for cordova.
 
 End result you get a cordova app built with your favorite web framework.
 
 It might be more useful for demos and learning purposes for Apache Cordova.
 
 [1]: https://npmjs.org/package/generator-dude
 
 -- 
 Carlos Santana
 csantan...@gmail.com

Re: iOS Camera asking for Location

2013-11-29 Thread Tommy-Carlos Williams

IIRC, Camera used to NOT keep the location and other data, then that was raised
as an issue and it was added in… and now it’s being ripped out again?

I agree with it being optional, but ripping it out again, not so much.

+1 for
https://issues.apache.org/jira/browse/CB-4003?focusedCommentId=13694956page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13694956

On 30 Nov 2013, at 6:43 am, Michal Mocny mmo...@chromium.org wrote:

Ah, thats a good point (us canadians do forget!), we will make sure to
factor that into silent consensus! (Land all the patches now, boys!)

On Fri, Nov 29, 2013 at 2:13 PM, Shazron shaz...@gmail.com wrote:

I believe Lorin is working on it being a preference, with it turned off by
default. https://issues.apache.org/jira/browse/CB-4003

Also FYI Adobe US ppl are away for the turkey long weekend, so responses
might be late

On Fri, Nov 29, 2013 at 11:04 AM, Michal Mocny mmo...@chromium.org
wrote:

I agree, rip it out. I'd love to see a plugin for editing EXIF data
using
this code as a starting point perhaps, but I can't see how what we have
now
is a good default.

-Michal

On Fri, Nov 29, 2013 at 1:25 PM, Andrew Grieve agri...@chromium.org
wrote:

On iOS, the Camera API has an undocumented feature where it injects
your
location into a photo's exif data.

Although neat, I think this isn't desired in most cases and it causes a
location permission dialog to appear.

I'd like to delete this location logic. Any objections?

1 2 >

1 - 100 of 163 matches

Mail list logo