Re: APK generated from FireFoxOS App?

[julio cesar sanchez]

Not sure if it's the same thing, but some time ago firefox beta for
android included the option to install firefox os apps on android
phones.
I tried it and the apps were installed as new apps from a server
generated .apk, but it was using the firefox app for opening the
firefox os apps or using something from there, because if you delete
the firefox app the firefox os apps stop working.



2014-06-21 4:16 GMT+02:00 Carlos Santana :
> I'm curious about this:
> https://developer.mozilla.org/en-US/Marketplace/Options/Open_web_apps_for_android
>
> Anyone knows more about how this works and compares to cordova android?
>
> Is generating a cordova android APK?
> Is using android web view or gecko web view?
> Is using some some sort of shim layer call "web runtime" for FirefoxOS API
> birding to Android?
>
> Anything here to leverage(i.e. Concepts, API separation, packaging on the
> the cloud, etc) for Cordova, maybe in the area of android plug-able web
> views?
>
> -- Carlos
>
>
>
>
> --
> Carlos Santana
> 

Re: More questions on FileSystem directories

[julio cesar sanchez]

"If you read this immediately after reading the docs for
cordova.file.dataDirectory, you may think that files there do NOT
survive app restarts."


Which ones, the files from dataDirectory or the files from cacheDirectory?

If you mean dataDirectory, maybe the doc should be something like this:

cordova.file.dataDirectory - Persistent data directory where to put
app-specific data files. (iOS, Android)

cordova.file.cacheDirectory - Directory for cached data files or any
files that your app can re-create easily. The OS may delete these
files when the device runs low on storage, nevertheless, apps should
not rely on the OS to delete files in here. (iOS, Android)

It's a mix from the apple
https://developer.apple.com/library/ios/Documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW11
and android doc
http://developer.android.com/guide/topics/data/data-storage.html

2014-06-29 19:08 GMT+02:00 Ray Camden :
> According to the docs, cordova.file.cacheDirectory is: "Cached files that 
> should survive app restarts. Apps should not rely on the OS to delete files 
> in here. "
>
> If you read this immediately after reading the docs for 
> cordova.file.dataDirectory, you may think that files there do NOT survive app 
> restarts.
>
> Can we flesh out this a bit more perhaps?

Re: More questions on FileSystem directories

[julio cesar sanchez]

Maybe we can wait to hear more opinios about my modification. Or you
can create the pull request and they will merge if they agree.

2014-06-30 16:44 GMT+02:00 Ray Camden :
> Yes, I meant that the doc for cacheDirectory implies, at least to me, that 
> the previous entry (dataDirectorry) will not persist. I think your 
> modification makes sense. Do you want to make a PR for the doc or should I?
>
> ____
> From: julio cesar sanchez 
> Sent: Monday, June 30, 2014 2:19 AM
> To: dev@cordova.apache.org
> Subject: Re: More questions on FileSystem directories
>
> "If you read this immediately after reading the docs for
> cordova.file.dataDirectory, you may think that files there do NOT
> survive app restarts."
>
>
> Which ones, the files from dataDirectory or the files from cacheDirectory?
>
> If you mean dataDirectory, maybe the doc should be something like this:
>
> cordova.file.dataDirectory - Persistent data directory where to put
> app-specific data files. (iOS, Android)
>
> cordova.file.cacheDirectory - Directory for cached data files or any
> files that your app can re-create easily. The OS may delete these
> files when the device runs low on storage, nevertheless, apps should
> not rely on the OS to delete files in here. (iOS, Android)
>
> It's a mix from the apple
> https://developer.apple.com/library/ios/Documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW11
> and android doc
> http://developer.android.com/guide/topics/data/data-storage.html
>
> 2014-06-29 19:08 GMT+02:00 Ray Camden :
>> According to the docs, cordova.file.cacheDirectory is: "Cached files that 
>> should survive app restarts. Apps should not rely on the OS to delete files 
>> in here. "
>>
>> If you read this immediately after reading the docs for 
>> cordova.file.dataDirectory, you may think that files there do NOT survive 
>> app restarts.
>>
>> Can we flesh out this a bit more perhaps?

Re: HTML5DevConf Intro talk slides & interview

[julio cesar sanchez]

If you want a list of framework that work with phonegap, on the "next
steps" guide they list a few

http://cordova.apache.org/docs/en/3.5.0/guide_next_index.md.html#Next%20Steps

Re: Famo.us & cordova?

[julio cesar sanchez]

With this "We are collaborating with another company on this project" I
think they are referring to Ludei's CocoonJS

El martes, 8 de julio de 2014, Fischer, Paul A 
escribió:

> I think they are referring to the Crosswalk pluggable webview. They
> currently use Crosswalk as their delivery mechanism for Android and it
> includes an approximately 15 MB payload for the replacement webview.
>
> -Original Message-
> From: mmo...@google.com  [mailto:mmo...@google.com
> ] On Behalf Of Michal Mocny
>
> I'm not concerned about that part Joe.  I'm a little concerned about the
> way they worded the second part.  It sounds like its something custom they
> are building, that isn't related to cordova at all.  I'm assuming it is,
> but talk about questionable writeup (gasp, surprise for Famo.us).
>
>
> On Tue, Jul 8, 2014 at 12:02 AM, Joe Bowser  > wrote:
>
> > WTF is Adobe Cordova? I know that someone was talking to the Famo.us
> > guys, but they really screwed up this mailout. :S
> >
> > On Mon, Jul 7, 2014 at 8:59 PM, Michal Mocny  > wrote:
> > > From todays Famo.us email marketting:
> > >
> > >
> > > *Adobe collaboration*
> > > We are proud to announce that we have officially begun a
> > > collaboration project with the Adobe Cordova team to make core
> > > improvements to Cordova itself. Included as part of this project
> > > will be a section of Famo.us University to teach people how to wrap
> Famo.us apps.
> > >
> > > *The Famo.us Wrapper*
> > > The wrapper will enable developers to create a pluggable webview
> > > wrapped inside their Android apps. The good news is that you can
> > > provide a Chrome
> > > 35 webview with this method. The bad news is that it comes with a
> > > 10-20MB payload. We are collaborating with another company on this
> > > project—sorry, but we can't say their name yet. This solution is in
> > > the labs and is not ready for production. We will let you know when
> > > it is available. If you'd like to participate in our beta, please
> contact fetter...@famo.us .
> >
>

Re: Famo.us & cordova?

[julio cesar sanchez]

I don't see CocoonJS as a "phonegap killer", maybe a "phonegap build
killer", they've just added cordova/phonegap API support.
They've created an improved webview for iOS and android, but phonegap isn't
about the webview, is about the API over it.
Sad part is they aren't open source, but they did a great job with their
webview.

Anyway, after iOS 8 and android L with their new webviews, maybe this kind
of projects (cocoonjs, crosswalk) won't make much sense in the future

Re: [iOS] CDVPluginResult breaking change

[julio cesar sanchez]

I think I don't return just the ok without message on any of my plugins,
I'll check, but you can fix it

Re: One platform development vs. Cordova CLI

[julio cesar sanchez]

+ ios background modes

2014-07-15 12:36 GMT+02:00 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

[julio cesar sanchez]

I think I've read somewhere you can change some things in the info.plist on
phonegap build, why can't we?

El martes, 15 de julio de 2014, tommy-carlos williams 
escribió:

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

Re: Manual iOS steps for a Cordova plugin... really?

[julio cesar sanchez]

I think there are other ways of doing this, take a look into other push
plugins, like the oficial pushplugin or the pushwoosh plugin.

I think i've even answered something like this on stackoverflow, I'll look
into this and let you know

El martes, 15 de julio de 2014, Michal Mocny  escribió:

> You can solve this problem as a plugin author using swizzling.
>
> Here's an example where we do it with our chrome.identity plugin:
>
> https://github.com/MobileChromeApps/mobile-chrome-apps/blob/master/chrome-cordova/plugins/chrome.identity/src/ios/ChromeIdentity.m#L50
>
> Max here was the author so he'd know most about this approach.
>
> One quick comment, we're not sure (aka seems unlikely) that its possible to
> add properties like this, so you'll have to change to plugin to store its
> data elsewhere.
>
>
> On Tue, Jul 15, 2014 at 10:50 AM, Lisa Seacat DeLuca  >
> wrote:
>
> > So I'm not an iOS developer but wanted to get some insight into this.
>  IBM
> > has a set of cordova plugins for our Bluemix (Cloud Foundry) offering.
> >
> > The plugins are available in the plugins repo:
> > http://plugins.cordova.io/#/package/com.ibm.mobile.cordova.ibmpush
> >
> > I was seeing a bunch of errors on the ios side, and when I reached out to
> > the team working on bluemix ios cordova plugin they said it's not a bug,
> I
> > need to follow a bunch of *manual steps* to get the ios plugin to work:
> >
> >
> >
> https://mbaas-gettingstarted.stage1.ng.bluemix.net/hybrid#set-up-push-in-cordova-for-ios
> >
> > Is this really a requirement?  Is there really no way to avoid having to
> > have manual steps to add pieces of code into the AppDelegate.h and
> > AppDelegate.m files?  I find this hard to believe.
> >
> > "To use the IBMPush Cordova plug-in for iOS, configure the AppDelegate of
> > the Cordova application.
> > 1.Add the following property to the AppDelegate.h file:
> > *@property* (*nonatomic*, *strong*) NSData* token;
> > 2.Add the following code snippets to the AppDelegate.m file.
> > Import the IBM Push cordova header file.
> > *// Import the header file.*
> > *#import **"CDVIBMPush.h"*
> > Add the following code to the didFinishLaunchingWithOptions method to
> > register your application to receive Push notifications.
> > -(BOOL)application:(UIApplication*)application
> > didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
> > {
> > *// Register to receive remote notification*
> > [application registerForRemoteNotificationTypes:
> > UIRemoteNotificationTypeBadge |
> > UIRemoteNotificationTypeAlert |
> > UIRemoteNotificationTypeSound];
> > }
> > ..."
> >
> >
> > Lisa
> >
> >
> > Lisa Seacat DeLuca
> > Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org *
> > > | | *ldel...@us.ibm.com
> * > |
> > *lisaseacat.com*  | [image: follow
> > @LisaSeacat on twitter] | [image:
> > follow Lisa Seacat DeLuca on linkedin]
> > 
>

Re: Manual iOS steps for a Cordova plugin... really?

[julio cesar sanchez]

I've just tested and you can just create an AppDelegate category for
the new methods and this should work, but don't use it for existing
methods on the AppDelegate because you will overwrithe the original
methods and only the category methods will be called. I don't know if
this is better/safer than swizzling

If you want to execute your own code when some existing method on the
AppDelegate is called, you can use Notifications
https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplication_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40006728-CH3-DontLinkElementID_4



2014-07-15 21:40 GMT+02:00 Shazron :
> There is an enhancement request for this sort of situation:
> https://issues.apache.org/jira/browse/CB-5601
> IMO, modifying files through the CLI will be problematic -- what
> happens if N plugins want to modify the AppDelegate for example?
>
> On Tue, Jul 15, 2014 at 12:27 PM, Sergey Grebnov (Akvelon)
>  wrote:
>> I think this is a good example of why plugin hooks support could be very 
>> useful.
>> https://github.com/MSOpenTech/cordova-lib/blob/795d40c9c98d1ecef0a63fc81a95d2b070f5bce2/cordova-lib/templates/hooks-README.md
>> https://github.com/apache/cordova-lib/pull/55
>>
>> PS. Not sure how pushwoosh manages this, I ended up with just documenting 
>> this as a manual step in similar situation.
>>
>> Thx!
>> Sergey
>> -Original Message-
>> From: julio cesar sanchez [mailto:jcesarmob...@gmail.com]
>> Sent: Tuesday, July 15, 2014 8:35 PM
>> To: dev@cordova.apache.org
>> Subject: Re: Manual iOS steps for a Cordova plugin... really?
>>
>> I think there are other ways of doing this, take a look into other push 
>> plugins, like the oficial pushplugin or the pushwoosh plugin.
>>
>> I think i've even answered something like this on stackoverflow, I'll look 
>> into this and let you know
>>
>> El martes, 15 de julio de 2014, Michal Mocny  escribió:
>>
>>> You can solve this problem as a plugin author using swizzling.
>>>
>>> Here's an example where we do it with our chrome.identity plugin:
>>>
>>> https://github.com/MobileChromeApps/mobile-chrome-apps/blob/master/chr
>>> ome-cordova/plugins/chrome.identity/src/ios/ChromeIdentity.m#L50
>>>
>>> Max here was the author so he'd know most about this approach.
>>>
>>> One quick comment, we're not sure (aka seems unlikely) that its
>>> possible to add properties like this, so you'll have to change to
>>> plugin to store its data elsewhere.
>>>
>>>
>>> On Tue, Jul 15, 2014 at 10:50 AM, Lisa Seacat DeLuca
>>> >
>>> wrote:
>>>
>>> > So I'm not an iOS developer but wanted to get some insight into this.
>>>  IBM
>>> > has a set of cordova plugins for our Bluemix (Cloud Foundry) offering.
>>> >
>>> > The plugins are available in the plugins repo:
>>> > http://plugins.cordova.io/#/package/com.ibm.mobile.cordova.ibmpush
>>> >
>>> > I was seeing a bunch of errors on the ios side, and when I reached
>>> > out to the team working on bluemix ios cordova plugin they said it's
>>> > not a bug,
>>> I
>>> > need to follow a bunch of *manual steps* to get the ios plugin to work:
>>> >
>>> >
>>> >
>>> https://mbaas-gettingstarted.stage1.ng.bluemix.net/hybrid#set-up-push-
>>> in-cordova-for-ios
>>> >
>>> > Is this really a requirement?  Is there really no way to avoid
>>> > having to have manual steps to add pieces of code into the
>>> > AppDelegate.h and AppDelegate.m files?  I find this hard to believe.
>>> >
>>> > "To use the IBMPush Cordova plug-in for iOS, configure the
>>> > AppDelegate of the Cordova application.
>>> > 1.Add the following property to the AppDelegate.h file:
>>> > *@property* (*nonatomic*, *strong*) NSData* token;
>>> > 2.Add the following code snippets to the AppDelegate.m file.
>>> > Import the IBM Push cordova header file.
>>> > *// Import the header file.*
>>> > *#import **"CDVIBMPush.h"*
>>> > Add the following code to the didFinishLaunchingWithOptions method
>>> > to register your application to receive Push notifications.
>>> > -(BOOL)application:(UIApplication*)application
>>> > didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
>>> > {
>>> > *// Register to receive remote notification* [application
>>> > registerForRemoteNotificationTypes:
>>> > UIRemoteNotificationTypeBadge |
>>> > UIRemoteNotificationTypeAlert |
>>> > UIRemoteNotificationTypeSound];
>>> > }
>>> > ..."
>>> >
>>> >
>>> > Lisa
>>> >
>>> >
>>> > Lisa Seacat DeLuca
>>> > Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org
>>> > * > | |
>>> > *ldel...@us.ibm.com
>>> * > |
>>> > *lisaseacat.com* <http://www.lisaseacat.com/> | [image: follow
>>> > @LisaSeacat on twitter] <http://www.twitter.com/LisaSeacat>| [image:
>>> > follow Lisa Seacat DeLuca on linkedin]
>>> > <http://www.linkedin.com/in/lisaseacat>
>>>

Re: How to provide more files from plugin.xml for project and native?

[julio cesar sanchez]

I have a related question, is it possible to add folders to a plugin as if
I seletected "Create folder references for any added folders" option? (blue
folder)

with   I get the resource as  if I
selected the "Create groups for any added folder" option (yellow folder)


2014-07-30 18:45 GMT+02:00 Carlos Santana :

> Would appreciate help to brainstorm
>
> I want to come out what is best for cordova developers.
> Today we have a downstream that ships cordova, I want to see if we can
> provide better experience
>
> I'm trying to experiment with the crazy idea of providing our value-add
> thru a cordova plugin, meaning developer uses cordova and cordova plugins,
> they can pick and choose when to update, and our value add is something
> they can add and remove very easily leaving their app un-touch.
>
> I understand the scenario about grunt/yeoman/gulp and scaffolding, but
> that's not the main use case.
> When starting from scratch on create is easy to use a template, the main
> use case is when a developer already has a created app.
>
> For example if a developer already has a Chrome Mobile App using cca, and
> then he wants to add a functionality that we provide?
> I want the answer to be: keep using cca tool, and just add our plugin
>
> I think I can achieve something by asking them to unzip an archive that I
> provide that contains files and hooks, but my problem is I want to provide
> an easy way for the developer to remove what was added by the zip archive.
>
> And again I don't think implementing a new type of "plugin",  "module", or
> "package" for the app/project that can be fetch, install, and remove is a
> simple answer, I want to keep it simple and easy to understand for
> developers.
>
>
>
>
>
> On Wed, Jul 30, 2014 at 12:06 PM, Michal Mocny 
> wrote:
>
> > On Wed, Jul 30, 2014 at 11:38 AM, Carlos Santana 
> > wrote:
> >
> > > On Wed, Jul 30, 2014 at 10:54 AM, Michal Mocny 
> > > wrote:
> > >
> > > > First, the easy one: Certainly you should have a way to drop files
> into
> > > > platforms/ios/HelloCordova, and I think  is probably the
> > way
> > > > to go.  The root seems to be the plugin folder by default, so you may
> > > need
> > > > to prefix with "../.." right now.  Also seems hacky, not sure if
> there
> > > is a
> > > > better way.
> > > >
> > >
> > >  doesn't work for my use case, I'm already using for
> > > libraries, frameworks, and files that I want to be available inside the
> > > Mobile App.
> > > I want the file to be inside the XCode project, but NOT inside the
> Mobile
> > > App. It's a file that I need from xcode build script
> > >
> > >
> > > > For the other two: /merges and /hooks, I really don't think we should
> > be
> > > > adding files into there.  I consider those application assets, along
> > with
> > > > www/ and application config.xml, which we also should not be directly
> > > > modifying from plugins.
> > > >
> > > >
> > > I think plugins should be allow to add files to any place in the
> cordova
> > > project/application.
> > > Or we can design a new type of "plugin" a plugin that deals with
> cordova
> > > project tooling.
> > > I like things simple, so if I can manage to create one plugin for my
> > > enterprise product, it will be easy for end user starting with cordova
> to
> > > add and remove one type of plugin, and then the plugin will take care
> of
> > > both what runs on the device and any tooling requirements for those
> > > features
> > >
> > > I'm building a plugin that will add to the existing cordova project
> > > excluding www/ (I don't want to touch this one). For www I think I will
> > > have "www" templates they can use when the do "cordova create" but this
> > are
> > > just samples, if they already have an existing app I want an easy for
> > them
> > > to get necessary files for my plugin to work, and some files are to be
> > > edited by them "merges", and other are hooks that need to run in
> prepare
> > >
> > > I want to add files to /merges/ /platforms and /hooks that are only
> > > applicable to my plugin and not overwriting any user files
> > >
> >
> > This sounds like something thats worth brainstorming the right solution
> > for.  I'm thinking this functionality should lay outside of cordova
> > tooling, which is already too beefy.
> >
> > For chrome apps, we created a downstream tool for this (cca).  I do think
> > its unfortunate that we all need to have separate downstream CLI's that
> > cannot be used together, but I don't think writing complicated plugins
> that
> > overwrite large part of a cordova workspace is a useful alternative.
> >  Perhaps grunt/gulp plugins that combine well are, not sure.
> >
> > Another option is to publish a project generator for your type of
> > application, either via yeoman, a custom script, or just a boilerplate
> > project.
> >
> >
> > >
> > >
> > > > For hooks -- there is a PR outstanding to just go ahead and add
> plugin
> > > > hooks.  Perhaps you would like to help review and comment on that to

Re: Notification on lock screen

[julio cesar sanchez]

This is a mail list for people who develop/contribute to cordova, not for
people who develop apps using cordova.
Ask on this group instead
https://groups.google.com/forum/m/#!forum/phonegap

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

[julio cesar sanchez]

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

[julio cesar sanchez]

That won't affect apps created with older SDKs because WKWebView isn't
available in older SDKs



2014-08-19 16:03 GMT+02:00 Jan Velecký :

> Well, this is bad, but we should know, if this affect also Cordova app,
> that
> is not created with iOS 8 SDK, but created by older SDK, older version of
> XCode.

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

[julio cesar sanchez]

You can choose the webview you want to use, but WKWebView is better

Cordova apps use the UIWebView, so your problem isn't related with this bug.
The idea is to change the UIWebView for the WKWebView in the future or let
the developer choose, but if this "bug" continues on the final version we
won't be able to use cordova apps with the improved WKWebView


2014-08-19 17:28 GMT+02:00 Ross Gerbasi :

> I haven't had much a chance to test this stuff out and I am guessing you
> know the answers to this already.
>
> Can you build with the iOS 8 SDK using UIWebView still or are you forced
> into WKWebView?
>
> I had a Cordova app on my device when I did the upgrade to iOS 8b5 and
> noticed it just force quits on launch. Is there a need to rebuild apps for
> iOS 8?
>
> Maybe this has to do with the webview lacking the ability to load?
>
>
> On Tue, Aug 19, 2014 at 10:21 AM, Shazron  wrote:
>
> > No, this is WKWebView only, does not affect UIWebView.
> >
> > On Tue, Aug 19, 2014 at 7:03 AM, Jan Velecký  wrote:
> > > Well, this is bad, but we should know, if this affect also Cordova app,
> > that
> > > is not created with iOS 8 SDK, but created by older SDK, older version
> of
> > > XCode.
> >
>

RE: Cordova and Android 4.4 (KitKat)

[julio cesar sanchez]

But if you want a better webview and still use phonegap api you can try
project crosswalk

Enviado desde mi Windows PhoneFrom: Carlos Santana
Sent: ‎9/‎2/‎2014 5:29
To: dev@cordova.apache.org
Subject: Re: Cordova and Android 4.4 (KitKat)
From
http://cordova.apache.org/docs/en/3.5.0/guide_platforms_android_index.md.html#Android%20Platform%20Guide
"Cordova supports Android 2.3.x (Gingerbread, starting with Android API
level 10) and 4.x" this includes Android 4.4

With Cordova when you run your App on Android the WebView used is the one
provided by the "Operating System".
This means that your Cordova App running on a device with Android 4.0.3
will be using a WebView with version 4.0.3, when the same App is running on
a device with Android 4.4 the webview will be 4.4 and so on.

Cordova currently doesn't provide a WebView, this is provided by Android.
So in your case your Cordova App should not show problems when running on
Android 4.4, but it will show problems in Android 4.0.3. Cordova will not
provide a 4.4 WebView on the device running 4.0.3 by "Magic" :-)

