You might also want to consider the Google Closure Compiler.
-Terence
On 2/13/2015 4:39 PM, Carlos Santana wrote:
Danish,
Like Joe said you can't encrypt your web code (i.e. javascript), at the
end of the day it needs to be parse by the webview in plain text.
Most you can do is obfuscate b
Ouch - Is the thinking to do a database restore to get the data back? (Or is it
too early to know.)
From: Steven Gill
Sent: Friday, February 13, 2015 7:13 PM
To: Andrew Grieve
Cc: dev
Subject: Re: Plugin history purged from registry?
Thanks Andrew
Anis
Actually that is an interesting point. Are we starting to add platform
specific attributes / elements into config.xml? Most of these were done as
preferences historically.
(BTW - Makes sense to add it, more raising the question as a topic about format
to help inform other PRs along these line
Thanks Andrew
Anis and I have spent the last little while trying to figure out why this
is happening.
For some reason, plugman publish is overwriting the existing version. The
tarballs are still in the DB, but the json version data seems to be gone.
Our running theory is it has something to do wi
Done. Fixed up the publish of device plugin & uploaded fixed archive to
cordova/dist.
On Fri, Feb 13, 2015 at 8:03 PM, Andrew Grieve wrote:
> I uploaded from the .zips we voted on. Seems the tagged version of device
> actually has -dev in it :(
>
> I'll re-archive & re-tag it. only difference
Fair enough. That said, this feels like we're trying to avoid testing.
On Fri, 13 Feb 2015 5:01 pm Andrew Grieve wrote:
> True. You can also use bin/create --link to avoid CLI though
>
> On Fri, Feb 13, 2015 at 5:41 PM, Joe Bowser wrote:
>
> > Right, but then I have to rely on the CLI to work.
I uploaded from the .zips we voted on. Seems the tagged version of device
actually has -dev in it :(
I'll re-archive & re-tag it. only difference between it and the commit
before its the adding of -dev.
On Fri, Feb 13, 2015 at 7:30 PM, Chuck Lantz wrote:
> So that would indicate things are reco
True. You can also use bin/create --link to avoid CLI though
On Fri, Feb 13, 2015 at 5:41 PM, Joe Bowser wrote:
> Right, but then I have to rely on the CLI to work. That means if there's
> something wrong with the CLI, I'm blocked because I'm stuck being yet
> another cook on something that has
There's already
So... how about adding support for:
and:
On Fri, Feb 13, 2015 at 4:12 PM, Tommy Williams wrote:
> I apologise for how anglo-chauvanist my response was. I guess I didn't
> really understand CB-6511... This isn't a bug that just affects some
> external group of developers,
I see no reason why we shouldn't post old versions. It's easy to do.
On Fri, Feb 13, 2015 at 4:42 PM, Treggiari, Leo
wrote:
> I have another question which I don't remember being discussed.
>
> Will older versions of the core plugins be published in NPM? I ask
> because existing user projects m
So that would indicate things are recoverable at least - Odd that
http://registry.cordova.io/org.apache.cordova.geolocation/0.3.11 returns json
with the version not found message. That would seem to mirror what you see on
the site.
-Chuck
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent
Github user muratsu closed the pull request at:
https://github.com/apache/cordova-ios/pull/129
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature i
Github user muratsu commented on the pull request:
https://github.com/apache/cordova-ios/pull/129#issuecomment-74351002
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
en
Github user shazron commented on the pull request:
https://github.com/apache/cordova-ios/pull/129#issuecomment-74348925
pulled in (see CB-8435). you can close this issue now
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
On Fri, Feb 13, 2015 at 3:18 PM, Steven Gill wrote:
> plugman info org.apache.cordova.geolocation still lists all of the old
> versions and as far as I can tell the attachments are still available.
>
> You can still download them by going to:
>
> Current version:
> http://registry.cordova.io/org.
GitHub user chrisbubernak opened a pull request:
https://github.com/apache/cordova-windows/pull/58
Fixed wording of warning + removed a commented out line
-made the warning message make more sense
-fixed the grammar of a comment in same function
-removed a commented out line
Github user shazron commented on the pull request:
https://github.com/apache/cordova-ios/pull/129#issuecomment-74345377
It should be CB-8435 (please edit the PR title). Don't worry about the
commits, I can edit the commit message when pulling/squashing it in.
---
If your project is s
plugman info org.apache.cordova.geolocation still lists all of the old
versions and as far as I can tell the attachments are still available.
You can still download them by going to:
Current version:
http://registry.cordova.io/org.apache.cordova.geolocation/-/org.apache.cordova.geolocation-0.3.12
This is scary. Is this recoverable?
--
tommy-carlos williams
On 14 February 2015 at 09:47:46, Chuck Lantz (cla...@microsoft.com) wrote:
Darryl appears to be correct - I just cleared my .plugman cache and any pinned
plugins stopped working because it was unable to fetch. That's a big problem.
Wow. I will look into it right now
On Fri, Feb 13, 2015 at 2:46 PM, Chuck Lantz wrote:
> Darryl appears to be correct - I just cleared my .plugman cache and any
> pinned plugins stopped working because it was unable to fetch. That's a
> big problem.
>
> -Chuck
>
> -Original Message-
> F
Darryl appears to be correct - I just cleared my .plugman cache and any pinned
plugins stopped working because it was unable to fetch. That's a big problem.
-Chuck
-Original Message-
From: dvpdin...@gmail.com [mailto:dvpdin...@gmail.com] On Behalf Of Darryl Pogue
Sent: Friday, February
Danish,
Like Joe said you can't encrypt your web code (i.e. javascript), at the
end of the day it needs to be parse by the webview in plain text.
Most you can do is obfuscate by using a tools like [1] uglifyjs to remove
comments, and do minification, their are others this is just one.
you can ru
Right, but then I have to rely on the CLI to work. That means if there's
something wrong with the CLI, I'm blocked because I'm stuck being yet
another cook on something that has too many cooks.
On Thu Feb 12 2015 at 6:04:55 PM Andrew Grieve wrote:
> Woo! All sounds great! Paramedic sounds awesom
Thanks Nikhil I see this as a very good and important feature to have in
our CLI stack
On Fri, Feb 13, 2015 at 4:48 PM, Nikhil Khandelwal
wrote:
> I'm taking this over from Dan. I like the idea of having the release
> signing information persisted in a json file.
>
> I have made some updates on
Github user muratsu commented on the pull request:
https://github.com/apache/cordova-ios/pull/129#issuecomment-74336804
The issue is finally resolved - we can go forward with this PR
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHu
After the plugins update today, all the old versions of the core plugins
have disappeared from the registry. Anyone that has projects locked to
specific versions of plugins is now unable to build.
For me personally, that means potentially missing legal review deadlines
for an app because I can't g
I'm taking this over from Dan. I like the idea of having the release signing
information persisted in a json file.
I have made some updates on the specific issue of how keys/passwords can be
passed through CLI and JSON:
https://docs.google.com/document/d/1tJQ9OoGrrMhZcLI3mg46rGzAfbiQu9PuNBL1auA
I have another question which I don't remember being discussed.
Will older versions of the core plugins be published in NPM? I ask because
existing user projects may reference previous versions of plugins and may want
to be able to continue to fetch them for quite some time. This is separate
I apologise for how anglo-chauvanist my response was. I guess I didn't
really understand CB-6511... This isn't a bug that just affects some
external group of developers, It caused quite a bit of trouble for me
personally in my day job. I have had to revert to a lesser version of
Cordova until somet
https://twitter.com/infrabot/status/566326512505217024
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Github user omefire commented on the pull request:
https://github.com/apache/cordova-lib/pull/166#issuecomment-74318530
What if a plugin install fails ? don't we want to continue with other
plugins' install like we do for platforms ?
That way, we also handle platform-dependent plug
Hmm, for cloud builders, it's also important that it show up in config.xml.
You've won me over. :)
On Fri, Feb 13, 2015 at 2:48 PM, Connor Pearson wrote:
> I'd prefer the activity name to be saved somewhere rather than relying on
> adding the option each time. I'm also not sure how the flag woul
I'd prefer the activity name to be saved somewhere rather than relying on
adding the option each time. I'm also not sure how the flag would work with
the auto save/restore of platforms.
There really shouldn't be any reason change the activity name. I think the
app name is more likely to change and
Github user omefire commented on the pull request:
https://github.com/apache/cordova-lib/pull/166#issuecomment-74313313
hmmm, it seems to me that during prepare, while restoring from config.xml,
we do use variables from config.xml. so, we should save it during
--save/autosave. Please,
Why is this a problem? We currently do not support this use case and do
not have any plans to as far as I'm aware. Anyone can unzip any APK and
dedex the code to see the Java as well. This often leads to hilarious
commentary on profanity in what people believed would be private code.
If you hav
HI,
First i would like to thank you for creating cordova. I have made one
application which is based on jquery mobile base in cordova. The only issue
is i want to encrypt .apk file because any body can change .apk extension
to .zip file & can view all the assest folder html files. i want to encryp
Thanks Andrew!
> On Feb 13, 2015, at 9:26 AM, Andrew Grieve wrote:
>
> Plugins published & blog post up!
> http://cordova.apache.org/news/2015/02/10/plugins-release.html
>
>
>
> On Fri, Feb 13, 2015 at 11:29 AM, Andrew Grieve
> wrote:
>
>> The vote has now closed. The results are:
>>
>>
Brilliant - thanks
W dniu 13/02/2015 o 18:16, Dmitriy Barkalov (Akvelon) pisze:
Hi Piotr,
Yes, seems chapter "Configuration Files" needs review. Please read
cordova-repos.json and cordova-config.json instead of repos.json and config.json.
An example of content of cordova-config.json you may f
Github user gorkem commented on the pull request:
https://github.com/apache/cordova-lib/pull/166#issuecomment-74294685
sure... as long as there plugin install logic uses variables from
config.xml, which does not.
---
If your project is set up for it, you can reply to this email and h
Github user omefire commented on the pull request:
https://github.com/apache/cordova-lib/pull/166#issuecomment-74293656
Also, we should probably save the plugin variables along with the version
into config.xml, so that on prepare/restore, we don't fail.
---
If your project is set up
Right. I'm suggesting adding the flag to "cordova platform add"
On Fri, Feb 13, 2015 at 11:46 AM, Connor Pearson wrote:
> I think it would have to be more than a flag to the create command.
>
> The use case I'm thinking of is an existing project that doesn't have the
> platforms folder checked i
Had a look. Seems WKWebView and UIWebView's storage files are compatible,
so the plugin just copies the file to a new location. Obviously the
easiest/best solution if it works (not intending to try myself though...
any takers?)
On Fri, Feb 13, 2015 at 11:04 AM, Ryan Hanna wrote:
> Would the goog
Plugins published & blog post up!
http://cordova.apache.org/news/2015/02/10/plugins-release.html
On Fri, Feb 13, 2015 at 11:29 AM, Andrew Grieve
wrote:
> The vote has now closed. The results are:
>
> Positive Binding Votes: 3
>
> Andrew Grieve
> Sergey Grebnov
> Jesse MacFadyen
>
>
> Negative
Hi Piotr,
Yes, seems chapter "Configuration Files" needs review. Please read
cordova-repos.json and cordova-config.json instead of repos.json and
config.json.
An example of content of cordova-config.json you may find in config.json.sample.
Regards, Dmitriy.
-Original Message-
From: P
It depends on how portable you want the data to be, the option below will
persist across devices, not just across web views.
Jay Proulx | computer scientist | aem engineering | office: 613.940.4052 |
mobile: 613 866 0732 | adobe systems
On 2015-02-13, 11:04 AM, "Ryan Hanna" wrote:
>Would the
I think it would have to be more than a flag to the create command.
The use case I'm thinking of is an existing project that doesn't have the
platforms folder checked into source control. A developer checks out the
project then runs cordova platform add for any of the platforms they want
to build
Github user gorkem commented on the pull request:
https://github.com/apache/cordova-lib/pull/166#issuecomment-74284189
Save logic is a bit disorganized because I was expecting @omefire to
implement it for plugins as well, so I have whipped up something. I will
probably make another pa
The vote has now closed. The results are:
Positive Binding Votes: 3
Andrew Grieve
Sergey Grebnov
Jesse MacFadyen
Negative Binding Votes: 0
The vote has passed.
On Thu, Feb 12, 2015 at 9:50 PM, Jesse wrote:
> +1
> Verified file-transfer plugin fix
> Some Ad-hoc testing on windows and wp8
>
Would the google drive persistence be useful across webviews for apps
already using storage that is not with google drive?
Eddy V seems to have come up with a great solution for iOS in his WKWebview
plugin as a
reference.
https://github.com/Telerik-Verified-Plugins/WKWebView/commits/master?page=2
Yeah - The PRs were closed and not merged based on this thread:
http://callback.markmail.org/message/vx5zklk57uic3iig?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+New+project+%3CPATH%3E+vs%2E+%3CNAME%3E+order:date-backward
Basically the feature was deferred at the time.
-Chuck
-Original M
Github user EricWVGG commented on the pull request:
https://github.com/apache/cordova-plugin-media/pull/12#issuecomment-74271774
If any of you are interested, WNYC made a similar plugin that utilizes the
VLC media player. This allows for near-instantaneous playback of streaming
audio,
All of those PRs are closed...
Thanks for pointing out that article. Makes it quite clear that this is a
thing we need to support.
The android:name is necessitates that a .java file be renamed when it
changes, so I don't think it should be a part of config.xml (annoying to
have to move files. esp
Github user flinn commented on the pull request:
https://github.com/apache/cordova-plugin-media/pull/12#issuecomment-74269271
Any updates on this being merged? Would love to use the latest version with
the background thread correction in a release I'm about to make to the app
stores :
Totally makes sense that when IAB is used as a dependency we wouldn't want
window.open() to be changed. Possibly we could add logic to do different
things when a plugin is a dependency vs. required explicitly, but I think
that might overcomplicate things.
I think it makes sense to keep require() f
Forgot to mention - The fix we talked about was the ability to set "project
name" independent of the display name (really for any platform). iOS actually
suffers from some of these same issues but unlike Java can handle Unicode
characters in filenames.
http://callback.markmail.org/thread/2iaoj
To be clear, CB-6511 fixes app names that are non-English which is clearly not
an edge case. For example, previous to this change it was impossible to build
an app for Android with a Chinese display name. You'll note Cordova
documentation is available in Chinese.
-Chuck
-Original Message--
For iOS you can use the new shared keychain, and for android you can
persist data to google drive to share across applications.
https://github.com/googledrive/appdatapreferences-android
Jay Proulx | computer scientist | aem engineering | office: 613.940.4052 |
mobile: 613 866 0732 | adobe system
Please someone fix this somehow :(
Is CB-6511 really important enough to cause this? It feels like an edge
case caused an issue for the majority.
- tommy
On 14 Feb 2015 12:32 am, "Connor Pearson" wrote:
> Hi all,
>
> I'm wondering what the status of CB-7827 is. It causes the APK and activity
>
Hi all,
I'm wondering what the status of CB-7827 is. It causes the APK and activity
name to be set to a hardcoded value. It's been open since October and has
more votes and watchers than any other Cordova bug.
According to the Android documentation (
http://android-developers.blogspot.com/2011/06
Open question: do we even need to clobber a symbol, or would
cordova.require('org.apache.cordova.iab').open() suffice?
Could we leave compatibility by default, but support opting-in to the
switch now? Perhaps a flag in the plugin and clobber window.open
from javascript only if a
is not set, ins
Is the documentation on https://github.com/apache/cordova-medic actual?
I tried to follow the installation instructions and I'm failing with no
cordova-config.json file
I'm on #cordova as well
Thanks
--
Piotr (zalun) Zalewa
Mozilla
-
61 matches
Mail list logo
