Another reasonable approach would be to use a Map<String, 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 = 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
>