If you have a specific use case, and think there is problem with Cordova
and Android 4.4 WebView please open a bug report in our system
http://issues.cordova.io

By the way this is a mailing list for contributors, you might get faster
turnaround on this type of questions if you use one of the user forums like
http://stackoverflow.com/questions/tagged/cordova
https://groups.google.com/d/forum/phonegap

--Carlos



On Sat, Aug 30, 2014 at 11:11 AM, Sachin Lale  wrote:

> Hello,
> I am developing app using Cordova 3.5 and Android 4.0.3. The app is related
> to zooming,panning,rotating image with gesture by transform css. But this
> is having a bit performance issue while translating image. The image
> translate animation looks bit jerky. After searching a while i found the
> requestAnimationFrame will solve the problem and its available in Android
> 4.4. But there is no documentation on saying Cordova 3.5 supports Android
> 4.4 Chromium Webview. If it does not then do i have to use some plugin for
> it or ther is migration path available.
>
> Best regards,
> Sachin
>



-- 
Carlos Santana

Re: [iOS 8] Status of WKWebView work

[julio cesar sanchez]

I had "news" from apple, they closed my bug repport because it was
duplicated (obviously, I copied shazron bug report)

Re: NFC and IOS

[julio cesar sanchez]

I think they'll just release the payment API and no NFC

El miércoles, 10 de septiembre de 2014, Shazron 
escribió:

> Yeah, my guess is they didn't want to tip their hand in revealing Apple Pay
> early nor the presence of NFC enabled iPhones, and the development of the
> SDK had to be locked down for release next week.
>
> As usual, we all should file radars to Apple requesting access to this SDK,
> the more the better
>
> On Wed, Sep 10, 2014 at 8:42 AM, Don Coleman  > wrote:
>
> > Unfortunately there are no NFC APIs in the iOS 8 SDK.
> >
> > Maybe iOS 9...
> >
> > On Wed, Sep 10, 2014 at 11:34 AM, Lisa Seacat DeLuca  >
> > wrote:
> >
> > > Joe's future prediction skills were wrong "iOS will never adopt NFC,
> so I
> > > don't think that will ever be core. :( "
> > >
> > >
> >
> http://apache.markmail.org/search/?q=org.apache.incubator.callback-dev+list%3Aorg.apache.incubator.callback-dev+order%3Adate-backward+NFC#query:org.apache.incubator.callback-dev%20list%3Aorg.apache.incubator.callback-dev%20order%3Adate-backward%20NFC+page:2+mid:dktjzff4coc7cw5p+state:results
> > >
> > > ...time to reconsider adding NFC support to Core?
> > >
> > > :)
> > >
> > >
> > > Lisa
> > >
> > >
> > >
> > > I have an existing NFC plugin
> > > https://github.com/chariotsolutions/phonegap-nfc
> > > I'm hoping to implement a new plugin based on the w3c spec to help work
> > > out some issues.
> > > If anyone is interested in helping with the new implementation or has
> > > feedback on the w3c spec let me know.
> > > On Mon, Jan 20, 2014 at 6:08 PM, Brian LeRoux  > wrote:
> > >
> > > Core is something we support as a group. (Hence moving as much out of
> > core
> > > as possible!)
> > > In seriousness, if its a w3c spec I feel we should strongly considering
> > > adopting in our 'core' of plugins. (And likewise, deprecating things
> the
> > > w3c has moved on from such as WebSQL, Net Info, etc.)
> > > On Mon, Jan 20, 2014 at 2:52 PM, Lisa Seacat DeLuca <
> ldel...@us.ibm.com 
> > > wrote:
> > > What is Core?
> > > ... granted I haven't been as active as I would like in this community
> > > recently but one of the reasons I joined (other than IBM's interest in
> > > Worklight and Open Source) was to help understand the alignment of w3c
> > > specs and Cordova. My understanding of Cordova is that eventually it
> will
> > > "go away" meaning the browser players will catch up and enable device
> > > functionality in the mobile browsers without the need for the Cordova
> > > bridge. So if something is in a w3c spec I think it should be
> considered
> > > for the Cordova core code. Which is why I suggested NFC given it's w3c
> > > interest.
> > > *Lisa Seacat DeLuca* Emerging Mobile Software Engineer - IBM Master
> > > Inventor SWG Emerging Internet Standards
> > > -- *Phone:* 1-410-332-2128 | *Mobile:*
> > > 1-415-787-4589 * E-mail:* *ldel...@us.ibm.com * <
> ldel...@us.ibm.com > *
> > > personal website: **lisaseacat.com*  *
> > > Chat:*[image: Sametime:] ldel...@us.ibm.com  * Find me
> on:* [image:
> > > LinkedIn: http://www.linkedin.com/in/lisaseacat]<
> > > http://www.linkedin.com/in/lisaseacat> [image: Twitter:
> > > https://twitter.com/LisaSeacat]< https://twitter.com/LisaSeacat> *and
> > > within IBM on:* [image: IBM Connections:
> > >
> > >
> >
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0
> > > ]<
> > >
> > >
> >
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0
> > >
> > > [image: IBM]
> > > 100 East Pratt St 21-2212 Baltimore, MD 21202-1009 United States
> > > From: Ian Clelland > To: "
> de...@cordova.apache.org "
> > > >, bows...@apache.org
>  Date: 01/20/2014 05:42 PM
> > > Subject: Re: NFC API at W3C Sent by: icle...@google.com 
> > > --
> > > Definitely a cool plugin opportunity -- I'd love to make it easy for
> apps
> > > to take advantage of that kind of hardware. I don't yet see the benefit
> > of
> > > having it in core, though (independent of actual device support -- I'd
> > say
> > > this even if some future iOS device does have it built-in one day)
> > > What does "core" mean these days? (Asking seriously; I recall having
> some
> > > F2F discussion of this, but I don't know that we've ever explicitly
> > > spelled it out)
> > > Is it a commitment by the community to maintain and support a plugin?
> Or
> > > by Apache, or Adobe, or the PMC? It is a commitment to implement the
> > > functionality on all of our supported platforms? Does it just mean a
> > > repository at git.apache.org? Or a component in JIRA? Something else?
> > > Namespaces? npm? All of the above?
> > > I feel like "core" should imply some sort of responsibility from the
> PMC,
> > > but also that it should be reserved for pieces which are either
> critical
> > > to Cordova, have exactly 1 possible implementation (based on a
> published
> > > web standard) 

Re: Is there any plan to make InAppBrowser plugin based on CordovaWebView

[julio cesar sanchez]

the problem is WKWebView is only available on iOS 8, if you choose it, then
on older versions you'll get UIWebView? maybe you want WKWebView if
available, and then crosswalk or gecko intead UIWebView

2014-09-11 21:35 GMT+02:00 Shazron :

> I'm thinking of the preference route for IAP, for iOS - once we get the
> WKWebView support going, having a separate plugin for that seems too much
> trouble (and duplicating code).
> Maybe a pref like
>  where value can be
> WKWebView, Crosswalk etc
>
>
> On Thu, Sep 11, 2014 at 12:00 PM, Ian Clelland 
> wrote:
>
> > I think it sounds like it should be a new plugin, that you would install
> > instead of IAP, and that depends on Crosswalk, rather than forcing the
> > existing IAP plugin to require a separate webview.
> >
> > Or perhaps IAP should have a preference which determines which WebView it
> > should instantiate, much like Cordova itself does, as of 4.0.x
> >
> > On Thu, Sep 11, 2014 at 2:52 PM, Andrew Grieve 
> > wrote:
> >
> > > Makes sense that we should do this.
> > >
> > > On Thu, Sep 11, 2014 at 12:43 PM, Gao, Chun 
> wrote:
> > > > Hi,
> > > >
> > > > I found there are some requirements for InAppBrowser plugin to
> support
> > > HTML5 features
> > >
> >
> http://stackoverflow.com/questions/25613773/is-it-possible-to-force-cordova-inappbrowser-to-use-crosswalk-webview
> > > . As InAppBrowser plugin is implemented based on android WebView
> > component,
> > > lots of HTML5 features were not supported on Android before Kitkat. Is
> > > there any plan to implement the plugin with CordovaWebView? If the
> plugin
> > > could be implemented based on CordovaWebView, third party web runtime,
> > like
> > > Crosswalk , could provide the HTML5 capabilities to InAppBrowser.
> > > >
> > > > Regards,
> > > > Gao Chun
> > >
> >
>

Re: Is there any plan to make InAppBrowser plugin based on CordovaWebView

[julio cesar sanchez]

Oh, sorry, I though crosswalk and gecko webviews were coming to iOS too.

About the WKWebView and UIWebView being the only renderers because the
apple rule, ludei's cocoonjs uses their own renderer based on chromium

Re: Is there any plan to make InAppBrowser plugin based on CordovaWebView

[julio cesar sanchez]

I was talking about the now called canvas+
I saw an interview to one of the programmers in february, and he refered to
it as "our home made web browser", but according to the doc it's a
javascript interpreter, so it's not really a webview (can't really display
html elements, just translates javascript to native) and then the
restrictions don't apply.
He talked about the webview+ too, but they have released it just for
android, so it might be due to that iOS restriction.

El viernes, 12 de septiembre de 2014, Ian Clelland 
escribió:

