Re: CB-5921
On 16 Sep,2014, at 20:07 , Shazron shaz...@gmail.com wrote: Thanks Erik, I'll take a look soon. As long as it addresses the points I've been making in the issue (wrt plugins) it would be fine -- the target is by 4.0 release It doesn’t do that yet, but I’m working on it. Expect a PR for that soon I would think for using workspaces. Yes, Swift is only supported with iOS 7 and up, so a Swift developed plugin needs to have as an engine tag value the Cordova release that supports iOS 7 and up. When users want to use swift for developing plugins we could have a xcconfig that changes the target, maybe? We haven't broached the subject of dropping iOS 6 support, but generally we do only want to support the current and previous iOS release -- but we'll let the list know if there are any concerns. That will be iOS 8 and 7 soon :)
cordova push plugin release
Hi all, After testing we are happy to announce that the 1.0.1 version of the cordova push plugin has been released. Thanks to everyone for testing and making this release happen. The reason for this point release was an error in the android dependencies of the plugin making it unusable. Happy coding, Erik Jan
CB-5921
Hi, I’ve started to work on https://issues.apache.org/jira/browse/CB-5921 and create a PR https://github.com/apache/cordova-ios/pull/104 that will generate a workspace instead of a subproject. Next step is to look how to integrate this with cli and maybe change how cli does changes to the project ( use xconfig files instead of changing pbxpoj ) Cheers, Erik Jan
Re: cordova push plugin release
Ultimate goal is to enable swift as a language to create plugins with On 16 Sep,2014, at 11:41 , Erik Jan de Wit ede...@redhat.com wrote: Hi all, After testing we are happy to announce that the 1.0.1 version of the cordova push plugin has been released. Thanks to everyone for testing and making this release happen. The reason for this point release was an error in the android dependencies of the plugin making it unusable. Happy coding, Erik Jan
Re: CB-5921
Ultimate goal is to enable swift as a language to create plugins with On 16 Sep,2014, at 14:43 , Erik Jan de Wit ede...@redhat.com wrote: Hi, I’ve started to work on https://issues.apache.org/jira/browse/CB-5921 and create a PR https://github.com/apache/cordova-ios/pull/104 that will generate a workspace instead of a subproject. Next step is to look how to integrate this with cli and maybe change how cli does changes to the project ( use xconfig files instead of changing pbxpoj ) Cheers, Erik Jan
plugin with swift
Hi all,
I’ve been experimenting with swift and ported the HelloWorld plugin [1] to
Swift. There was one trick to make it work together with cordova, that was to
specify the name of the class to export it under so it could be referenced:
@objc(HWPHello) class Hello : CDVPlugin {
Then it’s ‘exported’ under “HWPHello” that is what we put into the plugin.xml
that can then be found at runtime by cordova
There remains one problem in order to use CDVPlugin in Swift one needs to add a
bridging header file and add that to the swift compiler options. The file can
be part of the plugin but can cordova on plugin install add the needed compiler
settings?
[1] https://github.com/edewit/cordova-plugin-hello/tree/swift
Re: Android Plugin API
Hi all,
Created an plugin that does this:
https://github.com/edewit/aerogear-reflect-cordova the repository also includes
a example plugin that uses this. Also have a blog describing this a bit more
http://blog.nerdin.ch/2014/07/improved-cordova-android-plugin-api.html
Cheers,
Erik Jan
On 2 Jun,2014, at 4:20 , Terence M. Bandoian tere...@tmbsw.com wrote:
It does get complicated in a hurry. Using the technique in the Google Maps
plugin:
- getDeclaredMethod is documented to NOT return inherited methods which
limits exposure
- the signature passed to getDeclaredMethod also limits exposure
- annotations, as Andrew suggested, could further limit exposure
- getDeclaredMethod is documented to return private methods which for me
raises questions
- setAccessible(true) suppresses normal access checking which also raises
questions
- invoke throws InvocationTargetException so exceptions thrown by the invoked
method could be publicized
- invoke applies overriding which is probably a wash
- invoke returns an object which would have to be handled correctly
Quite a bit to consider.
-Terence Bandoian
On 5/29/2014 11:44 PM, Joe Bowser wrote:
On Thu, May 29, 2014 at 9:26 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:
Please correct me if I'm wrong but, as I understand it, the vulnerability
stems from injecting a Java object into the WebView which, in API levels 16
and below, exposed all of the public methods of the object (small 'o')
including the methods inherited from the Object class.
Yes, you are correct in this case. You can basically use the object
methods to reflect into whatever you want. Once you have a single
class exposed in this manner, you can then reflect into it, and
basically you're done. The reason we don't use reflection is that
it's very easy to reflect into things you're not supposed to be in.
IMO, It wouldn't be hard to do this if we exposed plugins in the same
way. Right now this is an Android Vulnerability, but if we start
using reflection for plugins, we could very quickly end up making a
similar Cordova exploit if we're not careful.
This is also why we use the prompt bridge on API levels below 17.
On 5/28/2014 9:54 AM, Joe Bowser wrote:
In case anyone is curious, here's why we minimize reflection:
https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/
On Wed, May 28, 2014 at 7:33 AM, Andrew Grieve agri...@chromium.org
wrote:
Another reasonable approach would be to use a MapString, Runnable, but
that can be implemented on top of what is currently exposed. I'm quite
wary
of Reflection as well.
On Wed, May 28, 2014 at 10:06 AM, Joe Bowser bows...@gmail.com wrote:
The execute command exists for security reasons. We don't want any
methods other than execute exposed to Javascript. I also prefer this
approach because it is less prone to less catastrophic bugs than using
Java reflection. We try and only use reflection when we have to.
On Wed, May 28, 2014 at 5:50 AM, Erik Jan de Wit ede...@redhat.com
wrote:
Hi,
When one is writing a plugin for android ATM the api that you have to
implement has a execute method that has the action as a string:
@Override
public boolean execute(String action, JSONArray args,
CallbackContext callbackContext) throws JSONException {
if (beep.equals(action)) {
this.beep(args.getLong(0));
callbackContext.success();
return true;
}
return false; // Returning false results in a
MethodNotFound
error.
}
When you have multiple actions this method gets very long, if you
compare this with iOS here you don’t need a method like this you could
‘just’ implement the method directly:
- (void)beep:(CDVInvokedUrlCommand*)command
{
CDVPluginResult* pluginResult =;
NSString* myarg =mmand.arguments objectAtIndex:0];
if (myarg !=) {
pluginResult �VPluginResult
resultWithStatus:CDVCommandStatus_OK];
} else {
pluginResult �VPluginResult
resultWithStatus:CDVCommandStatus_ERROR messageAsString:@Arg was
null];
}
[self.commandDelegate sendPluginResult:pluginResult
callbackId:command.callbackId];
}
We could do the same thing for android if we use reflection, making the
API more similar and removing all the string test by the user. What do
you
think?
Cheers,
Erik Jan
Re: Android Plugin API
On 10 Jul,2014, at 17:15 , Anis KADRI anis.ka...@gmail.com wrote: I want to say that this should be default...but we won't change the API again and won't break plugins again. Both could be supported at the same time, just by using a different base class
Re: Android Plugin API
On 28 May,2014, at 22:07 , Shazron shaz...@gmail.com wrote: https://github.com/apache/cordova-ios/blob/50ca482c8e861c1aa480dadba726b1abbacbc0e1/CordovaLib/Classes/CDVCommandQueue.m#L193-L198 Right thanks, that is how I expected it to work, so why not use the same logic in Android as on iOS? In Java one can also find a method based on the action name and invoke it. I would say it’s less error prone then doing string comparison yourself. On Wed, May 28, 2014 at 12:05 PM, Erik Jan de Wit ede...@redhat.com wrote: I don't know, it very much could be. It could be that this makes sense in Obj-C but not in Java based on how they handle NoSuchMethod. I'd prefer to not have to rely on an exception being caught, especially since it could suppress other exceptions being thrown that I want to know about. Sending a message (calling a method) in object-c for a method that doesn’t exist will also throw an exception, I haven’t looked at the implementation but I would suspect that there is a test to see if the method (selector) is there. Also, I'm assuming the exception is NoSuchMethod, which isn't a safe assumption given that each device has their own quirks and this isn't guaranteed. One could just lookup if the method exist and not just try to invoke it and wait for the NoSuchMethod. That way one could make the error handling nicer, for example: You have a method called ‘myAction’ but it does not have the proper method signature! Found public void myAction() but should be pubic PluginResult myAction(JSONArray, CallbackContext)
Re: Android Plugin API
I could build a little prototype that shows what I’m talking about, how does that sound?
Re: Android Plugin API
What is the benefit of using this logic? I personally don't see any benefit, since this makes our code more complex. It would benefit the users as they don’t have to implement this boilerplate code of dispatching based on the string. And this logic will be then on the android side where it’s implemented once instead of each time one is building a plugin.
Android Plugin API
Hi,
When one is writing a plugin for android ATM the api that you have to implement
has a execute method that has the action as a string:
@Override
public boolean execute(String action, JSONArray args, CallbackContext
callbackContext) throws JSONException {
if (beep.equals(action)) {
this.beep(args.getLong(0));
callbackContext.success();
return true;
}
return false; // Returning false results in a MethodNotFound error.
}
When you have multiple actions this method gets very long, if you compare this
with iOS here you don’t need a method like this you could ‘just’ implement the
method directly:
- (void)beep:(CDVInvokedUrlCommand*)command
{
CDVPluginResult* pluginResult = nil;
NSString* myarg = [command.arguments objectAtIndex:0];
if (myarg != nil) {
pluginResult = [CDVPluginResult
resultWithStatus:CDVCommandStatus_OK];
} else {
pluginResult = [CDVPluginResult
resultWithStatus:CDVCommandStatus_ERROR messageAsString:@Arg was null];
}
[self.commandDelegate sendPluginResult:pluginResult
callbackId:command.callbackId];
}
We could do the same thing for android if we use reflection, making the API
more similar and removing all the string test by the user. What do you think?
Cheers,
Erik Jan
Re: Android Plugin API
On 28 May,2014, at 19:06 , Joe Bowser bows...@gmail.com wrote: We don't want this pattern for Android because it is also more bug prone. Doesn’t the same hold true for iOS? On May 28, 2014 8:28 AM, Erik Jan de Wit ede...@redhat.com wrote: So this security issue is only a problem if you are able to inject some arbitrary js code. If your app ships with it’s own html and js this is very hard to do. No, it's not. Any trusted input could have the potential to inject JS. We're not even touching on the third-party ad networks code, frameworks or other code that developers add on a regular basis. Still in the example android permits any method to be executed (getClass) there could be checks. For instance only public methods that have a JSONArray and a CallbackContext as parameters and have the name of the action. That way you can’t inject any arbitrary code. If a user implements the wrong method the error logging can be in a way that one can easily correct the issue, because of these checks.
Re: Android Plugin API
I don't know, it very much could be. It could be that this makes sense in Obj-C but not in Java based on how they handle NoSuchMethod. I'd prefer to not have to rely on an exception being caught, especially since it could suppress other exceptions being thrown that I want to know about. Sending a message (calling a method) in object-c for a method that doesn’t exist will also throw an exception, I haven’t looked at the implementation but I would suspect that there is a test to see if the method (selector) is there. Also, I'm assuming the exception is NoSuchMethod, which isn't a safe assumption given that each device has their own quirks and this isn't guaranteed. One could just lookup if the method exist and not just try to invoke it and wait for the NoSuchMethod. That way one could make the error handling nicer, for example: You have a method called ‘myAction’ but it does not have the proper method signature! Found public void myAction() but should be pubic PluginResult myAction(JSONArray, CallbackContext)
Re: callback success STATUS OK
+1 for removing this This behaviour is also not the same on all platforms I’ve noticed that on iOS “OK” is passed, but not on android On 27 Feb,2014, at 8:35 , Ally Ogilvie aogil...@wizcorp.jp wrote: Since the very beginning a success callback without message (native args) has returned the string OK to the success function in JavaScript. I think there is no reason for this to be. I think the reason it's there is because it's been there from the beginning. But we should get rid of this now. Looking for some agreement (+1) on this before chalking it up on the todo list. Thanks. Ally.
Re: CB-4846
Hi Shazron, Actually I started out building it this way, I’ve changed it to way it’s now, because it didn’t work. Once the application has moved to the background trying to invoke the method with the plugin result no longer works. I’ve seen other plugins use the ‘named’ callback ’trick’ and thought that was the way to invoke a callback from background. Shall I try to investigate why this is not working? Cheers, Erik Jan On 24 Feb,2014, at 19:36 , Shazron shaz...@gmail.com wrote: Hi Erik, The gist of it is here: http://cordova.apache.org/docs/en/3.4.0/guide_platforms_ios_plugin.md.html#iOS%20Plugins Basically, you have to modify your js interface to take in a success and failure callback. Then, in native code you create a PluginResult and set it to a specific command status (CDVCommandStatus_*), then send it back through the commandDelegate - it will figure out how to route it properly. There are examples in the link above. On Sun, Feb 23, 2014 at 11:38 PM, Erik Jan de Wit ede...@redhat.com wrote: On 22 Feb,2014, at 0:01 , Shazron shaz...@gmail.com wrote: Joe - this calls a background fetch handler for your app at an interval, it doesn't really run in the background. Erik - just a quick code review: 1. The method swizzling stuff is great but what I have planned (sometime in the future, in progress) is this: https://issues.apache.org/jira/browse/CB-5601 Ahh cool, I'll keep an eye on that one. 2. The way you are using callbacks is not quite correct Could you elaborate on that, I'll be more then happy to fix it Agree on it being a user space plugin -- but I was thinking it could be in cordova-plugins maybe when the time comes I would love for it to be a cordova core plugin On Fri, Feb 21, 2014 at 1:47 PM, Joe Bowser bows...@gmail.com wrote: Is this actually running a service? I thought this just runs a Cordova App in the background, which Android already has a setting for. On Fri, Feb 21, 2014 at 1:44 PM, Brian LeRoux b...@brian.io wrote: I think its cool as a user space plugin for now though. Have you published it to http://plugins.cordova.io ? (Its just like npm / you can read up on how here: https://github.com/apache/cordova-plugman) I really like the idea of us looking at background processing. Android services: how would that work? Does Firefox OS have the concept of background services? I know Chrome Mobile Apps guys have been doing some thinking here too. On Fri, Feb 21, 2014 at 2:53 AM, Erik Jan de Wit ede...@redhat.com wrote: Hi, I've created an initial version for https://issues.apache.org/jira/browse/CB-4846 the plugin is located at https://github.com/edewit/cordova-background-plugin Cheers, Erik Jan
Re: CB-4846
This sounds to me like somehow the callbackIDs are out of sync. missing a keepCallback? Right that was it, I thought it had something to do with it being in the background but it was a simple mistake. Fixed it now looks much nicer
Re: CB-4846
On 22 Feb,2014, at 0:01 , Shazron shaz...@gmail.com wrote: Joe - this calls a background fetch handler for your app at an interval, it doesn't really run in the background. Erik - just a quick code review: 1. The method swizzling stuff is great but what I have planned (sometime in the future, in progress) is this: https://issues.apache.org/jira/browse/CB-5601 Ahh cool, I’ll keep an eye on that one. 2. The way you are using callbacks is not quite correct Could you elaborate on that, I’ll be more then happy to fix it Agree on it being a user space plugin -- but I was thinking it could be in cordova-plugins maybe when the time comes I would love for it to be a cordova core plugin On Fri, Feb 21, 2014 at 1:47 PM, Joe Bowser bows...@gmail.com wrote: Is this actually running a service? I thought this just runs a Cordova App in the background, which Android already has a setting for. On Fri, Feb 21, 2014 at 1:44 PM, Brian LeRoux b...@brian.io wrote: I think its cool as a user space plugin for now though. Have you published it to http://plugins.cordova.io ? (Its just like npm / you can read up on how here: https://github.com/apache/cordova-plugman) I really like the idea of us looking at background processing. Android services: how would that work? Does Firefox OS have the concept of background services? I know Chrome Mobile Apps guys have been doing some thinking here too. On Fri, Feb 21, 2014 at 2:53 AM, Erik Jan de Wit ede...@redhat.com wrote: Hi, I've created an initial version for https://issues.apache.org/jira/browse/CB-4846 the plugin is located at https://github.com/edewit/cordova-background-plugin Cheers, Erik Jan
CB-4846
Hi, I’ve created an initial version for https://issues.apache.org/jira/browse/CB-4846 the plugin is located at https://github.com/edewit/cordova-background-plugin Cheers, Erik Jan
Re: Something up with plugins.cordova.io?
Still something strange going on, there is no way to search! Cheers, Erik Jan On 9 Jan,2014, at 2:18 , Andrew Grieve agri...@chromium.org wrote: Awesome, thanks Steve. On Wed, Jan 8, 2014 at 3:27 PM, Steven Gill stevengil...@gmail.com wrote: I just tried to publish it and it worked. Seems to be updated on the site now. http://plugins.cordova.io/#/org.apache.cordova.device On Wed, Jan 8, 2014 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: I did a plugins release 6 days ago that all seemed to go fine. But yesterday I tried to do a point release for the device plugin and it seems wonky. I published 0.2.7 of the plugin, but it still says 0.2.6 is latest on: http://plugins.cordova.io/#/org.apache.cordova.device (tried re-publishing a few times) If I try to install it via command line, It installs v0.2.6 What I did to publish: cd cordova-plugin-device git checkout master plugman publish . Any ideas?
library use in plugins
Hi, I'm a member of the AeroGear team and we have created a number of plugins that enable the use of our native libs for cordova development. Now the question is how to use libraries with a plugin. Right now our iOS projects use cocaopods, I think is the most ideal way as this is just a source dependency like the plugin dependency. Only downside to this approach is that it requires to execute a pod install after plugin installation. More problems are with android, right now we've used a jar file and put it in the plugin.xml as a source with target lib. Are there alternatives to use libraries in a plugin? And if not are there plans to create some support for this, and what about phonegap build, we would like to post our plugins there as well. Looking forward to your thoughts, Erik Jan
Re: Cordova Plugins and CocoaPods
Hi, This is cool don't get me wrong, but it's just the other way around. With this, one could create a cordova application using CocoaPods, but I want to have a plugin that uses some CocoaPods libraries. Then it would be nice to add a PodFile to your plugin directory and have the cli 'install' these dependencies for you. On 2 Nov,2013, at 1:39 , Shazron shaz...@gmail.com wrote: The core and core plugins are cocoapods already, see the list (search for 'Cordova'): https://github.com/CocoaPods/Specs Someone is maintaining them, modifying the specs for them as versions go out: https://github.com/CocoaPods/Specs/pull/4539 On Thu, Oct 31, 2013 at 8:11 AM, Don Coleman don.cole...@gmail.com wrote: I have some iOS code that we are converting into a Cordova plugin. The project uses CocoaPods to manage dependencies. Have you see any Cordova plugins that use CocoaPods or can you think of a way to make CLI and CocoaPods play nice together?
Re: Cordova Plugins and CocoaPods
The AeroGear-PushPlugin uses cocoa pods, what would be nice is to be able to include a pod install into the CLI. On 31 Oct,2013, at 16:11 , Don Coleman don.cole...@gmail.com wrote: I have some iOS code that we are converting into a Cordova plugin. The project uses CocoaPods to manage dependencies. Have you see any Cordova plugins that use CocoaPods or can you think of a way to make CLI and CocoaPods play nice together?
Re: config.xml discussion, we need to talk
On the topic of IDE support my collage Gorkem has made a nice wizard in eclipse that mimics the CLI have a look at this video http://www.youtube.com/watch?v=QUyUUtmTYok On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote: Great Bryan Totally agree !!! Cordialement. --- Maxime LUCE - Somatic maxime.l...@somatic.fr 06 28 60 72 34 De : Brian LeRouxmailto:b...@brian.io Envoyé : 18/10/2013 01:48 À : dev@cordova.apache.orgmailto:dev@cordova.apache.org Objet : Re: config.xml discussion, we need to talk I don't really appreciate comments that we don't talk to our users, or build apps in anger. Neither of those assertions are true. The origins of these initiatives are based on both community feedback, and direct experience. Keeping your focus on just pure platform side of a project is fine, of course, since the CLI delegates to the platform. This was also a deliberate learning from MANY attempts at an architecture that satisfies both approaches. It separates the concerns and respects the platform will be canonical for the common workflows supported. This is a very real example of Conway's Law btw. [1] Anyhow. Deep breath! Software has bugs, people will report them, and we'll continue to improve. This is a very large group with a very diverse community that spans regular old hackers to the humble web designers. We need to respect that, and maybe be a little more compassionate to each other too. All software is fucked up, and at the end of the day, it is our perpetual job to make it a little less fucked up. [1] http://en.wikipedia.org/wiki/Conway's_law [Inline image 1] On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams to...@devgeeks.orgmailto:to...@devgeeks.org wrote: Late to the party due to timezone fun, but I just want to chime in in support of the CLI. As a dev working on an actual nontrivial real world app, I would like to let it be known that we (SpiderOak) have been heavy drinkers of the CLI Kool-Aid since its infancy. We have even managed to get to the point where ./platforms/**/* is just a build artefact (mostly by using hooks and tying the whole thing together with Grunt). We have a fast and fairly complex app (both many core plugins as well and a few custom/third party ones), that even includes the ability to white label it with relative ease. I feel pretty strongly in favour of the CLI and strongly advocate its use when asked in the #phonegap IRC channel. Just my opinion, but thought it was important to add to the discussion. - tommy / devgeeks On 18 Oct 2013 04:44, Anis KADRI anis.ka...@gmail.commailto:anis.ka...@gmail.com wrote: Sweet. So I think we all agree (expect Joe perhaps?) that both approaches should be supported :-) On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana csantan...@gmail.commailto:csantan...@gmail.com wrote: I meant in addition of .cordova/lib also allow also to do something like cordova platform add ios --path=./cordova_components/cordova-ios On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana csantan...@gmail.commailto:csantan...@gmail.com wrote: ++1 to install from a given directory instead of .cordova/libs. On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.netmailto:vi...@users.sourceforge.net wrote: This might be true - it took me quite some time to figure out how the CLI actually works - despite also having to fix one or two bugs for the WPX implementation of the CLI code (as well as the Windows 8 CLI code). But still I would hate to see the CLI go, since I think once you are used to it, it saves you quite a lot of time (I still have those old documents which guide me through the setup of the IDE projects for the different platforms - which is now mostly obsolete). So I guess supporting both methods is the way to go... :) Best, Wolfgang Am 2013-10-17 16:13, schrieb Michal Mocny: Thanks so much for chiming in, I'm very happy to see that you've figured out how to leverage the benefits and avoid the drawbacks of the new workflow, and that it has led to increased productivity for you. I do think that perhaps it is still too difficult for every developer to learn what you already have. -Michal On Thu, Oct 17, 2013 at 12:13 AM, Viras vi...@users.sourceforge.netmailto:vi...@users.sourceforge.net wrote: my view on this discussion: I've used the CLI to release the latest version of GOFG Sports Computer for Windows Phone. The support for the merges directory is a fantastic feature which allows me to focus on the javascript code using e.g. the NetBeans IDE - I can finally handle all my platform specific code from JavaScript in one consistent directory structure - which is what Cordova should be about. In addition the CLI forces you to write clean code (not implying that the other method forces to write
