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

[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

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

[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

[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 there is no information you wouldn’t be comfortable
 with the entire world knowing.

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

[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

[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&data=01%7c01%7cbradga%40micros
>>> oft.com%7c46d14102d64c4e5de06408d2c51d409d%7c72f988bf86f141af91ab2d7cd
>>> 011db47%7c1&sdata=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&data=01%7c01%7cbradga%40microsoft.com%7c46d14102d64c4e5de06408
>>> d2c51d409d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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&data=01%7c01%7cbradg
>>> a%40microsoft.com%7c46d14102d64c4e5de06408d2c51d409d%7c72f988b
>>> f86f141af91ab2d7cd011db47%7c1&sdata=WfhsLEijWdilHq7RBNF6%2fGuf
>>> qZSOVs661NnN2MM7uvU%3d
>>> 
>>> -- The redesign 

Re: [DISCUSS] Tools Release

[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&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7cc74c34192a664443cce908d2bf1cc69b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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&data=01%7c01%7cv-vlkoti%400
 64d.mgd.microsoft.com%7cc74c34192a664443cce908d2bf1cc69b%7c72f988bf8
 6f141af91ab2d7cd011db47%7c1&sdata=MtwvQkbecpe9ES%2fY5JyJbOnNsQUQaNfe
 LWy9BBMgejk%3d
 [2]
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>>> b.com%2fapache%2fcordova-lib%2fcommit%2f5f008df5e4b8bff934b05d049fda07
>>> 74b7bc4583&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7cc74c3419
>>> 2a664443cce908d2bf1cc69b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=
>>> 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

[Tommy-Carlos Williams]

+1 from me. 



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

[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  
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  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  
> > 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  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 : 
>  
> > 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 : 
> >> 
> >>> +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  >> > 
>  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 
>  iOSe

Re: Issue in config.xml passing

[Tommy-Carlos Williams]

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



> On 25 Aug 2015, at 02:29, Rob Paveza  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 
> 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 
> 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
> 
> ==
> 
> 
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.w3.org%2fns%2fwidgets&data=01%7c01%7cROPAVE%40exchange.microsoft.com%7c7f156d63cba3426177c108d2aca0981b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WsrxkgXR4ahRr9DXajnxu%2fAoyOGMxKt7yUJleELz1EU%3d";
>  
> xmlns:cdv="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordova.apache.org%2fns%2f1.0&data=01%7c01%7cROPAVE%40exchange.microsoft.com%7c7f156d63cba3426177c108d2aca0981b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NxlYMsj7Xx2aKOossViPx%2bXAhN7Ngi6zRmRkjvX1z9M%3d";>
> 
>Ezone
> 
>
> 
>A sample Apache Cordova application that responds to the
> deviceready event.
> 
>
> 
> href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordova.io&data=01%7c01%7cROPAVE%40exchange.microsoft.com%7c7f156d63cba3426177c108d2aca0981b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DV822%2fNVS0qN%2fDYlzYzZnzCT5%2fL6AW0j6wxZyw4V2N4%3d";>
> 
>Apache Cordova Team
> 
>
> 
>
> 
>
> 
>
> 
>http://*/*"; />
> 
>https://*/*"; />
> 
>
> 
>
> 
>mailto:*"; />
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
> 
> 
> 
> 
> Please solve my problems
> --
> *Warm Regards,*
> 
> *A R Abid*
> 
> *---*
> 
> *Founder/CTO*
> 
> 
> *MOB: **+91 9895971627* 
> *SKYPE: abikh.kunnil786*
> 
> 
> 
> 
> --
> *Warm Regards,*
> 
> *A R Abid*
> 
> *---*
> 
> *Founder/CTO*
> 
> 
> *MOB: **+91 9895971627* 
> *SKYPE: abikh.kunnil786*
> 
> -
> 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: Issue in config.xml passing

[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  wrote:
> 
> 

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

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

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

[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

[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  escribió:  

> Done.  
>  
>  
>  
> > On Aug 17, 2015, at 10:29 AM, Steven Gill  > 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  > 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  >  
> >> 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  >  
> >> 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  >  
> >>> wrote:  
> >  
> > I am guessing that this would be a one day meeting.  
> >  
> > -Original Message-  
> > From: Carlos Santana [mailto:csantan...@gmail.com ]  
> > Sent: Friday, August 7, 2015 2:25 PM  
> > To: dev@cordova.apache.org   
> > 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  >  
> > wrote:  
> >  
> >> I'm in! :)  
> >>  
> >> On Fri, 07 Aug 2015 08:37:50 +0900, Steven Gill  
> >> >  
> >> wrote:  
> >>  
> >>> Doodle:  
> >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdood  
> >>> le.com%2f58peh49rqm2tbyhm&data=01%7c01%7cpanarasi%40microsoft.com  
> >> %7c  
> >>>  
> 3fa83cc33aeb446a585708d29f6ebe75%7c72f988bf86f141af91ab2d7cd011db47%  
> >>> 7c1&sdata=Vq5pSYf1esq4Nw1%2fYJmbPEYP4kvZrbPHJhBfgWy18j0%3d  
> >>>  
> >>> On Thu, Aug 6, 2015 at 4:17 PM, Parashuram N  
> >>> >  
> >>> 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 ]  
>  Sent: Thursday, August 6, 2015 4:08 PM  
>  To: dev@cordova.apache.org   
>  Subject: RE: Cordova Face to Face meeting  
>   
>  I'll be there! Looking forward to it.  
>   
>  -Original Message-  
>  From: Jesse [mailto:purplecabb...@gmail.com ]  
>  Sent: Friday, August 7, 2015 8:25 AM  
>  To: dev@cordova.apache.org   
>  Subject: Re: Cordova Face to Face meeting  
>   
>  Yes!  
>   
>   
>   
>  My team is hiring!  
>  @purplecabbage  
> >> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data  
>  =01%7c01%7cpanarasi%40microsoft.com  
> >> %7c3fa83cc33aeb446a585708d29f6eb  
>   
> e75%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PHqR%2bUh%2bsPBfg0  
>  lU8kpQVavrBk9E4flFB%2fiUIipcSqM%3d  
>   
>  On Thu, Aug 6, 2015 at 2:59 PM, Steven Gill  
>  >  
>  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  
> > >  
> > 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  
> >> >  
> >> 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  
> 

RE: Cordova July Hangout

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

> We'll have it back momentarily, we just noticed as well.  
>   
> From: Andrey Kurdumov   
> 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 :  
>  
> > 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 :  
> >  
> > > 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   
> 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  
> > >

Re: Cordova July Hangout

[Tommy-Carlos Williams]

Alarm set for 4:30am. 

Better go to bed now ;)



> On 16 Jul 2015, at 21:20, Carlos Santana  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" 
>> 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

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

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

[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  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  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  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   
>> > 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  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  wrote:  
>> > > >  
>> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584  
>> > > > >  
>> > > > >  
>> > > > > On Monday, June 8, 2015, Shazron  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   
>> 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  
>> > > > >>>  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!

[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"  wrote:  

> Yeah retrying couple times worked for me earlier :)  
>  
> Sent from my iPhone  
>  
> > On Jun 12, 2015, at 12:15 PM, Shazron  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  >  
> > 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  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

[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  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  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   
> > 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  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  wrote:  
> > > >  
> > > > > Moar news https://twitter.com/wkwebview/status/608005652720451584  
> > > > >  
> > > > >  
> > > > > On Monday, June 8, 2015, Shazron  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   
> 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  
> > > > >>>  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: "Best" place to browse plugins

[Tommy-Carlos Williams]

+1



> On 26 May 2015, at 21:44, Carlos Santana  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 
> 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 :
>>> 
 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)
  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
>> 

---

Re: Also moving to a new team

[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  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  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: Also moving to a new team

[Tommy-Carlos Williams]

Wow. Real "end of an era" stuff here. 

Your tireless work for Cordova will be big shoes indeed. 

Good luck on the Chrome team. It's been a pleasure. 



> On 6 May 2015, at 05:36, Steven Gill  wrote:
> 
> Andrew, it has been a pleasure to work with you these last few years! Good
> luck on your new team!!
> 
>> On Tue, May 5, 2015 at 11:11 AM, Ryan J. Salva  wrote:
>> 
>> Thanks for all you've done for the project, Andrew and Michal. I'm sure
>> we'll cross paths again sometime soon. In the meantime, I can't wait to see
>> what you create with the Physical Web. It looks like a super-cool project.
>> I only expect great things :-)
>> 
>> rjs
>> 
>> Ryan J. Salva  |  Principal Program Manager Lead
>> Visual Studio Tools for Apache Cordova
>> rsa...@microsoft.com
>> 425 706 5270 office
>> 206 612 5079 mobile
>> 
>> 
>> 
>> My team is hiring.
>> 
>> -Original Message-
>> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
>> Grieve
>> Sent: Tuesday, May 5, 2015 9:16 AM
>> To: dev
>> Subject: Also moving to a new team
>> 
>> 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

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

[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  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  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  wrote:  
> >  
> > > Congrats Michal!  
> > > Super interesting project.  
> > >  
> > > On Mon, May 4, 2015 at 7:52 AM, Michal Mocny   
> 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: Jira CB-831: File transfer tests crash on Android L

[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: Does Cordova have a problem making developers happy?

[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: plugins, npm, and package.json …other art

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

[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   
Reply: dev@cordova.apache.org >  
Date: March 30, 2015 at 7:33:28 PM  
To: dev >  
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  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: Cordova Monthly Hangouts

[tommy-carlos williams]

+1 for package.json discussions

-- 
tommy-carlos williams

On 25 March 2015 at 09:18:12, Michal Mocny (mmo...@chromium.org) wrote:

Another topic is discussion of "package.json" based cli workflow, aka  
leveraging more npm-ness in our tools.  

-Michal  

On Tue, Mar 24, 2015 at 1:59 PM, Andrew Grieve  wrote:  

> +1!  
>  
> On Tue, Mar 24, 2015 at 1:23 PM, Jesse  wrote:  
>  
> > +1 asap, thanks Parash!  
> >  
> > We are much more coherent when we meet.  
> >  
> >  
> >  
> > > On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) <  
> > panar...@microsoft.com> wrote:  
> > >  
> > > Hi,  
> > >  
> > > I was wondering if folks would be interested in doing a hangout to  
> > quickly resolve some of the outstanding issues that we have been talking  
> on  
> > the mailing list. I think we could talk about the following  
> > >  
> > >  
> > > * Androind 4.0 release  
> > > * Medic/ParaMedic/Mobile Spec - progress and next steps  
> > > * Finalize Save/Restore discussions  
> > > * ApacheCon ?  
> > >  
> > > I can volunteer to help set this up if we think there are items that we  
> > would like to discuss and close on.  
> >  
> > -  
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org  
> > For additional commands, e-mail: dev-h...@cordova.apache.org  
> >  
> >  
>  

RE: Plugin history purged from registry?

[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

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

[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* s, then only apply global tags to those  
platforms.  
If plugin.xml has *no* s, then apply global tags to all platforms.  

On Tue, Feb 10, 2015 at 2:18 PM, Tommy Williams  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"  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"  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: [iOS 8] WKWebView moving forward

[tommy-carlos williams]

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: Plugin management ?

[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

[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  wrote:  

> !  
>  
> On Wed, Jan 7, 2015, 6:49 PM tommy-carlos williams   
> 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  wrote:  
>>  
>> > Also, who actually tests on Gingerbread? Please comment on this thread.  
>> >  
>> > On Wed Jan 07 2015 at 5:09:49 PM Joe Bowser  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: Deprecation Wars: ICS vs Gingerbread

[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: Reason for node_modules in Platform Repos

[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

[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"  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   
>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"  wrote:  
>>  
>> >I commented on Ian's comment on CB-8032:  
>> >  
>>  
>>https://issues.apache.org/jira/browse/CB-8032?focusedCommentId=14216403&p  
>>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   
>> >wrote:  
>> >  
>> >> On Tue Nov 18 2014 at 2:00:34 PM Jesse   
>>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  
>>catego

Re: Cordova Plugins

[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

[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   
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  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:  
> >  
> > 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  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:  
> > >   
> > >  
> > > 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   
> > 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"  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 Securi

Re: [iOS 8] WKWebView moving forward

[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  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:  
>  
> 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  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:  
> >   
> >  
> > 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   
> 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"  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   
> >> wrote:  
> >> >  
> >> >> I spent a lot of time thinki

Re: adding push notifications to core plugins

[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   
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  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  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  wrote:  
> > > >  
> > > > > I'm all for code removal. Which plugins tho?  
> > > > >  
> > > > >  
> > > > > On Thu, Oct 16, 2014 at 1:23 PM, Joe Bowser   
> 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  >  
> > > > 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   
> > > 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

[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

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

Re: [iOS 8] Status of WKWebView work

[tommy-carlos williams]

Generally speaking, JS performance is not a problem for most iOS Cordova apps. 
Certainly I never had a problem until recently.

Sadly, I now work with a JS privacy (crypto) lib called Crypton[1] that works 
pretty damn good on Android, decently on BB10 and even pretty good on FxOS… but 
takes like 2 MINUTES just to log in on an iPhone 5 :(

And that’s only using 1000 rounds of PBKDF2 for SRP authentication (less than 
we would like).

Luckily, my use case is not the norm… but it does mean I am making apps that 
are unusable on iOS, which makes me sad.

1. https://crypton.io

On 10 September 2014 at 10:20:21, Andrew Grieve (agri...@chromium.org) wrote:

That's great news.  

JS execution speed honestly hasn't really been a problem for Cordova  
apps that I've heard of anyways.  

On Tue, Sep 9, 2014 at 7:01 PM, Shazron  wrote:  
> Some interesting findings - iOS UIWebView and WKWebView have the same  
> user-agent value, and both score 440 on html5test.com.  
>  
> Which makes me think they use the same engine (renderer and js), but  
> UIWebView has nitro turned off. WKWebView seems to be about 4x faster on  
> the Sunspider benchmark.  
>  
> On Tue, Sep 9, 2014 at 3:58 PM, Shazron  wrote:  
>  
>> UIWebView iOS 8 scores 440/555 points on html5test.com, and yes it  
>> supports indexedDB  
>> Full results: http://html5te.st/f16d892273bbe5bd  
>>  
>> On Tue, Sep 9, 2014 at 1:33 PM, Andrew Grieve   
>> wrote:  
>>  
>>> :(  
>>>  
>>> Hopefully UIWebView will still get some updates though? E.g. IndexedDb?  
>>>  
>>> On Tue, Sep 9, 2014 at 4:18 PM, Tommy Williams   
>>> wrote:  
>>> > That's pretty disappointing.  
>>> >  
>>> > Especially with not even a comment from apple.  
>>> > On 10 Sep 2014 05:50, "Shazron"  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  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  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=date&desc=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: [iOS 8] Status of WKWebView work

[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  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  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=date&desc=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 !

[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_detailpage&v=zzNoXbv1DX4#t=1496 

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


-- 
Carlos Santana 
 

Re: Hello Cordova!

[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: [iOS 8] Please duplicate this Apple bug report for WKWebView use in Cordova

[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   
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 :  
> >  
> > > 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: [iOS 8] Please duplicate this Apple bug report for WKWebView use in Cordova

[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  wrote:  

> Done  
>  
>  
> 2014-08-16 4:08 GMT+02:00 Shazron :  
>  
> > 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: Reminder: Cordova Hangout Today @4pm EST, 1pm PST

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

[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  wrote: 

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

Re: Monthly Cordova hangouts

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

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

[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  wrote:  

> Event link: https://plus.google.com/events/c2cqjqfkkppsealikav2tm37dik  
> Alternative YouTube link: http://www.youtube.com/watch?v=Wpx91MxV-DA  
>  
> I've also enabled Q&A 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   
> 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  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   
> > > 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   
> > 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  >  
> > > >> wrote:  
> > > >>  
> > > >> > Which time slot is this one?  
> > > >> > On 15 Jul 2014 05:49, "Joe Bowser"  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   
> > 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: One platform development vs. Cordova CLI

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

> 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" :  
>  
> > 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 :  
> > >  
> > > > 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  
&

Re: One platform development vs. Cordova CLI

[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

[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" :  

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

[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 :  
>  
> > 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ý :  
> >  
> > > 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   
>  

Re: Verified Plugins Marketplace

[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  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 
> @rdlauer 
> 
> 

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

[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: 
>  
> 
> #2 deployment-target 
> This sets the IPHONEOS_DEPLOYMENT_TARGET in the build, which tranlsates to 
> the MinimumOSVersion in the ipa Propertly List. 
> Example: 
>  
> 
> [2] 
> http://docs.build.phonegap.com/en_US/configuring_preferences.md.html#_ios_only
>  
> 
> Thx! 
> Sergey 
> 

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

[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? 
> 
>  
>  
>  
> 
> [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: WKWebView for iOS8

[tommy-carlos williams]

This looks promising.

Thanks for the update, Shazron.

- tommy

On Sun, Jun 15, 2014 at 7:48 AM, Shazron  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  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 
 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  wrote:

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

 WKUserScript.

 On Saturday, June 7, 2014, Carlos Santana  
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  
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 


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


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





 --
 Carlos Santana
 

Re: Cordova hooks always verbose.

[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  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  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  wrote:  
>> > https://issues.apache.org/jira/browse/CB-6942  
>> >  
>> >  
>> > On Fri, Jun 13, 2014 at 3:51 PM, Michal Mocny   
>> 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

[tommy-carlos williams]

Yeah, that’s whatI am seeing as well

On 11 June 2014 at 6:06:19, Joe Bowser (bows...@gmail.com) wrote:

Isn't that just for watching?  


On Tue, Jun 10, 2014 at 1:04 PM, Ian Clelland  wrote:  
> Try this one:  
>  
> https://plus.google.com/u/0/events/cbu7q79m7a0abspj2dljtkloass?authkey=CMKg9sO3_fbaPg
>   
>  
>  
>  
> On Tue, Jun 10, 2014 at 4:02 PM, Ian Clelland   
> wrote:  
>  
>> Link incoming  
>>  
>>  
>> On Tue, Jun 10, 2014 at 3:59 PM, Steven Gill   
>> wrote:  
>>  
>>> Link?  
>>>  
>>>  
>>> On Tue, Jun 10, 2014 at 3:20 AM, tommy-carlos williams <  
>>> to...@devgeeks.org>  
>>> wrote:  
>>>  
>>> > 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   
>>> 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: Hangout

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

[tommy-carlos williams]

Yeah, I was afraid of that...

:(

On Fri, Jun 6, 2014 at 11:09 AM, Michal Mocny  
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  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  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 


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


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

[tommy-carlos williams]

nfuse, this is the point I was trying to get that there is "user  
>>>>> space" and "cordova platform space", Doing a plugin for yeoman, gulp ,  
>>>>> grunt, or the next thing is user space.  
>>>>>  
>>>>> cordova as a platform should be using flexbile and clear on what is  
>>>>>  
>>>> doing,  
>>>>  
>>>>> so "user space" can customize on top of it.  
>>>>>  
>>>>>  
>>>>> On Wed, Jun 4, 2014 at 12:44 PM, Terence M. Bandoian <  
>>>>>  
>>>> tere...@tmbsw.com>  
>>>  
>>>> wrote:  
>>>>>  
>>>>> This is helpful. Thank you for posting this, Carlos. I have a  
>>>>>>  
>>>>> couple  
>>>  
>>>> of  
>>>>  
>>>>> related questions.  
>>>>>>  
>>>>>> The config files I've used iOS and Android are significantly  
>>>>>>  
>>>>> different  
>>>  
>>>> for  
>>>>>  
>>>>>> the same project. Is combining everything for all platforms into one  
>>>>>> config.xml recommended?  
>>>>>>  
>>>>>> What cordova commands cause the www folder to be copied to a  
>>>>>>  
>>>>> platforms  
>>>  
>>>> directory? My workflow for iOS/Xcode is typically (similar for  
>>>>>> Android/Eclipse):  
>>>>>>  
>>>>>> - add/build iOS platform using cordova  
>>>>>> - edit, build, test iteratively in Xcode using platforms/ios  
>>>>>>  
>>>>> directory  
>>>  
>>>> Xcode doesn't copy from the outer www directory when it builds.  
>>>>>>  
>>>>> Should  
>>>  
>>>> it?  
>>>>>  
>>>>>> All 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"  
>>>>>>>  
>>

Re: adding platforms to npm for dependency sanity

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

Re: iOS 8 Release Notes - PhoneGap/Cordova mention

[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

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

Re: adding platforms to npm for dependency sanity

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

Re: Attending WWDC 2014?

[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  wrote:  
> Wow, that's new! Has the whole world gone sane?  
>  
> @purplecabbage  
> risingj.com  
>  
>  
> On Tue, Jun 3, 2014 at 2:17 PM, Shazron  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  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   
>> 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   
>> wrote:  
>> >>  
>> >>> WOW! Really?? That sounds promising!  
>> >>>  
>> >>>  
>> >>> On Tue, Jun 3, 2014 at 3:23 PM, Michal Mocny   
>> wrote:  
>> >>>  
>> >>> > WKWebView?!  
>> >>> >  
>> >>> >  
>> >>> > On Tue, Jun 3, 2014 at 3:14 PM, Shazron  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?  
>> >>> 

Re: adding platforms to npm for dependency sanity

[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   
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  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   
>>> 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  wrote:  
  
 NIH: not invented here  
>  
>  
>  
> On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve   
> wrote:  
>  
> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux  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: hen

Re: Attending WWDC 2014?

[tommy-carlos williams]

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

> I'm also in SF Monday-Wednesday.  
>  
> On Mon, Jun 2, 2014 at 10:47 AM, Michael Brooks  
>  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   
> 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   
> >> Reply-To: "dev@cordova.apache.org"   
> >> Date: Monday, June 2, 2014 at 9:09 AM  
> >> To: "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"   
> 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  
> >> >>   
> >> >>  
> >>  
> >>  
>  

Re: Hangout Today?

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

[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

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

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

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

Re: issues.cordova.io down

[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 
wrote: 

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

issues.cordova.io down

[tommy-carlos williams]

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

:/

Re: Android File and Camera plugins

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

[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  wrote: 

> On Thu, Mar 13, 2014 at 11:38 AM, Andrew Grieve  >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

[Tommy-Carlos Williams]

+1


On 12 Mar 2014, at 9:32 am, Carlos Santana  wrote:

> Blue for mobile-spec
> 
> On Tuesday, March 11, 2014, Brian LeRoux  wrote:
> 
>> omg yes
>> 
>> 
>> On Tue, Mar 11, 2014 at 1:59 PM, Michal Mocny 
>> >
>> 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 
>>> 
 wrote:
>>> 
 They look really good! Thanks for creating them!
 
 
 On Mon, Mar 10, 2014 at 3:35 PM, Brian LeRoux >
>> 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 
>> 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
> 

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

[Tommy-Carlos Williams]

+1


On 11 Mar 2014, at 5:52 am, Brian LeRoux  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?

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

[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: StatusBar plugin for Android

[Tommy-Carlos Williams]

Calling that not core seems a stretch (since it’s in an apache cordova repo and 
all), but the maintainer is Shazron, as far as I know… if that helps.




On 25 Feb 2014, at 5:29 pm, Andrey Kurdumov  wrote:

> I want to extend StatusBar plugin to support Android. And yesterday I file
> issue
> https://issues.apache.org/jira/browse/CB-6095. It was soon closed with
> suggestion contact plugin maintainer, because StatusBar is not core plugin.
> Maybe I file issue incorrectly, and specify wrong component/ something
> else, not sure about this.
> But I clearly see the StatusBar plugin in
> https://github.com/apache/cordova-plugins repository which is clone of
> git://git.apache.org/cordova-plugins.git
> Both seems to be belonging to Cordova project.
> 
> I do have fix for this issue, and willing to contribute that back.
> What route should I take?

Re: Introduction

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

[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  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  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  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 
>>> 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
 X.
 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
  dealing
 with 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 
 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  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

Re: Adding SSL Certificate Pinning to Cordova

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

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

[Tommy-Carlos Williams]

Brian,

Let’s see if I can wake up :)


On 17 Jan 2014, at 11:03 am, Brian LeRoux  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
> wrote:
> 
>> 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  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  wrote:
>>> 
>>>> So, when is this happening?
>>>> 
>>>> On Tue, Jan 14, 2014 at 6:33 PM, Andrew Grieve 
>>>> 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)
>>>>>  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
>>>>>> wrote:
>>>>>> 
>>>>>>> ugh... 4:30-6:30 am ;)
>>>>>>> 
>>>>>>> 
>>>>>>> On 14/01/2014, at 6:17 AM, Brian LeRoux  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

[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  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  wrote:
> 
>> So, when is this happening?
>> 
>> On Tue, Jan 14, 2014 at 6:33 PM, Andrew Grieve 
>> 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)
>>>  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
>>>> wrote:
>>>> 
>>>>> ugh... 4:30-6:30 am ;)
>>>>> 
>>>>> 
>>>>> On 14/01/2014, at 6:17 AM, Brian LeRoux  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

[Tommy-Carlos Williams]

ugh… 4:30-6:30 am ;)


On 14/01/2014, at 6:17 AM, Brian LeRoux  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

[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  wrote:

> On Tue, Jan 14, 2014 at 2:52 PM, Brian LeRoux  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 >> wrote:
>> 
>>> On Tue, Jan 14, 2014 at 1:44 PM, Brian LeRoux  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  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.
 )
 
 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 po

Re: Adding SSL Certificate Pinning to Cordova

[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  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  wrote:
>> On Mon, Jan 13, 2014 at 2:00 PM, Tommy-Carlos Williams
>>  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  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

[Tommy-Carlos Williams]

For Android, I see what you are saying.

At best it’s a slightly better situation than the plugin I initially mentioned. 
You could check the cert in the shouldInterceptRequest and return null if it 
was OK, or something else if it was not (like the current whitelist checks), 
but the *actual request* would still be separate from the one that was actually 
tested.

Just to further cloud the waters… if we *did* implement it this way, it would 
double the latency on every request to a pinned host.

:(

Hrm… I might have to solve this outside of core unless we can come up with an 
idea how to do it.



/me feels a plugin that polyfills xhr coming… ugh...


On 14 Jan 2014, at 1:28 pm, Andrew Grieve  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  wrote:
>> On Mon, Jan 13, 2014 at 2:00 PM, Tommy-Carlos Williams
>>  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  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?
>>>> 
>>>