> On Fri, Sep 12, 2014 at 2:23 AM, julio cesar sanchez <
> jcesarmob...@gmail.com 
> > wrote:
>
> > About the WKWebView and UIWebView being the only renderers because the
> > apple rule, ludei's cocoonjs uses their own renderer based on chromium
> >
>
> Do you have a source for that claim? It would be incredibly cool (and maybe
> even possible, according to a strict reading of Apple's review guidelines),
> but I can't confirm it.
>
> The closest thing that I can find is their Webview+ project, for Android
> 4.0+ (http://support.ludei.com/hc/en-us/articles/201952993), and the
> release notes announcing it (
> http://support.ludei.com/hc/en-us/articles/201941147-CocoonJS-v2-0-0), but
> also only for Android.
>
> Ian
>

Re: Is there any plan to make InAppBrowser plugin based on CordovaWebView

[julio cesar sanchez]

Anyway, reading the app store policies


   - 2.17

   Apps that browse the web must use the iOS WebKit framework and WebKit
   Javascript


Technically we don't browse the web, that should apply to InAppBrowser
plugin only

Re: Need help to develop a plugin to call a native IOS Libraries from the Phone gap

[julio cesar sanchez]

This is the official guide

http://docs.phonegap.com/en/3.5.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide

El domingo, 14 de septiembre de 2014, RAM Mohan Adduri <
radd...@consultants.ooredoo.qa> escribió:

>   Dear Team –
>
>
>
> I am just started developing Phonegap plugin to call a native service
> libraries in IPad so can you please help me on this. It would be great if
> you can provide some resources to understand how to develop this.
>
>
>
> Regards,
>
> Ram
>
>
>
>
> RAM Mohan Adduri
>
> Consultant
> Temporary Users
>
>
>
>
>
>PO Box 217, Doha, Qatar
>
> T: 28746  M:
>
> Follow us on  Twitter
>  and
> Facebook
> 
>
>
>
>
>
> --
>
> The information in this email and any attachments thereto may contain
> information that is confidential, protected by intellectual property
> rights, and may be legally privileged. It is intended solely for the
> addressee(s). Access to this email by anyone else is unauthorized. Any use,
> disclosure, copying, or distribution of the information contained herein by
> persons other than the designated addressee is unauthorized and may be
> unlawful. If you are not the intended recipient, you should delete the
> message immediately from your system. If you believe that you have received
> this email in error, please contact the sender. Any views expressed in this
> email and its attachments are those of the individual sender except where
> the sender expressly states them to be the views of Ooredoo.
>

Re: CB-5921

[julio cesar sanchez]

But you can't use swift if you support iOS 6, and cordova still supports
iOS 6

Re: NFC and IOS

[julio cesar sanchez]

Bad news

http://blogs.wsj.com/digits/2014/09/16/iphones-nfc-tech-will-only-work-with-apple-pay

RE: WKWebView for iOS8

[julio cesar sanchez]

@firt said yesterday on twitter the GM and the final versión has the
same build versión, so the problem should be thereFrom: Ally Ogilvie
Sent: ‎9/‎18/‎2014 5:32
To: dev@cordova.apache.org
Subject: Re: WKWebView for iOS8
Interested in any updates if you have 'em @Shazron ?
Following Brian's tweet i'm kinda hoping there has been a breakthrough to
load local files!

Gonna switch to WKWebViews from iOS 8 in ma WizViewManager plugin.
(WizViewManager is a WebView creator and manager for iOS and Android -
sorta like IAB)

On Thu, Aug 14, 2014 at 6:08 AM, Brian LeRoux  wrote:

> orly
>
>
> On Wed, Aug 13, 2014 at 1:57 PM, Shazron  wrote:
>
> > External urls of course work. The other alternative is to host www
> > contents on a local webserver, and for CORs use the whitelist.
> >
> > On Wed, Aug 13, 2014 at 1:51 PM, Shazron  wrote:
> > > Well, bad news, the workaround doesn't work. Nothing from a file://
> > > url will load in a WKWebView in an iOS 8 beta 5 device.
> > > Assumption 1 below fails.
> > >
> > > Assumptions:
> > > 1. WKWebView can load resources from tmp / Documents / Library /
> > Library/Caches
> > > 2. Can copy www folder in app bundle to tmp / Documents / Library /
> > > Library/Caches
> > >
> > > On Wed, Aug 13, 2014 at 11:18 AM, Shazron  wrote:
> > >> Jesse had a great idea -- surely you are allowed to load from tmp or
> > >> Documents. Assuming I can copy off the app bundle, I would copy the
> > >> www folder into tmp or Documents, and load the index.html from there.
> > >> This is the Windows Phone Cordova approach I believe.
> > >>
> > >> Assumptions:
> > >> 1. WKWebView can load resources from tmp or Documents
> > >> 2. Can copy www folder in app bundle to tmp or Documents
> > >>
> > >> On Wed, Aug 13, 2014 at 11:07 AM, Shazron  wrote:
> > >>> Bad news - local file loading in a WKWebView is borked ever since iOS
> > 8 beta 4.
> > >>>
> > >>> Not sure if there is some sort of new security model for loading
> local
> > >>> files in WKWebView >= beta 4.WKWebView cannot load local files in its
> > >>> app bundle anymore you get a blank screen, when on the device.
> > >>> Simulator seems fine. I found this out when updating my beta 3 iPhone
> > >>> to beta 5 yesterday. I downgraded back, but this beta unfortunately
> > >>> expires in 7 days on Aug 21, 2014.
> > >>>
> > >>> 1. https://devforums.apple.com/message/1011583
> > >>> 2.
> >
> http://stackoverflow.com/questions/24882834/wkwebview-not-working-in-ios-8-beta-4/24922619#24922619
> > >>> 3. https://issues.apache.org/jira/browse/CB-7288
> > >>> 4. rdar://problem/17761459
> > >>> 5. rdar://problem/17835098
> > >>>
> > >>>
> > >>> On Wed, Jul 16, 2014 at 12:05 PM, Marc Weiner  >
> > wrote:
> >  Same! Shazron, you're awesome!!
> > 
> > 
> >  On Wed, Jul 16, 2014 at 2:08 PM, Carlos Santana <
> csantan...@gmail.com
> > >
> >  wrote:
> > 
> > > Happy to see good news when returning from vacation. :-)
> > >
> > >
> > > On Mon, Jul 7, 2014 at 10:33 PM, Ally Ogilvie  >
> > wrote:
> > >
> > > > I'm usually an observer here but.. the urge to post was too
> great!
> > > >
> > > >
> > >
> >
> http://seattlesportsnet.files.wordpress.com/2013/11/anchorman-celebration-gif.gif
> > > >
> > > > Thanks for the research Shaz.
> > > >
> > > > On Tue, Jul 8, 2014 at 4:57 AM, Tommy Williams <
> to...@devgeeks.org
> > >
> > > wrote:
> > > >
> > > > > Yes!!!
> > > > > On 8 Jul 2014 05:52, "Shazron"  wrote:
> > > > >
> > > > > > Good news:
> > https://twitter.com/shazron/status/486235098715394048
> > > > > >
> > > > > > On Fri, Jun 27, 2014 at 3:46 PM, Shazron 
> > wrote:
> > > > > > > Broke the iOS 8 issue into sub-tasks:
> > > > > > > https://issues.apache.org/jira/browse/CB-7043
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Jun 16, 2014 at 8:20 AM, Shazron <
> shaz...@gmail.com>
> > > wrote:
> > > > > > >> Haven't yet - but from what I read - no. Something about
> > requests
> > > > > being
> > > > > > out
> > > > > > >> of process
> > > > > > >>
> > > > > > >>
> > > > > > >> On Monday, June 16, 2014, Andrew Grieve <
> > agri...@chromium.org>
> > > > wrote:
> > > > > > >>>
> > > > > > >>> Awesome.
> > > > > > >>>
> > > > > > >>> Shaz (or anyone else), curious if you've tested yet to
> see
> > if the
> > > > > > >>> whitelist
> > > > > > >>> still works with WKWebView? (e.g. does it go through
> > > > NSURLProtocol?)
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On Sat, Jun 14, 2014 at 8:16 PM, tommy-carlos williams
> > > > > > >>> 
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > > >>> > This looks promising.
> > > > > > >>> >
> > > > > > >>> > Thanks for the update, Shazron.
> > > > > > >>> >
> > > > > > >>> > - tommy
> > > > > > >>> >
> > > > > > >>> >
> > > > > > >>> > On Sun, Jun 15, 2014 at 

Re: [iOS] Xcode 6 requirement

[julio cesar sanchez]

The input file bug only affects if you compile using xcode 5, not sure if
are there more bugs like that.
Any reasons to use xcode 5 and don't update to 6? I think xcode 6 requires
mountain lion or newer, so people with lion and xcode 5 maybe don't want to
update the computer from lion to mountain lion or maveriks, but computers
with lion can definitelly update

Re: [iOS] Xcode 6 requirement

[julio cesar sanchez]

Sorry, I mess up with the OS versions, anyway, my point is any computer
with mountain lion (required by xcode 5) can be updated to maveriks and
yosemite.
Fear to update is other point, I didn't update to maveriks until june (I
wanted to test xcode 6 beta) for the same reasons as you, but I haven't had
problems so far

El sábado, 27 de septiembre de 2014, Darryl Pogue 
escribió:

> On 27 September 2014 08:48, julio cesar sanchez  > wrote:
> > Any reasons to use xcode 5 and don't update to 6? I think xcode 6
> requires
> > mountain lion or newer, so people with lion and xcode 5 maybe don't want
> to
> > update the computer from lion to mountain lion or maveriks, but computers
> > with lion can definitelly update
>
> Xcode 6 requires Mavericks or higher, which means people still on
> Mountain Lion can't
> upgrade.
>
> It would be convenient to keep Xcode 5 support until at least Yosemite
> is released.
> Several devs (myself included) are still on Mountain Lion because of
> Mavericks upgrade
> horror stories, but are planning to install Yosemite when it's available.
>

Re: Cordova Android < 3.5.1 XAS Security Vulnerability -- possibility of releasing a 2.7-based patched version

[julio cesar sanchez]

I have received the same mail.

BTW, in one of my apps I use an embedded cordova webview and I'm not sure
how to upgrade that app.

My main problem is I don't know how to install the core plugins I need,
that isn't explained on the embedding webviews guide. I don't think I can
use the CLI as the project isn't created with the CLI and isn't a real
cordova project.

Any hints?

Maybe using plugman?


2014-10-02 17:52 GMT+02:00 Ian Clelland :

> That patch fixes the startURL / errorURL issue, which is one of the major
> components of the 3.5.1 security release (CVE-2014-3500).
>
> The other issue is CVE-2014-3502, which is that intent urls can be launched
> by a Cordova app regardless of the whitelist settings. There isn't a patch
> which addresses this on the 2.x branch (unless IBM has produced one --
> Mike?) but it shouldn't be much work to simply remove the all of the code
> that handles intent / sms / geo / tel / etc. URLs from the
> shouldOverrideUrlLoading method of CordovaWebViewClient.java. If you remove
> the intent-launching code from that method, then it should stop your
> application from launching external applications.
>
> That being said, if you can afford to upgrade to 3.x (3.6.x now) then it
> will be much easier for you to get additional security patches in the
> future. We're not running or testing 2.x anymore, and can't guarantee, for
> instance, that the patch that Andrew mentioned or the technique that I just
> described will actually work.
>
> Ian
>
> On Thu, Oct 2, 2014 at 11:40 AM, Andrew Grieve 
> wrote:
>
> > That said, the relevant patch is here:
> >
> >
> >
> https://github.com/apache/cordova-android/commit/2ab81bc5aeb575fef3657cf48a671607e81ca37d
> >
> > (Ian / Joe, please correct me if there's more than that)
> >
> >
> >
> > On Thu, Oct 2, 2014 at 11:29 AM, Joe Bowser  wrote:
> >
> >> No, you should upgrade to 3.5.1.  We have dropped support for Cordova
> 2.x
> >> months ago, and we recommend upgrading.
> >>
> >> On Thu, Oct 2, 2014 at 7:33 AM,  wrote:
> >>
> >> > We have released applications in the Google Play store based on
> Cordova
> >> > 2.7.0 and have received notification from Google that these apps are
> >> > vulnerable to an Android Cordova security issue (
> >> > http://cordova.apache.org/announcements/2014/08/04/android-351.html).
> >> >
> >> > Upgrading to Cordova 3.5.1 would require significant work on our part.
> >> Is
> >> > there any possibility that you can release a patched Cordova Android
> >> > version based on 2.7 that would fix this security vulnerability?
> >> >
> >> > Please let me know whether you think this would be possible on your
> >> part.
> >> > Thank you!
> >> >
> >> > Thanks,
> >> > Steve Wilson
> >> >
> >>
> >
> >
>

Re: Cordova Android < 3.5.1 XAS Security Vulnerability -- possibility of releasing a 2.7-based patched version

[julio cesar sanchez]

I've using it for two and a half year on iOS but only for a year on android
Your blog post was very helpful (
http://infil00p.org/android/cordova/phonegap/2012/12/04/advanced-tutorial-using-cordovawebview-on-android/
)

We had a meeting with IBM guys yesterday and I think they mentioned that
they use the embedded webviews on worklight too

2014-10-02 19:16 GMT+02:00 Joe Bowser :

>
>
> On Thu, Oct 2, 2014 at 9:57 AM, julio cesar sanchez <
> jcesarmob...@gmail.com> wrote:
>
>> I have received the same mail.
>>
>> BTW, in one of my apps I use an embedded cordova webview and I'm not sure
>> how to upgrade that app.
>>
>> My main problem is I don't know how to install the core plugins I need,
>> that isn't explained on the embedding webviews guide. I don't think I can
>> use the CLI as the project isn't created with the CLI and isn't a real
>> cordova project.
>>
>> Any hints?
>>
>> Maybe using plugman?
>>
>
> Yes! Use plugman to install your plugins. It's kind-of annoying, but it's
> the best way to get them to work.  If there's bugs with Plugman, you should
> file an issue that it doesn't support this use case.
>
> Also, thanks for using the Embedded Cordova WebView! I'm really glad that
> there's real people who use it, since at times I was thinking I was making
> a big issue out of nothing.
>
>
>>
>>
>> 2014-10-02 17:52 GMT+02:00 Ian Clelland :
>>
>> > That patch fixes the startURL / errorURL issue, which is one of the
>> major
>> > components of the 3.5.1 security release (CVE-2014-3500).
>> >
>> > The other issue is CVE-2014-3502, which is that intent urls can be
>> launched
>> > by a Cordova app regardless of the whitelist settings. There isn't a
>> patch
>> > which addresses this on the 2.x branch (unless IBM has produced one --
>> > Mike?) but it shouldn't be much work to simply remove the all of the
>> code
>> > that handles intent / sms / geo / tel / etc. URLs from the
>> > shouldOverrideUrlLoading method of CordovaWebViewClient.java. If you
>> remove
>> > the intent-launching code from that method, then it should stop your
>> > application from launching external applications.
>> >
>> > That being said, if you can afford to upgrade to 3.x (3.6.x now) then it
>> > will be much easier for you to get additional security patches in the
>> > future. We're not running or testing 2.x anymore, and can't guarantee,
>> for
>> > instance, that the patch that Andrew mentioned or the technique that I
>> just
>> > described will actually work.
>> >
>> > Ian
>> >
>> > On Thu, Oct 2, 2014 at 11:40 AM, Andrew Grieve 
>> > wrote:
>> >
>> > > That said, the relevant patch is here:
>> > >
>> > >
>> > >
>> >
>> https://github.com/apache/cordova-android/commit/2ab81bc5aeb575fef3657cf48a671607e81ca37d
>> > >
>> > > (Ian / Joe, please correct me if there's more than that)
>> > >
>> > >
>> > >
>> > > On Thu, Oct 2, 2014 at 11:29 AM, Joe Bowser 
>> wrote:
>> > >
>> > >> No, you should upgrade to 3.5.1.  We have dropped support for Cordova
>> > 2.x
>> > >> months ago, and we recommend upgrading.
>> > >>
>> > >> On Thu, Oct 2, 2014 at 7:33 AM,  wrote:
>> > >>
>> > >> > We have released applications in the Google Play store based on
>> > Cordova
>> > >> > 2.7.0 and have received notification from Google that these apps
>> are
>> > >> > vulnerable to an Android Cordova security issue (
>> > >> >
>> http://cordova.apache.org/announcements/2014/08/04/android-351.html).
>> > >> >
>> > >> > Upgrading to Cordova 3.5.1 would require significant work on our
>> part.
>> > >> Is
>> > >> > there any possibility that you can release a patched Cordova
>> Android
>> > >> > version based on 2.7 that would fix this security vulnerability?
>> > >> >
>> > >> > Please let me know whether you think this would be possible on your
>> > >> part.
>> > >> > Thank you!
>> > >> >
>> > >> > Thanks,
>> > >> > Steve Wilson
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>

Re: Cordova Android < 3.5.1 XAS Security Vulnerability -- possibility of releasing a 2.7-based patched version

[julio cesar sanchez]

I'm updating the app right now.

I'm using plugman and it's working fine, the only problem I've found is, as
the app is old and I don't want to change the code, I tried to install the
file plugin from an older release (older than 1.0.0 release as it brought a
lot of changes) and got an error, but I'm not even sure if plugman supports
installing plugins from older releases.

I ended downloading the older release and instaled it from the folder, this
is working fine.


2014-10-02 21:37 GMT+02:00 julio cesar sanchez :

> I've using it for two and a half year on iOS but only for a year on android
> Your blog post was very helpful (
> http://infil00p.org/android/cordova/phonegap/2012/12/04/advanced-tutorial-using-cordovawebview-on-android/
> )
>
> We had a meeting with IBM guys yesterday and I think they mentioned that
> they use the embedded webviews on worklight too
>
> 2014-10-02 19:16 GMT+02:00 Joe Bowser :
>
>>
>>
>> On Thu, Oct 2, 2014 at 9:57 AM, julio cesar sanchez <
>> jcesarmob...@gmail.com> wrote:
>>
>>> I have received the same mail.
>>>
>>> BTW, in one of my apps I use an embedded cordova webview and I'm not sure
>>> how to upgrade that app.
>>>
>>> My main problem is I don't know how to install the core plugins I need,
>>> that isn't explained on the embedding webviews guide. I don't think I can
>>> use the CLI as the project isn't created with the CLI and isn't a real
>>> cordova project.
>>>
>>> Any hints?
>>>
>>> Maybe using plugman?
>>>
>>
>> Yes! Use plugman to install your plugins. It's kind-of annoying, but it's
>> the best way to get them to work.  If there's bugs with Plugman, you should
>> file an issue that it doesn't support this use case.
>>
>> Also, thanks for using the Embedded Cordova WebView! I'm really glad that
>> there's real people who use it, since at times I was thinking I was making
>> a big issue out of nothing.
>>
>>
>>>
>>>
>>> 2014-10-02 17:52 GMT+02:00 Ian Clelland :
>>>
>>> > That patch fixes the startURL / errorURL issue, which is one of the
>>> major
>>> > components of the 3.5.1 security release (CVE-2014-3500).
>>> >
>>> > The other issue is CVE-2014-3502, which is that intent urls can be
>>> launched
>>> > by a Cordova app regardless of the whitelist settings. There isn't a
>>> patch
>>> > which addresses this on the 2.x branch (unless IBM has produced one --
>>> > Mike?) but it shouldn't be much work to simply remove the all of the
>>> code
>>> > that handles intent / sms / geo / tel / etc. URLs from the
>>> > shouldOverrideUrlLoading method of CordovaWebViewClient.java. If you
>>> remove
>>> > the intent-launching code from that method, then it should stop your
>>> > application from launching external applications.
>>> >
>>> > That being said, if you can afford to upgrade to 3.x (3.6.x now) then
>>> it
>>> > will be much easier for you to get additional security patches in the
>>> > future. We're not running or testing 2.x anymore, and can't guarantee,
>>> for
>>> > instance, that the patch that Andrew mentioned or the technique that I
>>> just
>>> > described will actually work.
>>> >
>>> > Ian
>>> >
>>> > On Thu, Oct 2, 2014 at 11:40 AM, Andrew Grieve 
>>> > wrote:
>>> >
>>> > > That said, the relevant patch is here:
>>> > >
>>> > >
>>> > >
>>> >
>>> https://github.com/apache/cordova-android/commit/2ab81bc5aeb575fef3657cf48a671607e81ca37d
>>> > >
>>> > > (Ian / Joe, please correct me if there's more than that)
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Oct 2, 2014 at 11:29 AM, Joe Bowser 
>>> wrote:
>>> > >
>>> > >> No, you should upgrade to 3.5.1.  We have dropped support for
>>> Cordova
>>> > 2.x
>>> > >> months ago, and we recommend upgrading.
>>> > >>
>>> > >> On Thu, Oct 2, 2014 at 7:33 AM,  wrote:
>>> > >>
>>> > >> > We have released applications in the Google Play store based on
>>> > Cordova
>>> > >> > 2.7.0 and have received notification from Google that these apps
>>> are
>>> > >> > vulnerable to an Android Cordova security issue (
>>> > >> >
>>> http://cordova.apache.org/announcements/2014/08/04/android-351.html).
>>> > >> >
>>> > >> > Upgrading to Cordova 3.5.1 would require significant work on our
>>> part.
>>> > >> Is
>>> > >> > there any possibility that you can release a patched Cordova
>>> Android
>>> > >> > version based on 2.7 that would fix this security vulnerability?
>>> > >> >
>>> > >> > Please let me know whether you think this would be possible on
>>> your
>>> > >> part.
>>> > >> > Thank you!
>>> > >> >
>>> > >> > Thanks,
>>> > >> > Steve Wilson
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>

Re: Genymotion on Mac for Cordova testing

[julio cesar sanchez]

I've just installed and tested following this steps:

1. Download Virtual box
http://download.virtualbox.org/virtualbox/4.3.18/VirtualBox-4.3.18-96516-OSX.dmg
2. Install it
3. Download Genymotion
http://files2.genymotion.com/genymotion/genymotion-2.3.0/genymotion-2.3.0.dmg
(might need login)
4. Install it (Genymotion and Genymotion Shell)
5. Open Genymotion
6. Download a new device and start it.

I got a device with black screen, so I followed this steps:

When I start a virtual device, why does the window remain black?

You are probably in either of the following situations:

   - Your network adapter may be misconfigured. In this case:
  1. Run VirtualBox.
  2. Open *VirtualBox > Preferences **> Network*
  3. Edit the *Host-only Network* by clicking .
  4. Check that the adapter IPv4 address is in the same network (
  192.168.56.0/24 by default) as the DHCP server address, lower address
  bound and upper address bound. If not, your virtual device cannot start.
   You can also remove the *Host-only Network* by clicking . Genymotion
   will automatically recreate it at the next virtual device start.

I deleted the existing Host-only network adapter and it was recreated as it
says


For other problems check

https://cloud.genymotion.com/page/faq/


2014-10-22 17:41 GMT+02:00 Kerri Shotts :

> GenyMotion runs fine on my Mac (OS X 10.9.5). I haven't upgraded Geny to
> 2.3.0, so am still on 2.2.2. My Virtual Box is 4.3.6 (a tad out-of-date).
>
> Are you having a problem getting the app itself to run, or is a problem
> with getting the emulators started? Have you checked the console app to see
> if anything interesting shows up in there?
>
>
> ___
> *Kerri Shotts*
> photoKandy Studios, LLC
>
> On the Web: http://www.photokandy.com/
>
> *Social Media:*
>   Twitter: @photokandy, http://twitter.com/photokandy
> ​  App.net: @photokandy, https://alpha.app.net/photokandy
>   Google+: https://plus.google.com/110429856422449500918/posts
>   Facebook: https://www.facebook.com/photoKandy
>   Behance: https://www.behance.net/kerrishotts
>   Tumblr: http://photokandy.tumblr.com/
> ​  Github: https://github.com/kerrishotts
>https://github.com/organizations/photokandyStudios
>   CoderWall: https://coderwall.com/kerrishotts
> ​  Stack Overflow: ​
> http://stackoverflow.com/users/741043/kerri-shotts
>
>
> *Apps on the Apple Store:*
> ​  Greek Interlinear Bible 1.3​:
>
> https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828
>
> *Books:*
> ​  PhoneGap 3.x Mobile Application Development Hotshot:
>   http://www.photokandy.com/books/phonegap-3-x-hotshot/
>
>   PhoneGap 2.x Mobile Application Development Hotshot:
>   http://www.photokandy.com/books/phonegap-2-x-hotshot/
>
>   Instant PhoneGap Social Application Development:​
>   http://www.photokandy.com/books/instant-social-app/
>
>
>
> On Wed, Oct 22, 2014 at 9:36 AM, Lisa Seacat DeLuca 
> wrote:
>
> >
> >
> > Hey guys, I need to test an Android 4.2 device for a Cordova issue I'm
> > looking into and I just got a mac *yay*.  So I installed Genymotion and
> am
> > having the hardest time getting it to run.  I know most of our team of
> > developers use a Mac.  Does anyone else have Genymotion running?  Anyone
> > have any difficulties during install that they might have a trick for me
> to
> > try.  I have a sneaking suspicion that it's related to permissions but I
> > could be wrong.  Genymotion runs without any problem on my Windows
> machine.
> > It's just getting a little old going back and forth between the machines.
> >
> > Any advice appreciated!
> >
> >
> > Lisa
> > @LisaSeacat
> >
>

Re: Genymotion on Mac for Cordova testing

[julio cesar sanchez]

Did you try what I said?

I got that error to, and followed this steps
When I start a virtual device, why does the window remain black?

You are probably in either of the following situations:

   - Your network adapter may be misconfigured. In this case:
  1. Run VirtualBox.
  2. Open *VirtualBox > Preferences **> Network*
  3. Go to *Host-only Network*
  4. Removed the *vboxnet0* by clicking

So when I restarted the device image again it connected.



2014-10-22 23:13 GMT+02:00 Joerg Holz :

> So, it’s not a Gennymotion problem, it’s a VirtualBox problem.
>
> My corresponding versions are: VirtualBox 4.3.16 and the last version of
> Genymotion running on Yosemite, but it’s running on Mavericks also.
>
> I would suggest to update your VirtualBox, otherwise I would uninstall
> VirtualBox completly and reinstall it.
>
> On the other hand: Which system are you using on the new/old mac?
>
>
> Joerg
>
>
>
> > Am 22.10.2014 um 22:44 schrieb Lisa Seacat DeLuca :
> >
> > Genymotion itself installs just fine and I can download vms fine.  I
> just can't get any of them to run.  I thought maybe it was an issue with
> permissions but even when i run from the command line with sudo I get
> errors (although different).  I opened a stackoverflow question here:
> >
> >
> http://stackoverflow.com/questions/26287897/genymotion-not-working-on-mac
> >
> > but my error is: "Unable to connect to the virtual device. Genymotion
> will now close. Please check VirtualBox network configuration."
> >
> > I tried walking through the suggestions in the comments about updating
> the network adapters but that didn't fix my problem.  I just get a black
> screen until it throws the error.  Maybe i shoudl try to track down an
> older version of genymotion since it sounds like that works for other
> people.  Ugh, would make my life easier to be able to test Cordova apps on
> my mac.
> >
> > Anyways, thank you all of your response,
> >
> >
> > Lisa
> >
>
> 
> Jörg Holz | +49-175-640 35 80
> h...@hamburg.de
>
> NEU: doreport - die Reportingsoftware:
> http://www.doreport.de
> 
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Genymotion on Mac for Cordova testing

[julio cesar sanchez]

Mine was brand new too and I solved it deleting the network, but if it
doesn't work for you, I don't know what else you can do


2014-10-22 23:54 GMT+02:00 Joerg Holz :

> Brand new sounds good:
>
> What’s about the newest Java-Version? I’m using Yosemite since the second
> dev-Version and I had problems until I install java 8.
>
> Joerg
>
>
> > Am 22.10.2014 um 23:29 schrieb Lisa Seacat DeLuca :
> >
> > It's a brand new mac and brand new installation so i'm using the latest
> version of genymotion and virtualbox.  I can actually launch the vm's from
> within virtualbox and they startup just fine.  So it seems like it's more
> of a problem with genymotion being able to "talk" to the virtualbox.  So
> that's why I tried out the network fixes suggested but that didn't solve my
> issue.
> >
> > Lisa
> >
> > btw, also tried downgrading to an older version of genymotion and that
> didn't solve the problem
> >
> >
> >
> > Joerg Holz ---10/22/2014 05:14:40 PM---So, it’s not a Gennymotion
> problem, it’s a VirtualBox problem. My corresponding versions are: Virtua
> >
> > From: Joerg Holz 
> > To:   dev@cordova.apache.org
> > Date: 10/22/2014 05:14 PM
> > Subject:  Re: Genymotion on Mac for Cordova testing
> >
> >
> >
> > So, it’s not a Gennymotion problem, it’s a VirtualBox problem.
> >
> > My corresponding versions are: VirtualBox 4.3.16 and the last version of
> Genymotion running on Yosemite, but it’s running on Mavericks also.
> >
> > I would suggest to update your VirtualBox, otherwise I would uninstall
> VirtualBox completly and reinstall it.
> >
> > On the other hand: Which system are you using on the new/old mac?
> >
> >
> > Joerg
> >
> >
> >
> > > Am 22.10.2014 um 22:44 schrieb Lisa Seacat DeLuca  >:
> > >
> > > Genymotion itself installs just fine and I can download vms fine.  I
> just can't get any of them to run.  I thought maybe it was an issue with
> permissions but even when i run from the command line with sudo I get
> errors (although different).  I opened a stackoverflow question here:
> > >
> > >
> http://stackoverflow.com/questions/26287897/genymotion-not-working-on-mac
> > >
> > > but my error is: "Unable to connect to the virtual device. Genymotion
> will now close. Please check VirtualBox network configuration."
> > >
> > > I tried walking through the suggestions in the comments about updating
> the network adapters but that didn't fix my problem.  I just get a black
> screen until it throws the error.  Maybe i shoudl try to track down an
> older version of genymotion since it sounds like that works for other
> people.  Ugh, would make my life easier to be able to test Cordova apps on
> my mac.
> > >
> > > Anyways, thank you all of your response,
> > >
> > >
> > > Lisa
> > >
> >
> > 
> > Jörg Holz | +49-175-640 35 80
> > h...@hamburg.de
> >
> > NEU: doreport - die Reportingsoftware:
> > http://www.doreport.de
> > 
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>
> 
> Jörg Holz | +49-175-640 35 80
> h...@hamburg.de
>
> NEU: doreport - die Reportingsoftware:
> http://www.doreport.de
> 
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

InAppBrowser insertCSS/executeScript with file option code example is confusing

[julio cesar sanchez]

Looking into the inAppBrowser code, it seems to me that the insertCSS and
executeScript are for injecting an external CSS or JS, but looking at the
code example, it seems (to me), that an internal file could be loaded

insertCSS example code:

var ref = window.open('http://apache.org', '_blank', 'location=yes');
ref.addEventListener('loadstop', function() {
ref.insertCSS({file: "mystyles.css"});
});

executeScript example code:

var ref = window.open('http://apache.org', '_blank', 'location=yes');
ref.addEventListener('loadstop', function() {
ref.executeScript({file: "myscript.js"});
});


So, can anybody confirm if this two functions are only for external
files? or is it possible to load files from www folder?

If only external files are possible, then maybe we should change the
example codes to something like

var ref = window.open('http://apache.org', '_blank', 'location=yes');
ref.addEventListener('loadstop', function() {
ref.insertCSS({file: "http://www.example.com/mystyles.css"});
});

Re: cordova 64-bit support

[julio cesar sanchez]

what's the point of swift plugins?
is there something that can't be done with objective-c and need swift?
I think iOS 6 support is more important that the swift plugins

2014-11-07 20:14 GMT+01:00 Shazron :

> Yup. So the answer is:
>
> cordova-ios:
> 64 bit support since cordova-ios 3.4.1. Xcode 6 only support since
> cordova-ios 3.7.0.
>
> On Fri, Nov 7, 2014 at 11:04 AM, Marcel Kinard  wrote:
>
> > I suspect Vidiraj's question was driven by this:
> > https://developer.apple.com/news/?id=10202014a
>

Re: cordova 64-bit support

[julio cesar sanchez]

iOS 5 support was removed on cordova 3.5, released on may 2014, I think
it's too soon to remove iOS 6 support with all the devices left behind
(iphone 3gs and ipod touch 4gen), just to add swift plugins.

I'm ok with dropping support to old versions when there are real advantages
or security reasons.

I'm limited on resources too, but I volunteer to test on my ipod touch

Re: cordova 64-bit support

[julio cesar sanchez]

Apple just says "earlier" 5%. That should be iOS 5 and iOS 6

El domingo, 9 de noviembre de 2014, Terence M. Bandoian 
escribió:

> It might make sense to consider dropping support for an iOS version when
> usage, as reported by Apple, drops below a certain level.
>
> -Terence Bandoian
>
>
> On 11/8/2014 5:13 PM, julio cesar sanchez wrote:
>
>> iOS 5 support was removed on cordova 3.5, released on may 2014, I think
>> it's too soon to remove iOS 6 support with all the devices left behind
>> (iphone 3gs and ipod touch 4gen), just to add swift plugins.
>>
>> I'm ok with dropping support to old versions when there are real
>> advantages
>> or security reasons.
>>
>> I'm limited on resources too, but I volunteer to test on my ipod touch
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

I've fixed an issue. What's next?

[julio cesar sanchez]

CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I
asked if it could be assigned to me.
Shazron assigned to me and I fixed it with this pull request
https://github.com/apache/cordova-plugin-dialogs/pull/39

It's been 3 weeks and it hasn't been merged, so I don't know if I have to
do something else, it's the first issue assigned to me.

Re: I've fixed an issue. What's next?

[julio cesar sanchez]

I updated the pull request yesterday to add the iOS 8 macro code (and other
change proposed by Shazron), so it can work on Xcode 5

Re: [Discuss] Plugins release

[julio cesar sanchez]

Ian, can you take a look into this PR before updating the dialogs plugin?

https://issues.apache.org/jira/browse/CB-7734
https://github.com/apache/cordova-plugin-dialogs/pull/39

2014-11-26 10:16 GMT+01:00 Sergey Grebnov (Akvelon) 
:

> Jesse, sounds good, you can re-work any of them to show example/pattern
> and I'll assist you in reworking the rest.
>
> Thx!
> Sergey
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Tuesday, November 25, 2014 9:55 PM
> To: dev@cordova.apache.org
> Subject: Re: [Discuss] Plugins release
>
> +1 to getting the updates out.
>
> Sergey, I would like to hold off on those plugins until I can do a
> windows-universal refactor to get rid of all the extra csproj's that are
> being added.
>
> @purplecabbage
> risingj.com
>
> On Tue, Nov 25, 2014 at 7:43 AM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
> > +1, fully support as well.  If someone has a chance to take a look on
> > +the
> > following PRs I will appreciate this! Thx
> >
> > https://github.com/apache/cordova-plugin-vibration/pull/25
> > https://github.com/apache/cordova-plugin-battery-status/pull/19
> > https://github.com/apache/cordova-plugin-globalization/pull/31
> >
> > Thx!
> > Sergey
> > -Original Message-
> > From: Ian Clelland [mailto:iclell...@chromium.org]
> > Sent: Tuesday, November 25, 2014 4:36 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Discuss] Plugins release
> >
> > +1, I heartily support this.
> >
> > I'll take a look at the PRs and call out any that I think need extra
> > consideration. (We here in Canada can spend some time on Thursday and
> > Friday merging some of them in :) ) On Mon Nov 24 2014 at 5:28:51 PM
> > Steven Gill  wrote:
> >
> > > I want to do a plugins release next Monday, Dec 1. (Thursday/Friday
> > > are holidays in the states).
> > >
> > > I will review PRs the next few days, please bring any that you deem
> > > important to my attention.
> > >
> >
>

Re: Cordova file transfer

[julio cesar sanchez]

This is a cordova development mailing list, not for problems when
developing apps using cordova.
Ask on the phonegap google group or stack overflow.

But yes, you can upload other files, not just images.

2014-11-28 11:48 GMT+01:00 Ashima Bansal :

> Is it possible to upload pdf or text files from our phone internal
> storage/SD Card . I tried using file transfer but its working only for
> images and not for other files. How can we do this ?
>
> Thank You,
> Ashima Bansal
>

Re: Build proyect on different Android Cordova in the same PC

[julio cesar sanchez]

I have not tried what Ivan said, but as you are on version 2.9.0 I don't
think you can because cordova 2.9.0 wasn't installed on the system, just
downloaded, and there is no direct update from 2.9.X to 3.X.X.

What I did when upgraded from 2.9.1 to 3.6.4 was, I generated the
cordova-3.6.4.jar, deleted cordova-2.9.1.jar from the android project,
added cordova-3.6.4.jar and tested, as 2.9.1 included all the plugins in
the core and cordova 3.X.X didn't include them, I had to install the
plugins I was using with plugman.
So, updating like I mentioned, you can generate the .jar for any cordova
version and just test it, but your project won't be a real cordova project
and you'll need to update everytime like this, and install the plugins
using plugman instead of using the cordova CLI

So, the other choice you have is to create a new project using the CLI,
copy your current html, css and javascript and try. If you were using any
plugin it wont work, so you install the plugins you need using the cordova
CLI and then you will be able to update easily on new cordova updates.

Re: Deprecation Wars: ICS vs Gingerbread

[julio cesar sanchez]

The other day I saw a thread of a developer trying to support android 2.2,
and told me he was from argentina, was building an app just for argentina
and 2.2 had a big market share there.
I'm from Spain and 2.3 devices are still sold here.

I just tell this to add another point of view, but I'm OK with the 2.3
deprecation, some of the new features like the plugable webviews won't be
supported on 2.3 anyway, right?

Re: [DISCUSS] Plugins Release

[julio cesar sanchez]

Well, if somebody can review the pull request I did some months ago for the
dialogs plugin I'll be grateful
https://github.com/apache/cordova-plugin-dialogs/pull/39

I tested it on xcode 5 and xcode 6, on iOS 6, iOS 7 and iOS 8, it fixes a
repported bug (CB-7734) and changes the UIAlertView to UIAlerController
when available (it was necessary to fix the bug and makes the plugin future
proof)

El sábado, 10 de enero de 2015, Steven Gill 
escribió:

> I noticed Shaz cleaned up the iOS camera plugin. I figure other plugins
> might be ready for a release soon too.
>
> Let me know if you have any thoughts or concerns. I will look at doing this
> release next week.
>

anybody from phonegap build team here?

[julio cesar sanchez]

Hi,

I know this a cordova list, but maybe there is somebody from phonegap build
team here and can answer.

I have a doubt about contributing to phonegap build plugins, the docs say:
Submitting Your Plugin

Once your plugin is in a state that you're happy with,
submit the plugin 
to PhoneGap Build.
But the url goes to https://build.phonegap.com/plugins#add, where a message
like this appears "Please upgrade your PhoneGap Build account to submit a
plugin."

So, now you can't contribute to the plugins if you don't have a paid
account? I've submitted some plugins with my free account before the change
that allowed to publish private plugins, shouldn't it allow to submit open
source plugins to everyone, including free users, and add another option
for uploading private plugins just for paid accounts?

I know I can publish them in plugins.cordova.io and they can be used on
phonegap build too, but I think it's better if the plugins appear in both.

Re: Documentation on Android/Cordova Webview

[julio cesar sanchez]

If you unzip this, you have the framework directory

https://www.apache.org/dist/cordova/platforms/cordova-android-3.6.4.tgz

2015-01-12 12:55 GMT+01:00 Mike Dawson :

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Cordova Dev List,
>
> I'm looking to build a Hybrid app version and tried following:
>
>
> http://cordova.apache.org/docs/en/4.0.0/guide_platforms_android_webview.md.html#Android%20WebViews
>
> I think this might be a bit out of date.  I am running Cordova 4.2 and
> compiling with API Level 19; all on Ubuntu 14.10 which is all running
> fine for normal cordova and android development.
>
> The documentation says to unzip the download (whereas the main site
> recommends the normal installation using npm).  It then says to go to
> the android package framework directory.  There is no such framework
> directory either in a created project or in
> /usr/local/lib/node_modules/cordova or in a newly created cordova
> project with the android platform added.
>
> What does seem to work is to create a blank cordova project; add
> android, and then use the CordovaLib project generated as a library for
> another native android project; e.g.
>
> #native android project here
> mkdir androidproject
> cd androidproject
> android create project --target 6 --name UstadMobile --path
> ./ustadmobile --activity UstadMobile --package com.toughra.ustadmobile
>
> cd ..
>
> cordova create umcordovalib com.ustadmobile UMCordovaLib
> cd umcordovalib
> cordova platform add android
> cordova build
>
> cd ../androidproject
> android update project --target 6 --path ./ustadmobile/ --library
> ../../umcordovalib/platforms/android/CordovaLib/
>
> Is there any more up to date documentation on this? I did a quick google
> but couldn't find anything.  If not once I get through this I'd be happy
> to contribute a revised version of the documentation.
>
> Thanks/Regards,
>
> - -Mike
>
> - --
> Mike Dawson
> CEO
> Ustad Mobile
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJUs7Y9AAoJEMDbIyechsEfkMAQANDfbXnf6lnFryM30ae6gQ18
> htGraR10PYvlzTFJPz10Xbji7RHwRSNRej+g8Fok1tisi7MGhpcp5XAgFEp8kYcS
> vqDxqMZTI+PEDP3oGpYDB7z7hX6IGxzaXl7LcbujHh5ATFQST6zJe1JM8aCzZxeB
> 5IchoYDxIK0LFcmJgc9wAFuFYX8hSwB2/nlnZ72tVbMZo8PNz4268rZcNo0xLjKg
> KydBMt6Iq47Mwkqb/wp8Sq4okT3z8emb/aTx3yodzeI0pi/rnbrnVEF2YES7Vr4F
> z/BoZWE6PQKfRWjKlK59HaqkwXM+NfTrA+KnSahqFD2hsDb8JIDIUqaj5ESUMD9P
> O/3At0EOgHop3FjG2LC432k9yjjeqwt8eD3gnp6CjSBcga+03TKEFhjMQK7ow9Fj
> uPF9IbTdgkuNEMb+dqtqMFaKk+B363wN4+fpxTyiSAeVadaIOy45ga8FVl5UHux6
> Mgx2P0QB+/rvfLNALm/XrQOFsikVhaJEII7IMZ3IK7IA0FdjI5d78yN8W+mzlS8n
> cjPKCi0SHpNATPZUI6QYnFxG+1xWReSh+nh3Nrqc60J4HgsFCSLa4XS6Y5NXzMCu
> RyDgf7fbsuS/GjGlTu/5eXqe/f9njYrigP+o4o9GGmXoUuvm33Em/9yArL5dbSP1
> cRFsWjo8j04jefDmeQEX
> =4hbU
> -END PGP SIGNATURE-
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: anybody from phonegap build team here?

[julio cesar sanchez]

I know, I have asked there too, but that is an user forum, I was looking
for an answer from somebody from the phonegap build team, I'm not sure if
I'll get that there, and I have read answers from people on the phonegap
team on this mail list, so maybe people from the phonegap build team read
this list too. (I suppose they are different teams)





2015-01-12 22:01 GMT+01:00 Shazron :

> Hi Julio,
> The appropriate forum for PGB is http://community.phonegap.com
>
> On Mon, Jan 12, 2015 at 10:16 AM, Gorkem Ercan 
> wrote:
> >
> >
> > On 12 Jan 2015, at 4:15, julio cesar sanchez wrote:
> >
> >> Hi,
> >>
> >> I know this a cordova list,
> >
> > Actus Reus... and Mens Rea..
> >
> >> but maybe there is somebody from phonegap build
> >> team here and can answer.
> >>
> >> I have a doubt about contributing to phonegap build plugins, the docs
> say:
> >> Submitting Your Plugin
> >>
> >> Once your plugin is in a state that you're happy with,
> >> submit the plugin <http://build.phonegap.com/plugins#add>
> >> to PhoneGap Build.
> >> But the url goes to https://build.phonegap.com/plugins#add, where a
> message
> >> like this appears "Please upgrade your PhoneGap Build account to submit
> a
> >> plugin."
> >>
> >> So, now you can't contribute to the plugins if you don't have a paid
> >> account? I've submitted some plugins with my free account before the
> change
> >> that allowed to publish private plugins, shouldn't it allow to submit
> open
> >> source plugins to everyone, including free users, and add another option
> >> for uploading private plugins just for paid accounts?
> >>
> >> I know I can publish them in plugins.cordova.io and they can be used on
> >> phonegap build too, but I think it's better if the plugins appear in
> both.
> >
> > -
> > 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: anybody from phonegap build team here?

[julio cesar sanchez]

Ally, thanks for the link, I opened another thread and got a similar
answer. (I should have searched).

It's sad because I submited some plugins when having a paid plan wasn't
necessary for submitting plugins. One of them was approved and it's used by
more than 5000 apps. Now I can't update the plugin or submit new plugins
there.
I think I'll just move to plugins.cordova.io, delete the plugin from PGB
and break some fo the 5000 apps if they rebuild someday.





2015-01-16 10:54 GMT+01:00 Ally Ogilvie :

> Julio,
>
> This might help you
>
> http://community.phonegap.com/nitobi/topics/please-upgrade-your-phonegap-build-account-to-submit-a-plugin
> You understand correct. However, it's not all bad news: You can still
> upload your plugin to the Cordova Registry and recommend to your users they
> add `source="plugins.cordova.io"` attribute to a PhoneGap Build project
> config.xml.
>
> Ally.
>
>
> On Tue, Jan 13, 2015 at 7:21 AM, julio cesar sanchez <
> jcesarmob...@gmail.com
> > wrote:
>
> > I know, I have asked there too, but that is an user forum, I was looking
> > for an answer from somebody from the phonegap build team, I'm not sure if
> > I'll get that there, and I have read answers from people on the phonegap
> > team on this mail list, so maybe people from the phonegap build team read
> > this list too. (I suppose they are different teams)
> >
> >
> >
> >
> >
> > 2015-01-12 22:01 GMT+01:00 Shazron :
> >
> > > Hi Julio,
> > > The appropriate forum for PGB is http://community.phonegap.com
> > >
> > > On Mon, Jan 12, 2015 at 10:16 AM, Gorkem Ercan  >
> > > wrote:
> > > >
> > > >
> > > > On 12 Jan 2015, at 4:15, julio cesar sanchez wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I know this a cordova list,
> > > >
> > > > Actus Reus... and Mens Rea..
> > > >
> > > >> but maybe there is somebody from phonegap build
> > > >> team here and can answer.
> > > >>
> > > >> I have a doubt about contributing to phonegap build plugins, the
> docs
> > > say:
> > > >> Submitting Your Plugin
> > > >>
> > > >> Once your plugin is in a state that you're happy with,
> > > >> submit the plugin <http://build.phonegap.com/plugins#add>
> > > >> to PhoneGap Build.
> > > >> But the url goes to https://build.phonegap.com/plugins#add, where a
> > > message
> > > >> like this appears "Please upgrade your PhoneGap Build account to
> > submit
> > > a
> > > >> plugin."
> > > >>
> > > >> So, now you can't contribute to the plugins if you don't have a paid
> > > >> account? I've submitted some plugins with my free account before the
> > > change
> > > >> that allowed to publish private plugins, shouldn't it allow to
> submit
> > > open
> > > >> source plugins to everyone, including free users, and add another
> > option
> > > >> for uploading private plugins just for paid accounts?
> > > >>
> > > >> I know I can publish them in plugins.cordova.io and they can be
> used
> > on
> > > >> phonegap build too, but I think it's better if the plugins appear in
> > > both.
> > > >
> > > > -
> > > > 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
> > >
> > >
> >
>
>
>
> --
> <http://www.wizcorp.jp/>Ally Ogilvie
> Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/>
> --
> TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Website
> <http://www.wizcorp.jp/> | Twitter <https://twitter.com/Wizcorp> |
> Facebook
> <http://www.facebook.com/Wizcorp> | LinkedIn
> <http://www.linkedin.com/company/wizcorp>
>

Re: How to Implement native features in Cordova

[julio cesar sanchez]

As the media plugin doesn't follow the W3C specification for media capture,
it might be included in the plugin, but you should check if this is
possible on other platforms too.
You can file an issue on the cordova JIRA (
https://issues.apache.org/jira/browse/CB) as enhancement to the media
plugin providing the details you wrote here.

If you want to try to create a separate plugin, then check
http://docs.phonegap.com/en/3.5.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide

2015-01-22 4:47 GMT+01:00 Jeremy Plack :

> Hi,
>
> I'm new to Cordova and am interested in adding a native android feature.
>
>
> http://developer.android.com/reference/android/media/MediaMetadataRetriever.html
>
> This looks to me like it would be an improvement to the media plugin, or
> should this be in its own plugin?
>
> how would I go about integrating this feature into cordova and enlist some
> help and guidance in doing so?
>
> Thanks,
>
> *Jeremy Plack*
> *Freelance IT*
> *(636) 692-3465*
> stlouiswebservices.com
>

Re: Introduction for Julian Horn

[julio cesar sanchez]

And what about detecting if the user didn't include any cordova tag?

I usually see questions on stackoverflow asking, "X feature of cordova
isn't working". And the accepted answer is "include the cordova.js script
tag in you index.html"

2015-03-16 14:37 GMT+01:00 Horn, Julian C :

> Hi Jesse,
>
> While it's certainly true that it's impossible to bullet-proof Cordova,
> protection against multiple inclusion is pretty basic.  All the C system
> include files protect against multiple inclusion.  JavaScript objects like
> jQuery include code to tolerate multiple inclusion.  We should too.
>
> The fix certainly does not require a large chunk of time!  Here's the
> entire fix; you put this up near the top of cordova.js, inside the
> outermost function invocation:
>
> if (window.cordova) {
> return;
> }
>
> To appreciate why this matters, I think you have to cultivate a product
> viewpoint.  The Intel XDK is a development toolkit that attempts to make
> cross-platform HTML5 more approachable.  Obviously, as people get farther
> into HTML5 development they will run into all kinds of hard problems.  But
> right out of the box, you want people to be able to put together simple
> apps simply.  That kind of good initial experience is a key to making an
> approachable product.
>
> This particular mistake, of including two 

Re: Regarding the contribution

[julio cesar sanchez]

Welcome.

You can start here http://cordova.apache.org/#contribute



2015-03-19 11:54 GMT+01:00 Rahulkar, Prashant :

> Hello Sir,
> I am keen to contribute in your Apache Cordova project, I have any 9+
> years of experience in Web, Java, Enterprises application development.
> Please add me in your new member list and suggest to start with code.
>
> Thanks,
> Prashant Rahulkar
>
>

Re: Plugin Development

[julio cesar sanchez]

Hello.

Read the link you provided, read the SDK documentation and mix the
knowledge.

Most of the cordova plugins are open source and you can find them on
github, so you can search a few to see more complex code.

If you have any doubts after trying, ask on stackoverflow. This mail list
if for the development of cordova itself, not for 3rd party plugins or
problems while developing with cordova.


2015-03-27 7:37 GMT+01:00 Rahul Bhooteshwar <
rahul.bhootesh...@hotwaxsystems.com>:

> Hello All,
> I am new to cordova development, and would like to know how to develop
> cordova plugins for various platforms. I found the development guide for
> the same here
> <
> http://cordova.apache.org/docs/en/edge/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide
> >.
> But it explains the basic procedure to do the same. I would like to know
> how to develop cordova plugins using the SDK provided by device vendor for
> specific  platform. I want to develop cordova plugin for LineDevice
> . I have the ios SDK provided by vendor, but I don't
>  know how to use  it with cordova. The SDK provided contains LineaSDK.h and
> libLineaSDK.a files. Please help.
>
> Rahul Bhooteshwar
>

[proposal] [ANDROID] move inAppBrowser intents from onPageStarted to shouldOverrideUrlLoading

[julio cesar sanchez]

I've been looking into issues and I have seen this one:
https://issues.apache.org/jira/browse/CB-8180

Right now the code to handle the tel links is inside the onPageStarted

if (url.startsWith(WebView.SCHEME_TEL)) {
try {
Intent intent = new Intent(Intent.ACTION_DIAL);
intent.setData(Uri.parse(url));
cordova.getActivity().startActivity(intent);
} catch (android.content.ActivityNotFoundException e) {
LOG.e(LOG_TAG, "Error dialing " + url + ": " +
e.toString());
}
}

But the problem is, it launchs the intent and try to open the web page, so
when you come back from the intent you see a "couldn't load the url" page
on the app.

I've tried to use the view.stopLoading() but it doesn't seem to stop it.
The issue only talks about the tel links, but I suppose that will happen
with sms, mailto and some other links.


So, I think a solution might be to move that code to
shouldOverrideUrlLoading function.

Is there any reason of doing this on the onPageStarted instead of using the
shouldOverrideUrlLoading?

Re: Does Cordova have a problem making developers happy?

[julio cesar sanchez]

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.









2015-04-09 0:02 GMT+02:00 Dmitry Blotsky :

> Here is a short thing I found recently on this topic:
> http://coenraets.org/keypoint/phonegap-performance/#0
>
> Kindly,
> - Dmitry
>
> -Original Message-
> From: Tyler Freeman [mailto:ty...@drumpants.com]
> Sent: Wednesday, April 8, 2015 1:12 PM
> To: dev@cordova.apache.org; Michael Brooks
> Subject: Re: Does Cordova have a problem making developers happy?
>
> I think what colors people's perception the most is the graphics and
> interaction performance of JS vs Native. Here's a few possible reasons:
>
> * They are basing their bias off Phonegap apps they saw 3 years ago. Even
> though it's improved so much since then, those first apps still hang in
> people's minds.
>
> * Developers are not trying hard enough for that smooth, buttery
> animations. It is possible to get 60fps on modern WebKit views, but it's
> hard and takes a lot of work.
>
> * For instance, I came across an article once that recommended using CSS
> transforms instead of properties like "left". That changed my whole way of
> thinking, and my app looks and reacts so much better because of it. I think
> it would be good for the Cordova docs to lay out tips like that for making
> top-notch apps.
>
> * Non-native feel and interactions. Some apps just port their iOS-style
> design straight to Android without considering that Android users expect a
> completely different paradigm. Not sure there's much to do about this.
>
> Tyler
>
> On April 8, 2015 9:42:00 AM PDT, Michael Brooks 
> wrote:
> >This is a really interesting survey. My take is that the score is low
> >because over 50% of the participants are Windows users and the default
> >Cordova experience on Windows is extremely unconventional - Git Bash,
> >Node.js Command Prompt, terminal command driven development, and no
> >full blown IDE. The Microsoft team is dramatically improving this and
> >as Visual Studio integration becomes more well known, I hope those
> >survey results improve.
> >
> >On Wed, Apr 8, 2015 at 9:08 AM, Toplak Daniel 
> >wrote:
> >
> >> Absolutely right :-)
> >>
> >> Cordova is too easy in some situations and most of the developers
> >using
> >> cordova (not the cordova developers itself) are knowing nothing about
> >the
> >> plugin system under the hood, or anything about the JS->Native->JS
> >bridge.
> >> They even don't know anything about the asynchronos communitcation
> >with
> >> plugins.
> >>
> >> In most situations this is absolutely ok, but if anything special is
> >> needed or something goes wrong,

Re: Does Cordova have a problem making developers happy?

[julio cesar sanchez]

Raymond, sorry for the j* ** part, I know you like it and write
about it.
The truth is I haven't tried the 1.4.5 version yet, I use 1.3.2 at work and
I don't feel it soo slow (I use fastClick too and we target android 4 or
greater)

Just was talking about the questions I read on stackoverflow and *most* of
the question where they say "my cordova app is slow" the say they are using
that framework, but of course they don't mention the device where they are
testing, the version of the framework or the android version. I've seen *a
few* question where they ask "my cordova app is slow and I'm using ionic
framework", it's not always the framework fault.



2015-04-09 15:52 GMT+02:00 Carlos Santana :

> Julio this is a great report/list of current state of dev ux for developers
> using cordova in what ever form.
>
> I would be sad if this list get's buried in the mailing list. I would like
> to have place in some place (i.e. google doc) to brain storm actions to
> improve on some of those items.
>
> At least for me I have being doing some thinking lately in this space.
>
> I think one things to me is that I would like to see cordova have zero
> friction to open collaboration.
>
> One small thing would be to go FULL usage of Github.
> We already have folks go there to submit PR anyway.
>
> 1. Use Github Issues
> Have folks use Github issues as the easiest and preferred way
> Backup/Archive  data on Apache using github web hooks to create
> corresponding jira items, and sync comments. we already doing this with
> mentions of jira CB-.
>
> Ability to have a more open conversation, even cross referencing other open
> source project that can collaborate with cordova like npm, react-native,
> etc.. to solve common problems once with open standards and open source.
>
> potential for using issues tags, for auto taggin pr with apache icla,
> questions, etc..
>
> 2. Use Github Wiki
> Use Github Wiki instead of wiki.apache.org/cordova. Easier to read, easier
> to find and read for users. Backup/Archive data on Apache using github web
> hooks, or some other automated process.
>
> 3. Use Github Pages
> Cordova.io already is built with jekyll. Easier to maintain and easier to
> atract people to help out on blogs, ages, Docs
> Backup/Archive data on Apache using github webhook or other automated
> process.
>
> 4. Simplify our message on cordova.io to hey! we do open source go to
> Github for everything.
>
> I'm not sure but the only rule that Apache imposes is that if Gihub decides
> to go down (;-p) or disappear the project can continue to work and data and
> history is preserved.
>
> Also what about if cordova decides to move out from Apache Foundation, to
> another open source Foundation? That should not affect the community they
> should still continue to interface in Github.
>
>
>
>
> On Thu, Apr 9, 2015 at 4:08 AM, Stef  wrote:
>
> > As a survey it's always biased.
> >
> > I've used Cordova since a long time before the 1.x. The problem is
> clearly
> > not about Cordova, but most developers don't understand this. They think
> > Cordova is like "build an awesome application in 21 days".
> > Clearly most of these guys don't know Javascript, the mobile web nor
> > anything relative to the mobile.
> >
> > There are really a lots of shitty mobile applications and most of them
> are
> > native :)
> >
> > --
> > Stéphane Bachelier,
> > Tél. 06 42 24 48 09
> > B8A5 2007 0004 CDE4 5210  2317 B58A 335B B5A4 BFC2
> >
> > 2015-04-09 9:35 GMT+02:00 José-Luc Voltaire <
> > jose-luc.volta...@netdevices.fr
> > >:
> >
> > > Hi,
> > >
> > > I am a developper and I use Cordova.
> > >
> > > I just wanted to say that even thought we don't know all the details
> > about
> > > how it works under the hood, we have, at least, an idea of the work
> done
> > > and appreciate it.
> > >
> > > I try to understand how the tools I use work and I don't think I am the
> > > only one.
> > >
> > > I'm agree with Tyler and I think mobile web apps can be as good as
> native
> > > ones, it requires a lot of work, and that's what I try to do for the
> > apps I
> > > work on!
> > >
> > > Again, Thank you for your work, we appreciate!
> > >
> > > 2015-04-08 22:12 GMT+02:00 Tyler Freeman :
> > >
> > > > I think what colors people's perception the most is the graphics and
> > > > interaction performance of JS vs Native. Here's a few possible
> reasons:
> > > >
> > > > * They are basing their bias off Phonegap apps they saw 3 years ago.
> > Even
> > > > though it's improved so much since then, those first apps still hang
> in
> > > > people's minds.
> > > >
> > > > * Developers are not trying hard enough for that smooth, buttery
> > > > animations. It is possible to get 60fps on modern WebKit views, but
> > it's
> > > > hard and takes a lot of work.
> > > >
> > > > * For instance, I came across an article once that recommended using
> > CSS
> > > > transforms instead of properties like "left". That changed my whole
> way
> > > of
> > > > thinking, and my

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

[julio cesar sanchez]

Google added official multi sim support on the latest version, not sure how
that affects to apps. I have a motorola moto g 2014 and it's dual sim (at
least the spanish model), let me know if you need me to test anything when
I receive the 5.1 version (I'm on 5.0.2 right now)

Re: Cleaning up Jira?

[julio cesar sanchez]

I have been looking on iOS bugs and there were a few that couldn't
reproduce. I closed one of them because the reporter confirmed that he
couldn't reproduce it anymore, but I'm still waiting for response on others.


El miércoles, 15 de abril de 2015, Andrew Grieve 
escribió:

> Any help with organizing our JIRA would be greatly appreciated! Bugs can
> always be re-opened, so I think you're fine to aggressively resolve them if
> they look to be no longer relevant.
>
> On Wed, Apr 15, 2015 at 12:57 PM, Murat Sutunc  >
> wrote:
>
> > Should we close resolved bugs such as
> > https://issues.apache.org/jira/browse/CB-3452 after a week or so? People
> > seem to report the bugs and don't reply back. If they decide to revisit
> > after a long period we can re-open bugs.
> >
> > -Original Message-
> > From: Joe Bowser [mailto:bows...@gmail.com ]
> > Sent: Wednesday, April 15, 2015 9:51 AM
> > To: dev@cordova.apache.org 
> > Subject: Re: Cleaning up Jira?
> >
> > Depends on the platform.  I'd say to delete the Android ones since I just
> > fixed it and tested it, but keep the one where I talk about refactoring
> it
> > to clean up the nasty nested threading thing that's going on here.  (It's
> > bad, I had to do bad, bad things to get that to work again.)
> >
> > Also, any time Cordova gets killed due to the camera using too much
> memory
> > on Android, mark that as Won't Fix.  It's the nature of Intents on
> earlier
> > versions of Android, and I haven't seen it happen on 4.4 or 5.x yet.
> That
> > said, I have to try and get some super low-end 5.x devices.  (I'm looking
> > at you Moto E)
> >
> > On Wed, Apr 15, 2015 at 9:48 AM Murat Sutunc  >
> > wrote:
> >
> > > Hey,
> > > I was looking at the camera bugs (201 of them atm!) and some of them
> > > look pretty stale. Is it ok to close the bugs that no longer repro on
> > > the latest version of platform/plugin? Or close bugs which are
> > > resolved as can't repro? I think it would be much better to have few
> > > but actionable bugs than 10s of stale ones :) Thoughts??
> > >
> > > Thanks,
> > > Murat
> > >
> >
>

Re: Proposal: Expose check_reqs at the CLI level

[julio cesar sanchez]

+1 to Josh, I think it should be possible to check even before you create a
project


El miércoles, 15 de abril de 2015, Josh Soref 
escribió:

> We already support:
>
> `cordova build android`
>
> There's no need for the extra `platform` verb..
>
> But,
> `cordova build android --nobuild` isn't any more intuitive than w/ the
> extra
> "platform".
>
>
> And yes, as I noted, and others have noted, we used to run check_reqs in
> add,
> we're not going back to doing that.
>
> A `cordova doctor` or `cordova requirements` verb seems fine.
>
> I'm also fine `cordova doctor PLATFORM` instead of `cordova platform doctor
> PLATFORM`,
>
> As for when someone is likely to want to ask "what requirements do I need
> for
> a platform", it's fairly arbitrary.
>
> Someone who is given a project might know that they don't have the
> environment
> for a platform, they aren't likely to want to go down a "build" rabbit
> hole,
> so, I'm -1 on hiding it anywhere near build.
>
> It's perfectly reasonable from my perspective for someone to want to run
> `cordova requirements PLATFORM` without a project at all.
> Imagine someone is getting started, they "install cordova", and know they
> want
> to develop for PLATFORM, they could reasonably want to set up their
> requirements for that platform before trying to create a project...
>
> I don't know if anyone's check_reqs scripts actually requires a project, I
> actually think they don't, so it's probably sufficient to run them straight
> from the platform origin instead of from a created project.
>
> One notable thing: check_reqs isn't a .js file yet, as an API, it's
> "check_reqs" (*nix) and "check_reqs" + something from %PATHEXT% (Windows)
>
> > -Original Message-
> > From: agri...@google.com  [mailto:agri...@google.com
> ] On Behalf Of
> > Andrew Grieve
> > Sent: Wednesday, April 15, 2015 11:00 AM
> > To: dev
> > Subject: Re: Proposal: Expose check_reqs at the CLI level
> >
> > We've worked to make iOS add'able from Windows, so I do think it's a good
> > idea to *not* run check_reqs from add (we used to but removed it).
> >
> > We already run it on build, so potentially we already have this command:
> > "cordova platform build android --nobuild"
> >
> >
> >
> > On Tue, Apr 14, 2015 at 9:51 PM, Treggiari, Leo  >
> > wrote:
> >
> > > My opinions.
> > >
> > > Q1.  Just say that platform is not added, so cannot check requirements.
> > >
> > > I don't think it is important to support the platform-not-added case.
> > >
> > > Q2.  Should the requirements be checked when a platform is added, or
> > when
> > > it is built ?
> > >
> > > 'platform add' should work even when the requirements are not met.  If
> > > requirements
> > > used to be checked on 'platform add', then I suspect they were removed
> to
> > > support
> > > the scenario of using the same Cordova project on multiple host
> platforms.
> > > E.g. a team with some developers on Windows and some on Mac.  As a user
> > of
> > > Cordova CLI on Windows, I want it to be OK to have the project I'm
> working
> > > on have the
> > > iOS platform added and I only get errors if I try to do something
> (build,
> > > emulate)
> > > which requires the native SDK.
> > >
> > > Leo
> > >
> > > -Original Message-
> > > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com
> ]
> > > Sent: Tuesday, April 14, 2015 6:04 PM
> > > To: dev@cordova.apache.org 
> > > Subject: RE: Proposal: Expose check_reqs at the CLI level
> > >
> > > I think you raise an interesting point on the behavior of check_reqs
> for
> > > platform that are not yet added.
> > >
> > > The options, as you mention are
> > >
> > > Question 1
> > > 1 -  Add the platform, run check_reqs script, remove the platform and
> > > report results.
> > > 1.5 - Just download the check_reqs script (or use it from the cached
> > > platform directory) without adding the platform, and run that.
> > > 2 -  Just say that platform is not added, so cannot check requirements.
> > >
> > > Question 2: It also comes to the case of - when would a user want to
> run
> > > the requirement check
> > > - before starting a cordova project ?
> > > - before adding a platform ?
> > > - should the requirements be checked when a platform is added, or when
> it
> > > is built ?
> > >
> > > The answer to the above questions will help us understand if a top
> level
> > > req_check is required or not. We should also look at what check_reqs do
> > > today - the do not tell you ALL the missing pieces for building an SDK.
> > >
> > > It would be good to hear what the others in the community think about
> > > these answers.
> > >
> > > -Original Message-
> > > From: Josh Soref [mailto:jso...@blackberry.com ]
> > > Sent: Tuesday, April 14, 2015 9:55 AM
> > > To: dev@cordova.apache.org 
> > > Subject: RE: Proposal: Expose check_reqs at the CLI level
> > >
> > > Fwiw, for the case of a platform that isn't in a project yet, I'd
> > > envision:
> > >
> > > `cordova platform doctor not-yet-in

[iOS] can somebody reproduce this bug?

[julio cesar sanchez]

Hi,
Can somebody see this issue and try to reproduce it on an iOS 8.1 or 8.2
device?
https://issues.apache.org/jira/browse/CB-7734

shazron says he can't reproduce it

Re: [PROPOSAL] Update Cordova iOS Platform Xcode Compatibility

[julio cesar sanchez]

+1

note that maybe it's not clear, but we would remove Xcode 10 support as
using the Xcode 11 structure will make apps incompatible with previous
Xcode versions.

Dropping Xcode 10 support can also simplify some plugins code that have
additional code macros to work on Xcode 10 at the moment.


El lun., 10 feb. 2020 a las 14:54, Bryan Ellis ()
escribió:

> I accidentally clicked on the send button before adding the PR link that I
> already submitted.
>
> https://github.com/apache/cordova-ios/pull/780
>
> I also *+1* for setting the "*Project Format*" to "*Xcode 11-compatible*"
>
>
> On Mon, Feb 10, 2020 at 10:51 PM Bryan Ellis  wrote:
>
> > I would like to open the discussion and vote to *update the Cordova iOS
> > Xcode "Project Format" setting to Xcode 11-compatible* for the upcoming
> > next major release.
> >
> > I have already created a PR that performs the changes but would like to
> > get feedback from others regarding this change in general and maybe a
> > review.
> >
> > One of the major reasons for this change is to conform with the *App
> > Store Submission[1]* guidelines:
> >
> > Starting April, 2020, all apps submitted to the App Store will need to be
> > built with Xcode 11. Xcode 11 requires macOS Mojave 10.14.3 or later.
> >
> >
> > Additionally,
> >
> > This change would modernize our default project template, CordovaLib, and
> > as well as the testing fixtures.
> >
> > And also, quoted from Apple's *WWDC 2019 Video[2]*
> >
> > Keeping your project file modern is a critical way to make sure that
> Xcode
> > can help you out and avoids the accumulation of issues.
> > First, when you're updating to a new version of Xcode, you'll be offered
> > the opportunity sometimes to have Xcode update the project settings and
> > update your project file to the latest format.
> >
> >
> > *Reference Links*
> > *App Store Submission*
> > [1] https://developer.apple.com/app-store/submissions/
> >
> > *WWDC 2019 Video*
> > [2] https://developer.apple.com/videos/play/wwdc2019/239/
> >
>

Re: Looking for guidance to contribute Cordova

[julio cesar sanchez]

Hello,

Welcome to the cordova dev list.

I don’t think any Cordova PMC applied to GSOC to be a mentor, so if Apache
appears as organization is probably from other projects. Not sure if people
from other projects can be mentors for Cordova.

But you don’t need to be on GSOC to contribute to Cordova, you can just
start contributing by sending pull request to any of the Cordova
repositories (https://github.com/apache?utf8=✓&q=cordova-)
You can check the contribution guidelines here
https://cordova.apache.org/contribute/contribute_guidelines.html

Even if you don’t have a dedicated mentor, you can ask any question here on
the dev list and we will try to help you.


El sábado, 15 de febrero de 2020, Bhathiya Mihiran 
escribió:

> Hello,
> I'm Bhathiya Mihiran, a final year undergraduate student pursuing BSc in
> Information Systems from University of Colombo School of Computing who
> interested to do GSOC.  I have some experience in mobile app development
> and web application development
> I went through some projects of apache and I found interested in Apache
> Cordova as it related to my technical stack. Therefore I decided to
> contribute to the Cordova.
> So I would like to request for guidance to contribute for the Cordova.
> Thank you!!
>

Re: Statusbar Plugin Release?

[julio cesar sanchez]

The idea was to integrate it into the platforms, but we can probably leave
that out for next major releases (next year releases).
The plugin would need a major release because we removed the deprecated
platforms.

There are a few pending PRs that should be merged before doing the release.

El vie., 20 mar. 2020 a las 16:31, Niklas Merz ()
escribió:

> Hello everyone,
>
> Currently I am struggeling with a statusbar issue. There is a fix in
> master [1] and now I am wondering if we plan to do a release for this
> plugin.
>
> I am not sure but are there any plans to deprecate this plugin or
> something? There is something in my head but I can't remember exactly.
> Sorry for asking.
>
> Thanks and kind regards
> Niklas
>
> [1]
> https://github.com/apache/cordova-plugin-statusbar/commit/7d5d067f0391a9b07fae2ea89de818d0f2247527
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Statusbar Plugin Release?

[julio cesar sanchez]

I already mentioned it

"The plugin would need a major release because we removed the deprecated
platforms."

I think removing platforms, despite they are deprecated, is a breaking
change. At least in other plugins we did a major release after that.

El vie., 20 mar. 2020 a las 19:22, Chris Brody ()
escribió:

> Can you remind forgetful people like me what would trigger a major release
> here?
>
> It would be ideal to make a minor with bug fixes first but I suspect this
> would not be worth anyone’s time.
>
> On Fri, Mar 20, 2020 at 2:08 PM Niklas Merz  wrote:
>
> > Good. I will have a look in the next few days. Triage PRs and try to
> > prepare a major.
> >
> > Am 20. März 2020, 17:01, um 17:01, Chris Brody 
> > schrieb:
> > >+1 for making the release if we can get some of the more important PRs
> > >merged soon.
> > >
> > >We do have discussions of deprecating plugins but I think they are not
> > >really solid plans yet.
> > >
> > >
> > >On Fri, Mar 20, 2020 at 11:42 AM julio cesar sanchez
> > >
> > >wrote:
> > >
> > >> The idea was to integrate it into the platforms, but we can probably
> > >leave
> > >> that out for next major releases (next year releases).
> > >> The plugin would need a major release because we removed the
> > >deprecated
> > >> platforms.
> > >>
> > >> There are a few pending PRs that should be merged before doing the
> > >release.
> > >>
> > >> El vie., 20 mar. 2020 a las 16:31, Niklas Merz
> > >()
> > >> escribió:
> > >>
> > >> > Hello everyone,
> > >> >
> > >> > Currently I am struggeling with a statusbar issue. There is a fix
> > >in
> > >> > master [1] and now I am wondering if we plan to do a release for
> > >this
> > >> > plugin.
> > >> >
> > >> > I am not sure but are there any plans to deprecate this plugin or
> > >> > something? There is something in my head but I can't remember
> > >exactly.
> > >> > Sorry for asking.
> > >> >
> > >> > Thanks and kind regards
> > >> > Niklas
> > >> >
> > >> > [1]
> > >> >
> > >>
> > >
> >
> https://github.com/apache/cordova-plugin-statusbar/commit/7d5d067f0391a9b07fae2ea89de818d0f2247527
> > >> >
> > >> >
> > >-
> > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >> >
> > >> >
> > >>
> >
> --
> Sent from my mobile
>

Re: UiwebView deprecated issue for my App

[julio cesar sanchez]

There is also an entry about it on the Apache cordova blog

https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html

But as Chris said, doesn’t look like you did any research, if you google “
*ITMS-90809”* (the error you get when you submit the app),  the first
result is the ionic blog post he linked.


El miércoles, 1 de abril de 2020, Chris Brody 
escribió:

> The answer is already documented. We would really appreciate it if users
> could a little more research since maintainers are generally overloaded,
> especially while they are busy with a new major release.
>
> That said, here is a recommended link that I found from a quick search:
> https://ionicframework.com/blog/understanding-itms-90809-
> uiwebview-api-deprecation/
>
> I do think our documentation could use some improvement, and it has already
> been sponsored by an anonymous donor:
> https://github.com/apache/cordova-docs/issues/1057
>
>
> On Tue, Mar 31, 2020 at 8:48 PM Jesse  wrote:
>
> > Hi Binay,
> >
> > This list is for development of Apache Cordova itself.  For issues using
> > Apache Cordova in your app, your best bet is either via our slack channel
> > [1]
> > or stack overflow [2]
> > That said, it sounds like Ionic support might be a better option for your
> > issue.
> >
> > Cheers,
> >   Jesse
> >
> >
> > [1] https://slack-cordova-io.herokuapp.com/
> > [2] https://stackoverflow.com/questions/tagged/cordova
> >
> > On Tue, Mar 31, 2020 at 5:40 PM Binay Prabhakar 
> > wrote:
> >
> > > Hi Corodova Team,
> > > Six month back when I started working on Ionic App I was Very excited
> > > about it.
> > > But things are not smooth since few weeks.
> > > When I uploaded my app to test flight there were UI Web View
> depreciated
> > > warning came to me.
> > > To solve it i have migrated the app to Ionic 5 with a hope that this
> > issue
> > > will be solved.
> > > But sad part is that still Apple gave the same warning of Ui
> > depreciation.
> > > Can you please help me on this!
> > > Tried everything..Even created sample ionic project in ionic 5 and
> tried
> > > to build it but in ios code what I can see is there are references of
> > > UiwebView.
> > > Any proper blog will be helpful if you can suggest.
> > >
> > >
> > > Get Outlook for Android
> > >
> >
>

Re: Frustration with Cordova documentation

[julio cesar sanchez]

Maybe we should add the error code on the blog entry (*ITMS-90809*), that
way people can end up on the blog when searching about. Right now first
entry is the ionic blog, I checked 5 pages and didn’t find anything cordova
specific.

El miércoles, 1 de abril de 2020, Niklas Merz 
escribió:

> I think there is good documentation for this particular problem. I wrote a
> blog post {1} just two weeks ago to summarize it now that Apple is
> enforcing it. Most people just don't research properly and just ask and we
> can't do anything about it.
>
> But yes we really should get this money for better docs used now. I just
> don't know how to get this going. I guess we need to find a technical
> writer/developer capable of doing it.
>
> {1} https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html
>
> April 1, 2020 2:58 AM, "Chris Brody"  wrote:
>
> > Improvement has already been sponsored by an anonymous donor. Repeated
> > requests for help with getting it started have been met with no response
> so
> > far. I think this recent thread is an example of how our documentation
> > could use some improvement:
> >
> > https://lists.apache.org/thread.html/r261aa09ef8e4b0d47ceda731d38a5
> 8204186d544528b07c27898c000@ > ordova.apache.org>
> >
> > I sincerely hope I am just missing something here, would love to get the
> > ball rolling in the near future.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

[julio cesar sanchez]

I'm -1 for the stale bot, I've seen in other repos and it just ends closing
valid issues and PRs because the maintainers didn't have time to look into
them, but that's maintainers "fault" and I think it "punish" users.

I'm +1 for the other ones.

El vie., 17 abr. 2020 a las 12:43, Bryan Ellis ()
escribió:

> I forgot to link PR:
>
> https://github.com/apache/cordova/pull/210
>
> This PR contains the configurations for the apps described previously.
>
>
> On Fri, Apr 17, 2020 at 7:42 PM Bryan Ellis  wrote:
>
> > I would like to better improve our GitHub issue tracker by adding some of
> > the Probot apps that can be installed to GitHub.
> >
> >
> > There are many available apps and I wanted to start off with a selected
> > few that would help mitigate some of the tedious tasks.
> >
> > The apps I would like to bring up in this discussion and to vote on are:
> >
> >- Stale
> >- Request Info
> >- Lock Threads
> >- No Response
> >
> >
> > The "*Stale*" app is used to automatically close issues and prs which
> > have no activity over a period of time. This app provides a lot of
> > configuration flexibility. We can warn users after x number of days that
> > the issue/pr has become stale and append a stale label. After x number of
> > days being stale, then the app will close the issue/pr. We can ensure
> that
> > the issues and prs are not closed immediately and provide users ample
> time
> > to reply back.
> >
> >
> > The "*Request Info*" app is used to automatically alert users when they
> > have created a new issue or pr that does not have any description. The
> app
> > will inform them that they will need to provide information for use to be
> > able to help them. One of the great things about this app is that it can
> > also check against our templates. If a user has submitted an issue or pr
> > with only the default template, it will also fail the check.
> >
> >
> > The "*No Response*" app is used to automatically close issues that have
> > not received a response from the author. This app pairs nicely with the
> > "request-info" app which manages the warning and label pinning. This app,
> > on the other hand, does not support PRs as the "request-info" also
> > supports. This means we will need to manually manage PRs in the meantime
> > while we wait for the app to be updated.
> >
> >
> > The "*Lock Threads*" app is used to lock the threads of closed issues or
> > prs after (x) number of days of inactivity. This is to help prevent
> > long-lived issues and prs after being resolved and closed. If a user
> still
> > has issues to report after the thread of an issue or PR is locked, they
> > should create a new issue. The locking of the thread does not occur
> > immediately after an issue or PR is closed. Users can still have an
> > opportunity to communicate if they feel the issue was closed prematurely.
> >
> >
> > Here is an example of PR to configure and use the bots. Obviously, I
> would
> > also need to enable the bot on each repo.
> >
> >
> > Please let me know what is your thoughts on this and even make a vote on
> > it. I would like to move forward and start using the power of the apps
> that
> > can be installed.
> >
> >
> > Here is the general process based on the configurations in the PR.
> >
> >
> > *For proper Issues & PRs*
> >
> >- After 2 months of no activity, the issue/pr will become stale and
> >the thread will be warned. A "stale" label is appended.
> >- After 2 weeks of being stale, and continues to have no activity, the
> >issue/pr is closed.
> >- After 2 weeks of being closed, and continues to have no activity,
> >the issue/pr thread will become locked.
> >
> >
> > In total, this process covers ~3 months. (88 days exactly). After being
> > flagged stale, users have still enough time to create an activity to
> > prevent the app from closing and locking the thread.
> >
> >
> > Additionally, I have also declared labels of "security" and "pinned" to
> be
> > ignored by the app so it will never go stale.
> >
> >
> > *For issues & PRs that have no description or matches the template.*
> >
> >- Shortly after the submission of a bad issue or pr, the app will post
> >a warning that information must be provided. Also, "info-needed"
> label is
> >applied
> >- After 4 days of no response, the bot will close the issue. (PR will
> >need to be manually managed for now)
> >- After 2 weeks of being closed, and continues to have no activity,
> >the issue/pr thread will become locked.
> >
> >
> > In total, this process covers ~18 days. The author of the ticket will
> have
> > enough time to correct the issue before the app closes and locks the
> thread.
> >
> >
> > If we have enough votes for this, what I will do is merge in the PR and
> > then do a mass deploy to all repos. I will also enable the bots to each
> > repo.
> >
> > Please provide a vote on this as well.
> >
> >
> >
>

Re: vote: PR merge convention

[julio cesar sanchez]

Just a reminder that we agreed on using the squash and merge, but I still
see regular merge commits in a few repos from time to time.

El El sáb, 5 oct 2019 a las 19:32, gandhi rajan 
escribió:

> + 1 for squash and merge as it makes the repo history cleaner.
>
> On Sat, Oct 5, 2019 at 8:34 PM  wrote:
>
> > +1 for "Squash and merge" as the default strategy
> >
> > Regarding "Create a merge commit":
> > At times, I find this option valuable too. Consider a PR that cleans up a
> > test suite. As part of that cleanup I might re-order the test cases. As
> > re-ordering produces a noisy diff, I usually isolate it in its own
> commit.
> > I would not want to merge this commit with the others as that would lead
> to
> > a commit with a very incomprehensible diff. So in this case I would favor
> > leaving the commits separate and doing an actual merge to group them
> > together in the global history.
> >
> > Am Fr., 4. Okt. 2019 um 17:03 Uhr schrieb julio cesar sanchez <
> > jcesarmob...@gmail.com>:
> >
> > > Sorry if it wasn't clear, I said I was leaving the protecting master
> > branch
> > > out of the vote.
> > >
> > > Looks like we all agree on using "Squash and merge" as default, unless
> it
> > > makes more sense to use one of the other options.
> > >
> > > El jue., 3 oct. 2019 a las 3:43, Bryan Ellis ()
> > > escribió:
> > >
> > > > -1 for protected master branches.
> > > > Protecting a branch is a great idea except it does not work with our
> > > > current workflow process. COHO commits directly onto the master
> branch
> > > for
> > > > releases. We would have to spend more time planning and changing our
> > > entire
> > > > current workflow process to eliminate direct commits if we wanted to
> > > > protect branches. There is alternative such keeping master open for
> > > direct
> > > > commits and development while creating a protected "production"
> branch.
> > > > Anyways this part of the discussion is off-topic and could be another
> > > > discussion... Anyways, stated above I am downvoting protected
> branches
> > > for
> > > > now.
> > > >
> > > > +1 for "Squash and merge"
> > > > Makes a nice single commit with the PR number and without the extra
> > merge
> > > > commit.
> > > >
> > > > +1 for "Rebase and merge"
> > > > There are use cases where this can work perfectly.
> > > > For example, Cordova-Electron has a `draft-2.0.0` branch which is
> > > targeting
> > > > the next major release. Major PRs were merged into that branch with
> > > "Squash
> > > > and merge". This means all PRs have nice PR# information in the
> title.
> > > > A PR will later be created to merge this branch onto master. "Rebase
> > and
> > > > merge" will be used and will not create the merge commit message and
> > will
> > > > not squash.
> > > >
> > > > -1 for "Create a merge commit"
> > > > Not in favor of the extra merge commit. I think in most cases one PR
> > > should
> > > > focus on one task so that means it could be squashed when there are
> > > > multiple commits. If "Create a merge commit" is used, each commit
> will
> > be
> > > > merged and does not contain the PR# in the title. When creating
> release
> > > > notes, I need to manually review those commits to identify what PR it
> > > came
> > > > from to include the PR linking. Some times, depending on if they are
> > all
> > > > related commits, I need to manually group them and create a
> meaningful
> > > > title for the release notes which I would prefer to have been done
> > > > beforehand.
> > > >
> > > >
> > > > On Wed, Oct 2, 2019 at 12:51 AM Jesse 
> wrote:
> > > >
> > > > > -1 for protected master branches, we are a small group of
> committers
> > > and
> > > > > don't need rules to keep us honest.
> > > > > Protecting master would involve infra, as we cannot manage the
> > minutia
> > > in
> > > > > github.  I think we all do this anyway except for rare occasions.
> > > > >
> > > > > +1 for squash and merge, as long as the meaningful individual
> commit
>

Re: vote: PR merge convention

[julio cesar sanchez]

It’s not just you Jesse, there are a few in a few repos from different
people. Didn’t mean to attack you, just wanted to remind it as we all agreed

El El sáb, 2 may 2020 a las 20:41, Jesse  escribió:

> I made a mistake, no need to create laws or rules.
>
> > On May 2, 2020, at 11:21 AM, Tim Brust  wrote:
> >
> > +1 to Niklas suggestion :)
> >
> > Sent from my iPhone
> >
> >>> On 2. May 2020, at 6:54 PM, Niklas Merz  wrote:
> >>>
> >>> We could try to enforce this setting with .asf.yml. I saw this posted
> on another list.
> >>>
> >>> See:
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
> >>>
> >>> Should we roll this out to all repos?
> >>>
> >>> May 2, 2020 1:38 PM, "julio cesar sanchez" 
> wrote:
> >>>
> >>> Just a reminder that we agreed on using the squash and merge, but I
> still
> >>> see regular merge commits in a few repos from time to time.
> >>>
> >>>> El El sáb, 5 oct 2019 a las 19:32, gandhi rajan <
> gandhiraja...@gmail.com>
> >>>> escribió:
> >>>>
> >>>> + 1 for squash and merge as it makes the repo history cleaner.
> >>>>
> >>>>> On Sat, Oct 5, 2019 at 8:34 PM  wrote:
> >>>>
> >>>> +1 for "Squash and merge" as the default strategy
> >>>>
> >>>> Regarding "Create a merge commit":
> >>>> At times, I find this option valuable too. Consider a PR that cleans
> up a
> >>>> test suite. As part of that cleanup I might re-order the test cases.
> As
> >>>> re-ordering produces a noisy diff, I usually isolate it in its own
> >>>> commit.
> >>>> I would not want to merge this commit with the others as that would
> lead
> >>>> to
> >>>> a commit with a very incomprehensible diff. So in this case I would
> favor
> >>>> leaving the commits separate and doing an actual merge to group them
> >>>> together in the global history.
> >>>>
> >>>> Am Fr., 4. Okt. 2019 um 17:03 Uhr schrieb julio cesar sanchez <
> >>>> jcesarmob...@gmail.com>:
> >>>>
> >>>>> Sorry if it wasn't clear, I said I was leaving the protecting master
> >>>> branch
> >>>>> out of the vote.
> >>>>>
> >>>>> Looks like we all agree on using "Squash and merge" as default,
> unless
> >>>> it
> >>>>> makes more sense to use one of the other options.
> >>>>>
> >>>>> El jue., 3 oct. 2019 a las 3:43, Bryan Ellis ()
> >>>>> escribió:
> >>>>>
> >>>>>> -1 for protected master branches.
> >>>>>> Protecting a branch is a great idea except it does not work with our
> >>>>>> current workflow process. COHO commits directly onto the master
> >>>> branch
> >>>>> for
> >>>>>> releases. We would have to spend more time planning and changing our
> >>>>> entire
> >>>>>> current workflow process to eliminate direct commits if we wanted to
> >>>>>> protect branches. There is alternative such keeping master open for
> >>>>> direct
> >>>>>> commits and development while creating a protected "production"
> >>>> branch.
> >>>>>> Anyways this part of the discussion is off-topic and could be
> another
> >>>>>> discussion... Anyways, stated above I am downvoting protected
> >>>> branches
> >>>>> for
> >>>>>> now.
> >>>>>>
> >>>>>> +1 for "Squash and merge"
> >>>>>> Makes a nice single commit with the PR number and without the extra
> >>>> merge
> >>>>>> commit.
> >>>>>>
> >>>>>> +1 for "Rebase and merge"
> >>>>>> There are use cases where this can work perfectly.
> >>>>>> For example, Cordova-Electron has a `draft-2.0.0` branch which is
> >>>>> targeting
> >>>>>> the next major release. Major PRs were merged into that branch with
> >>>>> "Squash
> >>>>&g

Re: [Discuss] Cordova plugin camera release 4.2.0

[julio cesar sanchez]

I've just noticed that
https://github.com/apache/cordova-plugin-camera/pull/588 totally breaks
camera plugin, so we can't release 4.2.0. My bad as I accepted it without
testing on a real device as it looked like a harmless change.


El jue., 7 may. 2020 a las 22:13, Jesse ()
escribió:

> I have closed the vote for Camera-4.2.0
> I will sort out my signing keys and restart tonight.
>
> On Sun, May 3, 2020 at 11:08 PM Jesse  wrote:
>
> > Does anyone have any reason to delay a cordova-plugin-camera release?
> > Any outstanding patches to land?
> >
> > If not, I will start the release soon.
> >
> > (CI is currently green)
> >
>

Re: Request to add to dev mailing list

[julio cesar sanchez]

All the cordova mail lists and instructions about how to subscribe can be
found at
https://cordova.apache.org/contact/

El El mié, 13 may 2020 a las 21:09, Jesse 
escribió:

> Welcome Devendra,
>
> If you would like more info on contributing, there is a ton of info here:
> https://cordova.apache.org/contribute/contribute_guidelines.html
> As well, I believe those on this list would be supportive if you have
> questions, or need help contributing.
>
> That said, please remember that this list is specifically for developing
> Apache Cordova, and is not a community support forum for apps built with
> Cordova.
> The  #slack community is a great place to ask and answer questions as well.
> http://slack.cordova.io/
>
> Cheers,
>   Jesse
>
> On Wed, May 13, 2020 at 12:01 PM Devendra Khatri 
> wrote:
>
> > Hello,
> >
> > I have been working on cordova platform for past 3-4 years, I Keep
> reading
> > blogs about the platform to keep our product stable. I came across this
> > listing recently, If you can add me in the listing !
> >
> > Also, let me know If I need to know any thing else here !!
> >
> > Thanks
> > Devendra
> >
>

the future of cordova-plugin-wkwebview-engine

[julio cesar sanchez]

we should discuss about what's going to happen
with cordova-plugin-wkwebview-engine

cordova-ios 6 is coming soon and it uses WKWebView, but it uses a custom
scheme to serve the app content instead of serving from file protocol.
some people prefers file over the custom scheme,
but cordova-plugin-wkwebview-engine will not work in cordova-ios 6 because
of some breaking changes introduced.

So, should we

a) continue maintaining cordova-plugin-wkwebview-engine and fix it to work
on cordova-ios 6?
b) modify cordova-ios 6 to allow both file and custom scheme and then
sunset cordova-plugin-wkwebview-engine?
c) do nothing and tell people who want to use file protocol to stick with
cordova-ios 5.1.1?
d) other option I didn't think of (please, describe)

Re: the future of cordova-plugin-wkwebview-engine

[julio cesar sanchez]

The data lost is not the topic and I don’t think it’s our duty to avoid it
(but we have to document it and mention it on the release notes). For users
concerned about that, there are plugins available (will probably need some
changes because they were created for the ionic plugin).

There are a few more problems with the custom schemes, I don’t remember
them all, but it comes to my head that playing big video files in the video
tag takes a lot of memory and we can’t send the data in chunks because
there are no request headers (I reported it to Apple long ago and it’s not
fixed yet). That doesn’t happen when the video is served from file protocol.

El jueves, 21 de mayo de 2020, Norman Breau 
escribió:

> The only real advantage of using the file protocol is to maintain
> backwards compatibility I think. Other than that, it contains a lot of
> disadvantages, as the webview disables/restricts a lot of browser features
> while on the file protocol, including using XHR to fetch local resources,
> which makes using web frameworks hard to use, such as angular, which
> heavily uses XHR for fetching templates, and is a common source of
> wkwebview related bug reports.
>
> I've just recently migrated an app from UIWebView to the ionic webview,
> which included migrating local storage data that was extremely important
> for us to keep, and that wasn't too difficult to do. It was just simply
> renaming a sqlite database file. So if the primary concern is the protocol
> change causing lost of data (because change of origin), it might be
> possible to write migratory code. I don't know if migrating
> cookies/indexDB/other storage tech is as easy as migrating local storage
> though, I don't use that browser tech, didn't pay attention to it. This
> would obviously delay the cordova-ios@6 release, but would allow us to
> sunset the wkwebview-engine plugin.
>
> On 2020-05-21 1:45 p.m., Michael Gatto wrote:
>
>> Hi,
>>
>> What exactly are the advantages to serving with the file protocol if
>> Cordova doesn't need to?
>>
>> FWIW, I was never able to get WKWebView working without the additional
>> XHR plugin, so serving from file holds no obvious advantage for me, at
>> least.
>>
>> --
>> Michael Gatto
>>
>> ___
>> Michael Gatto · Senior Software Engineer · vinSUITE
>> o: 707-253-7400 e: mga...@vinsuite.com
>> vinsuite <https://www.vinsuite.com/> · twitter  <
>> https://twitter.com/vinsuite>· facebook  <https://www.facebook.com/vinS
>> UITEsoftware/>· linkedin <https://www.linkedin.com/company/vinsuite/>
>>   You sell wine. We make it easier.
>> Top 5 Tasting Room Survey Takeaways - Watch Now! <
>> https://go.vinsuite.com/watch-CellarPass-webinar>
>>
>> On 5/21/20, 9:18 AM, "julio cesar sanchez" 
>> wrote:
>>
>>  we should discuss about what's going to happen
>>  with cordova-plugin-wkwebview-engine
>>   cordova-ios 6 is coming soon and it uses WKWebView, but it uses
>> a custom
>>  scheme to serve the app content instead of serving from file
>> protocol.
>>  some people prefers file over the custom scheme,
>>  but cordova-plugin-wkwebview-engine will not work in cordova-ios 6
>> because
>>  of some breaking changes introduced.
>>   So, should we
>>   a) continue maintaining cordova-plugin-wkwebview-engine and
>> fix it to work
>>  on cordova-ios 6?
>>  b) modify cordova-ios 6 to allow both file and custom scheme and then
>>  sunset cordova-plugin-wkwebview-engine?
>>  c) do nothing and tell people who want to use file protocol to stick
>> with
>>  cordova-ios 5.1.1?
>>  d) other option I didn't think of (please, describe)
>>
>>
>> -
>> 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: Strongly deprecating the FileTransfer plugin

[julio cesar sanchez]

This happens with all the deprecated plugins we have, people keeps
reporting issues on them.
I proposed long ago to archive them, but some people was against it, but I
think archiving is the way to go when something is deprecated.


El miércoles, 3 de junio de 2020, Jesse  escribió:

> +1 The deprecation notice needs to be prominent, I missed it myself on a
> quick scroll.
> Some of that readme is in a specific format to support appearance in
> docs.cordova.io ( similar to
> https://cordova.apache.org/docs/en/latest/reference/
> cordova-plugin-file/index.html
>  )
> This is no longer a requirement, so we can go prominent.
> We should also ask INFRA to put the text [DEPRECATED] in the description,
> and possibly even archive the repo.
>
>
> On Wed, Jun 3, 2020 at 12:02 PM Norman Breau 
> wrote:
>
> > I'm sure you're not the only one who misses it, considering the repo is
> > still pretty active in terms of new issues being reported.
> >
> > On 2020-06-03 3:59 p.m., Darryl Pogue wrote:
> > > Correction: There is in fact a deprecation notice, part-way down the
> > > README, but it's not especially attention grabbing and I missed it the
> > > first 2 times I skimmed the file.
> > >
> > > On Wed, Jun 3, 2020 at 11:55 AM Darryl Pogue  wrote:
> > >
> > >> Hey folks,
> > >>
> > >> The File Transfer plugin has been officially deprecated since 2017:
> > >>
> > https://cordova.apache.org/blog/2017/10/18/from-
> filetransfer-to-xhr2.html
> > >>
> > >> However, the repo and npm have no link to that page or any sort of
> > >> indication that it is not maintained.
> > >>
> > >> With the release of cordova-ios 6, the FileTransfer plugin no longer
> > >> compiles on iOS:
> > >> https://github.com/apache/cordova-plugin-file-transfer/issues/258
> > >>
> > >> I want to reply to that issue saying that it's deprecated and not
> > >> maintained, but I feel like we haven't made that very clear.
> > >>
> > >> I would like to propose that we update the README for File Transfer
> > with a
> > >> clear deprecation notice which links to the blog post from 2017, and
> > that
> > >> we ask ASF Infra to mark the repo as archived.
> > >>
> > >> Any objections?
> > >>
> > >> ~Darryl
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Strongly deprecating the FileTransfer plugin

[julio cesar sanchez]

I think people knew they were leaving the project and voted to deprecate
plugins to leave less things to maintain to the few remaining people.

Since there are new committers now that didn’t vote, maybe we can
reconsider/re vote.



El miércoles, 3 de junio de 2020, Darryl Pogue 
escribió:

> Not that we want to outright endorse 3rd party plugins without due
> diligence, but there are other options than the FileTransfer plugin, such
> as https://www.npmjs.com/package/cordova-plugin-advanced-http
>
> On Wed, Jun 3, 2020 at 1:46 PM Tim Brust  wrote:
>
> > While I agree that we should somehow archive old code, I'm still -1 on a
> > deprecation of this plugin. (We've had some discussion about it here,
> too:
> > https://github.com/apache/cordova/issues/185)
> > XHR is not reliable and causes OOM errors when handling large data.
> >
> >
> >
> > On Wed, Jun 3, 2020 at 7:29 PM Norman Breau 
> > wrote:
> >
> > > +1 on archiving/adding  [DEPRECATED] text in the description.
> > >
> > > On 2020-06-03 4:25 p.m., julio cesar sanchez wrote:
> > > > This happens with all the deprecated plugins we have, people keeps
> > > > reporting issues on them.
> > > > I proposed long ago to archive them, but some people was against it,
> > but
> > > I
> > > > think archiving is the way to go when something is deprecated.
> > > >
> > > >
> > > > El miércoles, 3 de junio de 2020, Jesse 
> > > escribió:
> > > >
> > > >> +1 The deprecation notice needs to be prominent, I missed it myself
> > on a
> > > >> quick scroll.
> > > >> Some of that readme is in a specific format to support appearance in
> > > >> docs.cordova.io ( similar to
> > > >> https://cordova.apache.org/docs/en/latest/reference/
> > > >> cordova-plugin-file/index.html
> > > >>   )
> > > >> This is no longer a requirement, so we can go prominent.
> > > >> We should also ask INFRA to put the text [DEPRECATED] in the
> > > description,
> > > >> and possibly even archive the repo.
> > > >>
> > > >>
> > > >> On Wed, Jun 3, 2020 at 12:02 PM Norman Breau <
> nor...@normanbreau.com>
> > > >> wrote:
> > > >>
> > > >>> I'm sure you're not the only one who misses it, considering the
> repo
> > is
> > > >>> still pretty active in terms of new issues being reported.
> > > >>>
> > > >>> On 2020-06-03 3:59 p.m., Darryl Pogue wrote:
> > > >>>> Correction: There is in fact a deprecation notice, part-way down
> the
> > > >>>> README, but it's not especially attention grabbing and I missed it
> > the
> > > >>>> first 2 times I skimmed the file.
> > > >>>>
> > > >>>> On Wed, Jun 3, 2020 at 11:55 AM Darryl Pogue 
> > > wrote:
> > > >>>>
> > > >>>>> Hey folks,
> > > >>>>>
> > > >>>>> The File Transfer plugin has been officially deprecated since
> 2017:
> > > >>>>>
> > > >>> https://cordova.apache.org/blog/2017/10/18/from-
> > > >> filetransfer-to-xhr2.html
> > > >>>>> However, the repo and npm have no link to that page or any sort
> of
> > > >>>>> indication that it is not maintained.
> > > >>>>>
> > > >>>>> With the release of cordova-ios 6, the FileTransfer plugin no
> > longer
> > > >>>>> compiles on iOS:
> > > >>>>> https://github.com/apache/cordova-plugin-file-transfer/
> issues/258
> > > >>>>>
> > > >>>>> I want to reply to that issue saying that it's deprecated and not
> > > >>>>> maintained, but I feel like we haven't made that very clear.
> > > >>>>>
> > > >>>>> I would like to propose that we update the README for File
> Transfer
> > > >>> with a
> > > >>>>> clear deprecation notice which links to the blog post from 2017,
> > and
> > > >>> that
> > > >>>>> we ask ASF Infra to mark the repo as archived.
> > > >>>>>
> > > >>>>> Any objections?
> > > >>>>>
> > > >>>>> ~Darryl
> > > >>>>>
> > > >>> 
> -
> > > >>> 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
> > >
> > >
> >
> > --
> > Tim Brust
> > timbrust3...@gmail.com
> >
> > M: +49 160 9757 3632 <+4916097573632>
> >
>

Re: [DISCUSS] InAppBrowser 4.0.0 major release

[julio cesar sanchez]

As far as I know, the versions are the minimum required to work, not the
minimum supported by the plugin.

But yeah, ideally we could set all of them to recent versions to make sure
people don't use them in very old versions.

For the record, not all plugins have engines or some have but not for all
versions, and really don't know if they properly work.

El jue., 4 jun. 2020 a las 19:40, Chris Brody ()
escribió:

> The whole motivation behind adding the minimum Cordova engine version, in
> the first place, seems to be here:
>
> https://github.com/apache/cordova-plugin-inappbrowser/blob/master/plugin.xml#L33
>
> It says "Needs cordova/urlutil".
>
> I think we do not specify the minimum Cordova engine version on most of the
> plugins, unfortunately don't have much time to check this right now.
>
> Whenever we do specify a minimum Cordova engine version, I would favor
> specifying a version that is not excessively old such as 6 or 7. This is
> analogous to the Node.js ecosystem where the node field in engines does
> actually specify the minimum Node version it can work with.
>
> But yes, definitely should not update with the current Cordova version.
>
> Yeah, probably not worth blocking a release. I wish I had more time to help
> with this kind of improvement.
>
>
> On Thu, Jun 4, 2020 at 1:20 PM Niklas Merz  wrote:
>
> > Correct me if I am wrong, but I don't think we want to update the
> > dependency versions to the current ones. It's just another version we
> > have to track and update.
> >
> > I must say I don't really know what they are for and would love to learn
> > about that.
> >
> > The PR updates them to be consistent and working with a bare minimum
> > like said in the PR with code checks. These old version numbers don't
> > mean that these version have to be supported and compatible. If users
> > have I issues we always advise to use the latest versions of everything.
> >
> > IMHO this shouldn't block a release.
> >
> > Am 04.06.20 um 17:14 schrieb Chris Brody:
> > > I would favor updating the minimum Cordova requirement in both
> > package.json
> > > and plugin.xml, as I just commented in PR #685. I wish I would have
> seen
> > it
> > > before PR #685 was merged.
> > >
> > >
> > > On Thu, Jun 4, 2020 at 10:59 AM Niklas Merz 
> > wrote:
> > >
> > >> I merged two outstanding patches just now.
> > >>
> > >> If no reviews or concern come up, I will start the release in a few
> > hours.
> > >>
> > >> June 2, 2020 8:31 PM, "Niklas Merz"  wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> since cordova-ios 6.0 was released recently the inappbrowser plugin
> > does
> > >> not work properly because
> > >>> of the removal of UIWebView. I would suggest we do a plugin *release
> as
> > >> soon as possible*.
> > >>>
> > >>> Since we already merged some major changes (including the UIWebview
> > >> removal) this will be a major
> > >>> release.
> > >>>
> > >>> Does anyone have a reason to delay the release?
> > >>>
> > >>> From my personal use of the plugin to pending PRs would be helpfull
> for
> > >> this release, but they need
> > >>> reviews. I would not delay the release for them and proceed without
> > >> merging them.
> > >>> https://github.com/apache/cordova-plugin-inappbrowser/pull/688
> > >>> https://github.com/apache/cordova-plugin-inappbrowser/pull/656
> > >>>
> > >>> Any other outstanding patches to land?
> > >>>
> > >>> If not, I will start the release tomorrow.
> > >>>
> > >>> -
> > >>> 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
> >
> >
>

Re: [DISCUSS] cordova-ios 6.0.0 Major Release

[julio cesar sanchez]

The podspec issue is not breaking, we can publish on next patch or minor
release.

El El vie, 5 jun 2020 a las 22:00, Chris Brody 
escribió:

> Looks like we missed breaking PR #795:
> https://github.com/apache/cordova-ios/pull/795
>
> I just put #795 into new 7.0.0 milestone, along with the podspec issue:
> https://github.com/apache/cordova-ios/issues/887
>
>
> On Wed, May 20, 2020 at 4:13 AM Bryan Ellis  wrote:
>
> > This is a followup, I will be preparing the iOS release this Friday
> (about
> > ~48hrs from now).
> >
> > There are a few remaining PRs that could be merged but requires review,
> > rebasing, etc.
> >
> > IF these PRs are not prepared or merged in by then, they will be dropped
> > from this release and postponed for next major. (sometime maybe mid-2021)
> >
> > PRs:
> >
> > * #851 - breaking: replace shelljs with fs-extra
> >   * https://github.com/apache/cordova-ios/pull/851 <
> > https://github.com/apache/cordova-ios/pull/851>
> >
> > * #859 - refactor: use superspawn
> >   * https://github.com/apache/cordova-ios/pull/859 <
> > https://github.com/apache/cordova-ios/pull/859>
> >   * Requires #851
> >
> > * #860 - breaking: drop q dependency
> >   * https://github.com/apache/cordova-ios/pull/860 <
> > https://github.com/apache/cordova-ios/pull/860>
> >   * Requires #851 & #859
> >
> > * #861 - chore: add package-lock.json
> >   * https://github.com/apache/cordova-ios/pull/861 <
> > https://github.com/apache/cordova-ios/pull/861>
> >   * Preferably merged after #860
> >   * Requires Rebasing after #860
> >
> > * #852 - ci: use github actions
> >   * https://github.com/apache/cordova-ios/pull/852 <
> > https://github.com/apache/cordova-ios/pull/852>
> >   * Requires #861
> >
> > * #790 CB-13143: Integrate and replace SplashScreens with Launch
> Storyboard
> >   * https://github.com/apache/cordova-ios/pull/790 <
> > https://github.com/apache/cordova-ios/pull/790>
> >   * Requires a rebase
> >
> > * #808 - (iOS) Dark mode splashscreen storyboard images
> >   * https://github.com/apache/cordova-ios/pull/808 <
> > https://github.com/apache/cordova-ios/pull/808>
> >   * Preferably merged after #790
> >
> > As for the reaming PRs that were mentioned previously and not listed
> above:
> >
> > > - https://github.com/apache/cordova-ios/pull/823 <
> > https://github.com/apache/cordova-ios/pull/823>
> > * I left a comment asking for additional feed back and a concern with the
> > change.
> > * No reply has been received.
> > * I believe this PR will not make it in this release.
> >
> > > - https://github.com/apache/cordova-ios/pull/763 <
> > https://github.com/apache/cordova-ios/pull/763>
> > * This PR was closed out with out merge.
> > * It has been replaced with #859 & #860
> >
> > > - https://github.com/apache/cordova-ios/pull/454 <
> > https://github.com/apache/cordova-ios/pull/454>* There is a
> > comment/request to wrap the changes with a flag so it doesn’t change the
> > default.
> > * This request was not been completed.
> > * I believe this PR will not make it in this release.
> >
> >
> >
> > > On Apr 19, 2020, at 3:35, Darryl Pogue  wrote:
> > >
> > > I've just merged two very small PRs:
> > > - https://github.com/apache/cordova-ios/pull/615
> > > - https://github.com/apache/cordova-ios/pull/825
> > >
> > > There are some others that would be nice to get in, but require more
> > > testing or more work to finish:
> > > - https://github.com/apache/cordova-ios/pull/823
> > > - https://github.com/apache/cordova-ios/pull/790
> > > - https://github.com/apache/cordova-ios/pull/763
> > > - https://github.com/apache/cordova-ios/pull/454
> > >
> > > On Fri, Apr 17, 2020 at 10:56 PM Bryan Ellis  wrote:
> > >
> > >> Does anyone have any reason to delay a cordova-ios major release
> > (6.0.0)?
> > >>
> > >> Any additional outstanding changes to land?
> > >>
> > >> If not, I will start the release process in the next couple of days.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> >
> >
>

Re: Modernize cordova-android build?

[julio cesar sanchez]

There is a PR to allow any jdk version, we mistakenly thought java 8 was
required for android development, but looks like we were wrong.

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


El lunes, 8 de junio de 2020, Darryl Pogue  escribió:

> On Sun, Jun 7, 2020 at 7:49 PM Chris Brody  wrote:
> >
> > Another thing is that many build systems are now using a Gradle wrapper,
> > while Cordova still needs the Gradle tool to be installed in its search
> > path. This may be related to a nasty-looking issue here:
> > https://github.com/apache/cordova-android/issues/845
>
> I seem to recall that we have to use the system-installed gradle to
> generate our gradle wrapper, because the wrapper depends on a JAR file
> and we're not allowed to distribute JAR files.
>
> Previous mailing list discussion regarding gradle wrapper distribution:
> https://lists.apache.org/thread.html/9fcaf3cd6b22e9cd6d09e17ff5956b
> f661c3560be923f734dcc4450e%401403096149%40%3Cdev.cordova.apache.org%3E
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: June board report

[julio cesar sanchez]

How is this calculated?

Issue close rate of 57%:

   - 300 issues opened on GitHub, past quarter
   - 311 issues closed on GitHub, past quarter

311 closed for 300 opened is more than 100%

El El jue, 11 jun 2020 a las 0:29, Jesse  escribió:

> Sorry for the short notice, the June Board Report is due today.
>
> Please review and reply if you have any additions, revisions, or questions.
>
> https://github.com/apache/cordova-apache-board-reports/blob/master/2020/2020-06.md
>
> If it's all good, I'll be submitting it later this evening.
>
> Cheers,
>   Jesse
>

Re: Question about WKWebView Audio

[julio cesar sanchez]

This list is for talking about the development of Apache cordova project,
not for asking questions.

But FYI, it’s a WKWebView bug, supposedly fixed, but unclear if released

https://bugs.webkit.org/show_bug.cgi?id=203293

El viernes, 26 de junio de 2020, Oliver Deng 
escribió:

> Hi Team,
>
>
> currently, I am facing the issue which is about audio in WKWebView. When we
> use the iPhone to open the ionic Cordova app with background music on, then
> the music will suddenly be paused. Do you know how to fix this?
>
>
>
>
>
> Many thanks
> Oliver Deng
>

Re: [DISCUSS] cordova-lib 10.0.0 Major Release

[julio cesar sanchez]

Does the CLI/lib has something to do with platform deprecation? I mean, do
we add warnings or something when adding them?

As far as I know you can always add any platform as long as it implements
the required API, whether is official and maintained or official and
deprecated or a 3rd party platform. Deprecated only means we won’t do more
work on them and we will remove plugins code for those platforms, so I
don’t see any reason to block this release. Even if we add warnings, that
can be done in a minor release.

El El lun, 29 jun 2020 a las 4:05, Chris Brody 
escribió:

> Thanks. Am I right to assume we can start the deprecation in a minor
> release?
>
>
> On Sun, Jun 28, 2020 at 9:32 PM Bryan Ellis  wrote:
>
> > The pinning for Android, OSX, and iOS will be bumped before release. I am
> > currently working on that PR.
> >
> > The deprecation & removal of OSX and Windows pinning from Lib will not be
> > performed in this release.
> >
> > An official vote thread will need to be created for each platform in
> > question. The browser should also be included.
> >
> > The Electron and Browser platform is not being released before Lib or
> CLI.
> >
> > A platform major releases are not required to be performed before a major
> > release of Lib or CLI. They can be released at any time. Only a
> patch/minor
> > release of Lib and CLI is needed.
> >
> >
> > > On Jun 29, 2020, at 10:15, Chris Brody  wrote:
> > >
> > > I think src/platforms/platformsConfig.json should be updated for the
> > recent
> > > cordova-osx & upcoming cordova-android major releases.
> > >
> > > I would also like to see cordova-osx and cordova-windows deprecated
> now,
> > > for reasons discussed in another thread:
> > >
> > > - cordova-osx has outdated platform name (minor) and is missing support
> > for
> > > pods, and is expected to be not needed once we can resolve the issue
> with
> > > using Catalyst
> > > - cordova-windows is not supported by Visual Studio 2019
> > > - maintainers seem to be already overloaded by the burden of supporting
> > > Cordova on all other platforms
> > >
> > > And what about cordova-electron & cordova-browser?
> > >
> > >
> > > On Sun, Jun 28, 2020 at 9:03 PM Bryan Ellis  wrote:
> > >
> > >> Does anyone have any reason to delay a cordova-lib major release
> > (10.0.0)?
> > >>
> > >> Any additional outstanding changes to land?
> > >>
> > >> If not, I will start the release process shortly.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> >
> >
>

Re: [DISCUSS] cordova-lib 10.0.0 Major Release

[julio cesar sanchez]

Ah, didn’t know about the deprecated field.

Then yeah, I think we can set them to true at any moment in a minor release
and then totally remove for next major.
We should probably start separate deprecation vote threads for each
platform.

El El vie, 3 jul 2020 a las 20:00, Chris Brody 
escribió:

> I thought it was cordova-lib, which is used by the Cordova CLI, that would
> generate the deprecated platform messages. Just a reminder that the
> platform supported "out of the box" are imported here (with a require
> statement):
>
> https://github.com/apache/cordova-lib/blob/master/src/platforms/platformsConfig.json
>
> I would definitely agree with Julio that we can add and deprecate platforms
> at any time, presumably in a minor or major release of cordova-lib.
>
> I would definitely favor NOT blocking the cordova-lib release. I just hope
> we can follow up and deprecate the outdated cordova-osx & cordova-windows
> platforms in the near future.
>
>
> On Fri, Jul 3, 2020 at 7:24 AM julio cesar sanchez  >
> wrote:
>
> > Does the CLI/lib has something to do with platform deprecation? I mean,
> do
> > we add warnings or something when adding them?
> >
> > As far as I know you can always add any platform as long as it implements
> > the required API, whether is official and maintained or official and
> > deprecated or a 3rd party platform. Deprecated only means we won’t do
> more
> > work on them and we will remove plugins code for those platforms, so I
> > don’t see any reason to block this release. Even if we add warnings, that
> > can be done in a minor release.
> >
> > El El lun, 29 jun 2020 a las 4:05, Chris Brody 
> > escribió:
> >
> > > Thanks. Am I right to assume we can start the deprecation in a minor
> > > release?
> > >
> > >
> > > On Sun, Jun 28, 2020 at 9:32 PM Bryan Ellis  wrote:
> > >
> > > > The pinning for Android, OSX, and iOS will be bumped before release.
> I
> > am
> > > > currently working on that PR.
> > > >
> > > > The deprecation & removal of OSX and Windows pinning from Lib will
> not
> > be
> > > > performed in this release.
> > > >
> > > > An official vote thread will need to be created for each platform in
> > > > question. The browser should also be included.
> > > >
> > > > The Electron and Browser platform is not being released before Lib or
> > > CLI.
> > > >
> > > > A platform major releases are not required to be performed before a
> > major
> > > > release of Lib or CLI. They can be released at any time. Only a
> > > patch/minor
> > > > release of Lib and CLI is needed.
> > > >
> > > >
> > > > > On Jun 29, 2020, at 10:15, Chris Brody 
> > wrote:
> > > > >
> > > > > I think src/platforms/platformsConfig.json should be updated for
> the
> > > > recent
> > > > > cordova-osx & upcoming cordova-android major releases.
> > > > >
> > > > > I would also like to see cordova-osx and cordova-windows deprecated
> > > now,
> > > > > for reasons discussed in another thread:
> > > > >
> > > > > - cordova-osx has outdated platform name (minor) and is missing
> > support
> > > > for
> > > > > pods, and is expected to be not needed once we can resolve the
> issue
> > > with
> > > > > using Catalyst
> > > > > - cordova-windows is not supported by Visual Studio 2019
> > > > > - maintainers seem to be already overloaded by the burden of
> > supporting
> > > > > Cordova on all other platforms
> > > > >
> > > > > And what about cordova-electron & cordova-browser?
> > > > >
> > > > >
> > > > > On Sun, Jun 28, 2020 at 9:03 PM Bryan Ellis 
> > wrote:
> > > > >
> > > > >> Does anyone have any reason to delay a cordova-lib major release
> > > > (10.0.0)?
> > > > >>
> > > > >> Any additional outstanding changes to land?
> > > > >>
> > > > >> If not, I will start the release process shortly.
> > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: Formally deprecate cordova-plugin-wkwebview-engine?

[julio cesar sanchez]

Yeah, I think we can deprecate it since cordova-ios 6 works the same way by
default, but as Darryl said, we should do a last release with the engines
properly configured to not install in cordova-ios 6.

El El vie, 3 jul 2020 a las 20:04, Darryl Pogue 
escribió:

> I don't know that we want to go as far as deprecating it just yet, but
> we should definitely do a release that prevents it from being
> installed with cordova-ios 6 (since it conflicts).
>
> On Fri, Jul 3, 2020 at 10:50 AM Chris Brody  wrote:
> >
> > It would definitely be nice if we don't have to support that plugin any
> > longer, and I think it would be good to archive it as well. My one
> comment
> > is that there should be a very clear guide for people who have to
> continue
> > using the same scheme due to data stored by the web view. A couple of
> > off-topic items that I think are related:
> >
> > I think we should recommend that people consider using native plugins
> such
> > as cordova-plugin-file, SQLite, or something similar for storing
> important
> > data.. I have seen quite a few things such as local storage deleting
> data,
> > IndexedDB eviction, and other things going wrong to trust the WebView to
> > not lose data.
> >
> > I think we should deprecate and archive some other plugins in the near
> > future, due to the support burden, as I proposed in:
> > https://github.com/apache/cordova/issues/185
> >
> >
> > On Fri, Jul 3, 2020 at 1:28 PM Norman Breau 
> wrote:
> >
> > > Hi team,
> > >
> > > I believe previously we decided on a path to deprecate
> > > cordova-plugin-wkwebview-engine, but I wanted
> > > to make sure that is still our stance.
> > >
> > > cordova-ios@6 supports both url schemes and the legacy file scheme,
> > > effectively making the wkwebview engine plugin redundant. Now that
> > > cordova-ios@6 is released, I feel like it's time to formally deprecate
> > > the wkwebview plugin according to our Deprecation Policy[1]
> > >
> > > With that being said, I'm not sure if we also want to archive this
> > > repository. According to the policy, we should archive if:
> > >
> > > "A deprecated repository might also be archived if we don't intend to
> > > provide support of any kind (Issues, Pull Requests, Releases) for this
> > > component any more."
> > >
> > > I feel like this is probably our intention as I think all maintenance
> > > will now be done in cordova-ios going forward, but I want to gather
> some
> > > thoughts on this.
> > >
> > > [1] https://cordova.apache.org/deprecation_policy.html
> > >
> > > Cheers,
> > > Norman
> > >
> > >
> > >
> > > -
> > > 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
>
>

plugin engines

[julio cesar sanchez]

Historically we have only used/updated plugin engines when a certain
cordova-cli/android/ios version was needed because of a new
feature required by the plugin.

Nowadays, most plugins still (technically) support
old cordova-cli/android/ios versions, but we don't really test on those
versions, so can't be sure. And a few recent PRs I've sent are technically
breaking because I removed old iOS code for iOS 6-8 support. Those versions
have not been supported in cordova-ios for a long time, but the plugins
still supported them as they didn't have engines or the cordova-ios version
used as min supported version still supported them.

So, what I'm proposing is to add engines to all the plugins to require at
least
cordova 9
cordova ios 5.1.0
cordova-android 8.0.0

We should do it before we do a major release of any plugin, but don't mean
we need to do a major release of all plugins right now, just have it in
mind before we do a major release of any plugin.

And I would also like to remove the "protective" engine all plugins have
that points the next major version to cordova >= 100

thoughts?

Network information plugin was updated to require cordova 9
https://github.com/apache/cordova-plugin-network-information/pull/118
camera plugin has a PR to require cordova 9 and cordova-android 9
https://github.com/apache/cordova-plugin-camera/pull/628

Re: plugin engines

[julio cesar sanchez]

>  > And I would also like to remove the "protective" engine all plugins have
> that points the next major version to cordova >= 100
>
> +1. I never really understood the rationale behind this. I think it's
> safe to assume that a next plugin major will continue to support the
> cordova cli that it used to support. If it does not, then we can update
> the engines accordingly.
>

The idea was, if a breaking change was introduced that required updating
engines, but we forgot to update the engines, it would prevent the plugin
to install and break user's projects.
But in most cases it ended in cases where breaking changes were introduced,
but they didn't need updating engines and the "protective" entry ended
blocking the plugin install for no reason, so instead of saving us from
trouble, it caused trouble.


>  > So, what I'm proposing is to add engines to all the plugins to require
> at
> least
> cordova 9
> cordova ios 5.1.0
> cordova-android 8.0.0
>
> I think an argument could be made that adding these could be breaking in
> itself and thus warrant a major release, but at the same time, in
> addition to what Julio said, anything pre cordova-android@8 will not be
> accepted by Google Play store due to target API requirements, and the
> same for pre cordova-ios@5.10 because of the wkwebview requirement. So I
> still give a +1 on this.
>

It's not really a breaking change if we replace the existing protective
entry with these new requirements, since the new requirements are only for
the next major release, and won't have any effect until we release a major
version.

Re: [DISCUSS] Unarchive & Un-deprecate cordova-plugin-device-orientation

[julio cesar sanchez]

I guess you mean this issue
https://github.com/apache/cordova-plugin-device-orientation/issues/52

To be clear, the web API still works on iOS 13, but it requires to request
a permission first with DeviceMotionEvent.requestPermission();

But the permission request has a few issues that I have noticed and
reported to Apple.

1.- If using file scheme it will show "" instead of the app name on the
permission request (https://bugs.webkit.org/show_bug.cgi?id=213469), and if
using a custom scheme it will show the hostname (localhost by default.

2.- Even if you provide an usage description for motion, it's not shown on
the webview permission request (
https://bugs.webkit.org/show_bug.cgi?id=213467)

3.- The permission is not remembered, if you allow it, on next app launch
you need to request it again (https://bugs.webkit.org/show_bug.cgi?id=213468
)


El mar., 18 ago. 2020 a las 6:56, Bryan Ellis () escribió:

> This discussion is to unarchive & un-deprecate the plugin:
>
>   cordova-plugin-device-orientation
>
> This plugin is now requires because iOS w/ Custom Schemes does provide the
> support necessary to use Web APIs.
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: 💡Cordova as a monorepo - ??

[julio cesar sanchez]

Maybe it makes more sense for the tooling packages, common, cli, lib, etc,
as they get less issues reported and it's usually more confusing for users
(and me) to report in the proper place as a bug in one of those modules can
be caused by another module. But I would keep platforms and plugins in
separate repos.
Also the monorepo makes it not possible to install from github, I think a
lot of people rely on that for installing unreleased versions (specially
for plugins since there are no nightly versions for them).


El jue., 27 ago. 2020 a las 18:26, Chris Brody ()
escribió:

> Someone had an idea to convert Cordova into a single monorepo. There
> are some very well-known benefits, and it would help us to keep the
> issues and discussions all in one place. Lerna seems to be a nice tool
> to keep things consistent and in sync.
>
> I think the original PhoneGap that Cordova was based on was a kind of
> monorepo, before it was split up.
>
> I generally tend to lean the other way and favor "small, focused
> modules" but just wanted to mention this idea in case it can help lead
> to other ideas.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: PhoneGap Plugins?

[julio cesar sanchez]

The push plugin is already forked and got a few code updates, so if you
could point to it in the phonegap one would be good. Will have a different
name, so people will have to replace it.

For the barcode, the aar used on android is 4 year old and it’s built from
a zxing app that was abandoned 2 years ago and that was very hard to
update, so I don’t think it makes sense to continue maintaining it as is.
Nowadays there are better sdks, so would make more sense a completely new
plugin, but doesn’t need to be on the Apache umbrella.

El viernes, 4 de septiembre de 2020, Simon MacDonald <
simon.macdon...@gmail.com> escribió:

> Yeah, no worries folks. If you don't have the bandwidth to pull them
> under the Apache umbrella I completely understand.
>
> As for licensing, we'd be able to figure it out. I work with 4 lawyers
> on this stuff so they would be able to figure out a path that works.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Thu, Sep 3, 2020 at 1:45 PM Chris Brody  wrote:
> >
> > At this point I would be a little reluctant to start supporting more
> > plugins.
> >
> > Issues and unmerged PRs seem to keep piling up in multiple places. Here
> are
> > a couple of very sad examples:
> >
> > - https://github.com/apache/cordova-ios/pull/795
> > - https://github.com/apache/cordova-plugin-file/pull/242
> >
> >
> > On Thu, Sep 3, 2020 at 12:34 AM Bryan Ellis  wrote:
> >
> > > It could be integrated into Apache.
> > >
> > > What exactly would the process of integrating look like?
> > >
> > > I suspect it would start with a vote email?
> > >
> > > Since the existing plugin license is MIT, what happens here?  I don't
> know
> > > the rules or process on how we can change the license. I had read that
> > > there were exceptions where we might be able to keep the original
> license
> > > while in Apache. I believe...
> > >
> > > Also, would the old repo be transferred, forked, hard copy?
> > >
> > > If we do this, we could start with "phonegap-plugin-barcodescanner”.
> > >
> > >
> > >
> > > > On Aug 29, 2020, at 5:33, Jesse  wrote:
> > > >
> > > > Thanks Simon
> > > >
> > > > We'll look at this. Erisu appears to already be actively working on
> > > > havesource/cordova-plugin-push
> > > >
> > > > Cheers,
> > > >  Jesse
> > > >
> > > > On Fri, Aug 28, 2020 at 1:22 PM Simon MacDonald <
> > > simon.macdon...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Long time no chat. As you are no doubt aware Adobe announced they
> are
> > > >> no longer in the PhoneGap business. To that end I archived the
> > > >> following plugins that are still being used widely:
> > > >>
> > > >> phonegap-plugin-push - 7,659 weekly downloads
> > > >> phonegap-plugin-barcodescanner - 11,058 weekly downloads
> > > >>
> > > >> I'm terribly disappointed that I have not been able to actively
> > > >> maintain them for the past two years. To that end, if you think it
> > > >> would be beneficial to Apache Cordova I can navigate the waters
> > > >> internally to donate the plugins to Apache.
> > > >>
> > > >> Note: I'm not trying to throw this code over the wall and make it
> > > >> someone else's problem. Cordova has been a positive experience in my
> > > >> life and if donating the code helps the project I'll make it happen.
> > > >> If you don't feel like it would help we'll keep the repo's archived
> > > >> and hope the community forks and maintains things.
> > > >>
> > > >> Julio mentioned there is already a fork of the push plugin at
> > > >> https://github.com/havesource/cordova-plugin-push.
> > > >>
> > > >> Let me know what you think as I've been contacted by a few users
> > > already.
> > > >>
> > > >> Simon Mac Donald
> > > >> http://simonmacdonald.com
> > > >>
> > > >> 
> -
> > > >> 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: Greenfield for cordova-plugin-network-information + release version 3.0.0

[julio cesar sanchez]

It would be good that instead of just saying what you would like to see
changed, you also say why you would like it (benefits, reasoning, etc.)

El lunes, 7 de septiembre de 2020, Niklas Merz 
escribió:

> Hi Pieter
>
> At first a warm welcome to the list.
>
> If you would like to open a proposal for discussion I can point you to
> the cordova-discuss repository:
> https://github.com/apache/cordova-discuss/ . We track some proposals in
> issues and pull requests there.
>
> I am not really familiar with the plugin but looking at the description
> and recent activity it looks like it was designed to implement the old
> version of the Network Information API. Other community members probably
> know more about that.
>
> A new major version could possibly change that if we can get consensus
> about this but someone would need to do the work.
>
> It looks you already got your own requirements ready and I personally
> would build and publish this plugin myself in this case. Creating
> plugins is not that hard if you start with the skeleton of an existing
> one. Contact me if you need any help.
>
> Kind regards
> Niklas
>
> Am 07.09.20 um 00:06 schrieb Pieter Van Poyer:
> > Hey Cordova devs
> >
> > You are doing a great job with Cordova.
> > I've got a question, suggestion for the cordova-plugin-network-
> information.
> >
> > Is it possible to open an issue, a milestone, a metaticket or something
> to discuss the future requirements of the plugin (v4).
> > Something like a whitepaper.
> >
> >
> > My suggestions for a whitepaper are:
> >
> > Loosen the requirements of the plugin to it's barebone's essentials.
> > Requirements
> >
> >   *   Detect online/offline only when the app is active.
> >   *   When online, only detect following types: WIFI, MOBILE
> > Stop with next requirements
> >
> >   *   Detect online/offline when the app is not active.
> >   *   Don't try to detect other network type's beside WIFI and MOBILE.
> >   *   Do not let this plugin support background work like fileupload's
> and datasyncs. Remove it from the doc's.
> >   *   Drop Windows platform support.
> > For android: use the NetworkCallback reference/android/net/ConnectivityManager.NetworkCallback.html> API
> instead of the deprecated Connectivitymanager.
> >
> > Maybe we could take some insparation by looking at the Capacitor plugin
> https://github.com/ionic-team/capacitor-plugins/tree/main/network or
> Flutter plugin.
> >
> >
> > Is it also possible to release version 3.0.0 of the plugin.
> >
> > Kind regards
> >
> > Pieter Van Poyer
> >
> > 
> >
> > Deze e-mail en alle gekoppelde bestanden zijn officiele documenten van
> Havenbedrijf Antwerpen NV van publiek recht en kunnen vertrouwelijke of
> persoonlijke informatie bevatten. Gelieve de afzender onmiddellijk via
> e-mail of telefonisch te verwittigen als u deze e-mail per vergissing heeft
> ontvangen en verwijder vervolgens de e-mail zonder deze te lezen, te
> reproduceren, te verspreiden of te ontsluiten naar derden. Havenbedrijf
> Antwerpen NV van publiek recht is op geen enkele manier verantwoordelijk
> voor fouten of onnauwkeurigheden in de inhoud van deze e-mail. Havenbedrijf
> Antwerpen NV van publiek recht kan niet aansprakelijk gesteld worden voor
> directe of indirecte schade, verlies of ongemak veroorzaakt als gevolg van
> een onnauwkeurigheid of fout in deze e-mail.
> >
> > English Translation: This e-mail and all attached files are official
> documents of Antwerp Port Authority and may contain confidential or
> personal information. If you have received this e-mail in error, you are
> asked to inform the sender by e-mail or telephone immediately, and to
> remove it from your system without reading or reproducing it or passing it
> on to other parties. Antwerp Port Authority is in no way responsible for
> any errors or inaccuracies in the contents of this e-mail, nor can it be
> held liable for any direct or indirect loss, damage or inconvenience
> arising from any such errors or inaccuracies.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Minimum Target SDK

[julio cesar sanchez]

Despite we allow users to configure the target SDK, I don’t think we should
allow other than the default on latest cordova-android.

By allow I mean on issues, users are free to use whatever they want, but if
they don’t use latest they should take care of possible problems themselves.
With that being said, camera plugin requires latest cordova-android, so
that means target sdk 29.

But also we need to have in mind that if the plugin allowed older
cordova-android versions and we add some code that requires a higher sdk
than the default on that cordova-android version we should bump the
dependency to the version that targets that sdk as default.

BTW, sdk 29 is already a requirement for new apps since August, November is
for existing apps.

El El mié, 14 oct 2020 a las 23:46, Norman Breau 
escribió:

> Hi team,
>
> A recent discussion came up about what the minimum Target SDK we should
> support. Google enforces apps to be built with at least Target SDK 28 (soon
> to be 29 coming November), but Cordova users may not be publishing to the
> Google Play store, particularly with enterprise businesses with internal
> distribution systems.
> This is currently not documented and I would like it to be documented
> because we were close to merging a PR that would make the camera plugin
> require Target SDK 28. But before I submit a documentation PR I would like
> some feedback on what our minimum Target SDK should be.
> Logically I think it makes the most sense to say that whatever what our
> Minimum SDK level is should be our minimum supported Target SDK (which is
> currently 22 for cordova-android@9).
> For clarity because terminology here is a little confusion:
> Minimum SDK = The minimum supported OS
> Target SDK = The SDK level used to compile an app.
>
> Norman Breau
> Software Developer
>
> nor...@normanbreau.com (
> https://link.getmailspring.com/link/c6cac914-84d1-430d-9fd4-acd8f2bcd...@getmailspring.com/0?redirect=mailto%3Anorman%40normanbreau.com&recipient=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D
> )
> https://breautek.com (
> https://link.getmailspring.com/link/c6cac914-84d1-430d-9fd4-acd8f2bcd...@getmailspring.com/2?redirect=https%3A%2F%2Fbreautek.com&recipient=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D
> )
>
>

Re: Minimum Target SDK

[julio cesar sanchez]

Related to this. Should we allow setting the min SDK lower than the min SDK
cordova-android uses?
At the moment it’s not possible, I closed this issue because I thought we
didn’t allow it, but if we allow it then should be reopened and fixed

https://github.com/apache/cordova-android/issues/1070

El jueves, 15 de octubre de 2020, Norman Breau 
escribió:

> To recap our hangouts meeting on this topic
>
> Sounds like the stance we are to take is to officially only support the
> cordova default target/compile sdk version (which is currently 29). Users
> can change this if they wish at their own risk.
> Norman Breau
> Software Developer
>
> nor...@normanbreau.com (mailto:nor...@normanbreau.com)
> https://breautek.com
>
> On Oct 15 2020, at 6:05 am, Pieter Van Poyer  portofantwerp.com> wrote:
> >
> > Hi
> >
> >
> > I'd like to give my opinion. Because the discussion about the sdk
> version was with me.
> >
> > I don't like to disagree with Norman, but the problem with the
> CameraPlugin was IMO not with the targetSdkVersion. I could lower the
> targetSdkVersion to 22 without any problems.
> >
> > The problem was with the compileSdkVersion.
> > I was not able to use a constant available in android 28
> (Build.VERSION_CODES.P, if I am right), because Norman suggested it would
> be able to compile with android level 22.
> > So I did change it to the numerical 28 .
> >
> >
> >
> >
> >
> >
> > So IMO, there may be more guidelines
> > About the targetSdkVersion. Not sure about that one. (
> https://developer.android.com/guide/topics/manifest/uses-
> sdk-element.html#target )
> > About the compileSdkVersion (only support officially the one used for
> cordova-android – 29).
> > With using the latest compileSdkVersion and skipping the previous (now
> 22 – 28), plugin developers can use the features from api 29.
> >
> >
> >
> >
> > And for a plugin, this settings must indeed be based on the supported
> cordova (-android) version of that plugin. It must indeed be able to run on
> the defaultMinSdkVersion for the supported cordova-android versions.
> >
> > Kind regards
> > Pieter Van Poyer
> >
> > -Oorspronkelijk bericht-
> > Van: julio cesar sanchez 
> > Verzonden: donderdag 15 oktober 2020 00:39
> > Aan: dev@cordova.apache.org
> > Onderwerp: Re: Minimum Target SDK
> >
> >
> >
> > Despite we allow users to configure the target SDK, I don’t think we
> should allow other than the default on latest cordova-android.
> >
> > By allow I mean on issues, users are free to use whatever they want, but
> if they don’t use latest they should take care of possible problems
> themselves.
> > With that being said, camera plugin requires latest cordova-android, so
> that means target sdk 29.
> >
> > But also we need to have in mind that if the plugin allowed older
> cordova-android versions and we add some code that requires a higher sdk
> than the default on that cordova-android version we should bump the
> dependency to the version that targets that sdk as default.
> >
> > BTW, sdk 29 is already a requirement for new apps since August, November
> is for existing apps.
> >
> > El El mié, 14 oct 2020 a las 23:46, Norman Breau  (mailto:nor...@normanbreau.com)>
> > escribió:
> >
> > > Hi team,
> > >
> > > A recent discussion came up about what the minimum Target SDK we
> > > should support. Google enforces apps to be built with at least Target
> > > SDK 28 (soon to be 29 coming November), but Cordova users may not be
> > > publishing to the Google Play store, particularly with enterprise
> > > businesses with internal distribution systems.
> > > This is currently not documented and I would like it to be documented
> > > because we were close to merging a PR that would make the camera
> > > plugin require Target SDK 28. But before I submit a documentation PR I
> > > would like some feedback on what our minimum Target SDK should be.
> > > Logically I think it makes the most sense to say that whatever what
> > > our Minimum SDK level is should be our minimum supported Target SDK
> > > (which is currently 22 for cordova-android@9).
> > > For clarity because terminology here is a little confusion:
> > > Minimum SDK = The minimum supported OS Target SDK = The SDK level used
> > > to compile an app.
> > >
> > > Norman Breau
> > > Software Developer
> > >
> > > nor...@normanbreau.com (mailto:nor...@normanbreau.com) (
> > > https:/

Re: [DISCUSS] Cordova Plugin Geolocation 4.0.3 Release

[julio cesar sanchez]

It should be 4.1.0

One of the changes adds a new install variable, that's a feature.

El jue., 5 nov. 2020 a las 17:14, Bryan Ellis () escribió:

> Does anyone have any reason to delay a cordova-plugin-geolocation release
> 4.0.3?
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process with <= 24 hours.

Re: Proxy for CORS/ITP issues built into cordova-ios

[julio cesar sanchez]

I don't think the proxy belongs to cordova-ios, I think it should be a
separate plugin, but not a webview plugin, I think cordova-ios should allow
one this two:

a) cordova-ios should allow plugins/users to set their
own WKURLSchemeHandler. This can be problematic since there can only be one
for the same scheme, so should be a subclass of CDVURLSchemeHandler or
duplicate most of its code.
b) cordova-ios should allow plugins to handle requests
inside CDVURLSchemeHandler, so if a plugin is able to handle a request, let
the plugin handle it, if not, use the default CDVURLSchemeHandler code for
request handling.

Both options would allow to create plugins that act like a proxy, or other
features like loading app content from the device file system instead of
from the www folder (for live update plugins).

El mar., 13 oct. 2020 a las 13:43, Niklas Merz ()
escribió:

> This might take time to get released in Cordova iOS if it becomes part of
> the platform at all.
>
> On 2020/10/08 21:22:08, Steve Podell  wrote:
> > Hi,
> >I desperately need this for the non-profit WeVote Voter Guide app
> > .  Please add your change to cordova IOS, it
> > seems like a core feature for IOS 14 to me.
> >
>
> If you need an solution immediatly you can use a custom version of the
> Ionic Webview plugin:
> cordova plugin add
> https://github.com/GEDYSIntraWare/cordova-plugin-ionic-webview#custom.
> Contact me if you need help.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Cordova Plugin Geolocation 4.1.0 Release

[julio cesar sanchez]

Variables have always required to uninstall and reinstall to change them.

El lunes, 9 de noviembre de 2020, Bryan Ellis  escribió:

> I also agree that this issue is not related to the plugin and should not be
> a blocker for the release.
>
> With little digging into this issue, I want to say it might be an issue in
> Cordova Lib and maybe around munger.
>
> When you add the plugin, and review the contents of this file:
> */cordovaPlugin/platforms/android/android.json,
> y*ou will notice that it contains plugin information which I want to say is
> going to be used for the cordova prepare step.
>
> Example snippet:
>
> "cordova-plugin-geolocation": {
>   "GPS_REQUIRED": "false",
>   "PACKAGE_NAME": "org.apache.cordovaPlugin"
> }
>
> When running cordova prepare, this is not updated either.
>
> More investigation would be required to determine if it is coming from
> this, and also another thread to future discuss this issue and also if it
> is intentional or not.
>
>
>
> On Mon, Nov 9, 2020 at 3:34 PM Norman Breau  wrote:
>
> > Testing the feature that was added, I observed some odd behaviour.
> >
> > I added the plugin with the --variable GPS_REQUIRED set to false. This
> > works as expected, with the variable recorded in package.json and the
> > AndroidManifest.xml containing the proper flag to signal that gps
> hardware
> > is not required.
> > However, if I change the variable inside package.json from "false" to
> > "true" and rerun prepare or build, the AndroidManifest.xml is not
> updated.
> > The only way I can get AndroidManifest.xml to update properly is by
> > removing the plugin and re-adding it with the updated variable. Is this
> > intentional?
> > Even if this is a bug, I don't think it's a bug inside this plugin so I
> > don't think it's necessary to block the release or anything. Just simply
> > pointing out a potential problem.
> > On Nov 5 2020, at 11:32 pm, Bryan Ellis  wrote:
> > >
> > > This is an updated thread of the previous thread
> > https://lists.apache.org/thread.html/r431cbb7ae688285280e2cb0a92f88
> c241596960c0932c34ca45bd7b7%40%3Cdev.cordova.apache.org%3E
> > <
> > https://lists.apache.org/thread.html/r431cbb7ae688285280e2cb0a92f88
> c241596960c0932c34ca45bd7b7@%3Cdev.cordova.apache.org%3E
> > >
> > > The only exception is that it will prepare for the
> > cordova-plugin-geolocation 4.1.0 release instead.
>

Re: [VOTE] Deprecate cordova-plugin-wkwebview-engine

[julio cesar sanchez]

+1

El sábado, 6 de febrero de 2021, Niklas Apache 
escribió:

> +1
>
> On February 6, 2021, "dpogue.ca"  wrote:
> > +1
> >
> > On Fri, Feb 5, 2021 at 8:54 PM Bryan Ellis  wrote:
> > >
> > > +1
> > >
> > > On Sat, Feb 6, 2021 at 1:21 PM Jesse 
> > wrote:
> > >
> > > > +1
> > > >
> > > > > On Feb 5, 2021, at 5:49 PM, Norman Breau 
> > wrote:
> > > > >
> > > > > Now that the wkwebview engine plugin is published on NPM,
> > pending
> > > > announcement (waiting for cordova.apache.org to update with the
> > blog
> > > > post). I would like to set motion a vote to deprecate this
> > package.
> > > > >
> > > > > The reason for deprecation is the plugin's code base has
> > effectively
> > > > been moved to the core cordova-ios platform, making the plugin
> > deprecated.
> > > > >
> > > > > Upon a successful vote to deprecate this plugin, I'll prepare a
> > PR
> > > > adding deprecation text to the plugin's readme as well as marking
> > the NPM
> > > > package as deprecated.
> > > > >
> > > > > I vote +1.
> > > > >
> > > > >
> > > > >
> > > > >
> > -
> > > > > 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
>

Re: Cordova plan to adopt LivePerson Messaging SDK?

[julio cesar sanchez]

We don't create apache plugins for 3rd party SDKs, you can build it
yourself or contact Liveperson and ask them about a plugin.


El mié, 3 mar 2021 a las 10:08, Manisha Bardiya ()
escribió:

> Hi Team,
>
> We are looking at Cordova as an option for our mobile app, can you confirm
> if you have any plans to adopt native Liveperson Messaging SDK in Cordova?
> If yes, May I know your planned timelines, this will help us a lot.
>
> Thanks in advance.
>
>
>
> Thanks,
>
> Manisha Bardiya
>

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[julio cesar sanchez]

I'm a little concerned about
https://github.com/apache/cordova-android/pull/1174 and the previous one
that also bumped the gradle version to 6.6.1. If you open the project on
latest Android Studio, Android Studio recommends using Gradle 6.5, so not
sure how safe it is to use the latest bleeding edge version instead of the
recommended and if that could cause problems with plugins that have gradle
files.

But since it's a minor bump maybe I have no reason to be concerned.

Other than that, looks good.


El mar, 30 mar 2021 a las 17:06, Bryan Ellis () escribió:

> Does anyone have any reason to delay a cordova-android minor release
> (9.1.0)?
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process shortly.
>
>
> ==Changes==
>
> https://github.com/apache/cordova-android/compare/9.0.0...master

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[julio cesar sanchez]

Yeah, but 9.0.0 was a major release, and the PR that updated gradle had
"major" on the title. So it was safer to bump versions.

El mar, 30 mar 2021 a las 19:49, Chris Brody ()
escribió:

> FYI the build seemed to be red due to a timeout; I just restarted the
> build; hope it will be green.
>
>
> On Tue, Mar 30, 2021 at 1:46 PM Norman Breau 
> wrote:
>
> > 9.0 used the latest available release at the time of the release with no
> > issue. Gradle 6.5 is just the minimum required version according to the
> > docs, they explicitly say 6.5+ is supported:
> > https://developer.android.com/studio/releases/gradle-plugin
> >
> > Because we were already on >= 6.5, I think this is still okay for
> release.
> >
> > On 2021-03-30 2:37 p.m., julio cesar sanchez wrote:
> > > I'm a little concerned about
> > > https://github.com/apache/cordova-android/pull/1174 and the previous
> one
> > > that also bumped the gradle version to 6.6.1. If you open the project
> on
> > > latest Android Studio, Android Studio recommends using Gradle 6.5, so
> not
> > > sure how safe it is to use the latest bleeding edge version instead of
> > the
> > > recommended and if that could cause problems with plugins that have
> > gradle
> > > files.
> > >
> > > But since it's a minor bump maybe I have no reason to be concerned.
> > >
> > > Other than that, looks good.
> > >
> > >
> > > El mar, 30 mar 2021 a las 17:06, Bryan Ellis ()
> > escribió:
> > >
> > >> Does anyone have any reason to delay a cordova-android minor release
> > >> (9.1.0)?
> > >>
> > >> Any additional outstanding changes to land?
> > >>
> > >> If not, I will start the release process shortly.
> > >>
> > >>
> > >> ==Changes==
> > >>
> > >> https://github.com/apache/cordova-android/compare/9.0.0...master
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[julio cesar sanchez]

I've seen that Bryant sent a few PRs reverting gradle related dependencies.
I only meant gradle wrapper, not everything else, and it's because Android
Studio automatically updates to 6.5 instead of updating to the latest
version.
In Capacitor we have had problems when users have updated the wrapper, but
not with the gradle plugin or google services plugin (at least that I
remember)


El mié, 31 mar 2021 a las 2:57, Jesse () escribió:

> +1 to moving ahead with 9.1.0, I think this is correctly identified as a
> minor.
>
>
> On Tue, Mar 30, 2021 at 2:51 PM  wrote:
>
> > It would be great if we could include
> > https://github.com/apache/cordova-android/pull/1101 in this release.
> >
> > It is just a pure refactoring/non-functional change PR but it sure would
> be
> > great to merge and release it before it gets stale.
> >
> > I would have no concerns merging it as is, even without reviews, since I
> am
> > confident it is an improvement in code quality. So we would not need to
> > delay the release.
> >
> > What do you think?
> >
> > Bryan Ellis  schrieb am Di., 30. März 2021, 17:06:
> >
> > > Does anyone have any reason to delay a cordova-android minor release
> > > (9.1.0)?
> > >
> > > Any additional outstanding changes to land?
> > >
> > > If not, I will start the release process shortly.
> > >
> > >
> > > ==Changes==
> > >
> > > https://github.com/apache/cordova-android/compare/9.0.0...master
> >
>