EAP version 1.31.0-dev
Moderator: Martin
Re: EAP version 1.31.0-dev
I prefer when it's a regular part of the script action since it will allow to easily modify values, loop over collections, check values with if/else etc.
It also allows to execute dynamic scripts, for example you could send a script by SMS to your device and "eval" the text.
It also allows to execute dynamic scripts, for example you could send a script by SMS to your device and "eval" the text.
Re: EAP version 1.31.0-dev
Wow, that java stuff is super exciting! I know it's still in development, so no rush, but do you think you might provide an example or two after release?
Re: EAP version 1.31.0-dev
Sure, I'll post some examples when time permits.
It's not the most useful example since the vibrator can be controlled using a regular action but it shows how the feature works:
It's not the most useful example since the vibrator can be controlled using a regular action but it shows how the feature works:
Code: Select all
vibrator = callJavaMethod(getContext(), "android.content.Context", "getSystemService(java.lang.String)", "vibrator");
callJavaMethod(vibrator, "android.os.Vibrator", "vibrate(long)", 1000);
Re: EAP version 1.31.0-dev
A new EAP version is available.
Changes in this update:
Regards,
Martin
Changes in this update:
- update release notes with missing entry: new action Init Variable Package Info
- minor changes and fixes
Regards,
Martin
Re: EAP version 1.31.0-dev
Hi Martin,
That reflection APi seems really promissing! Love it already! Could I add a small request to it? Although it might seem weird at first, but I think it could simplify things if you introduced a base type "string" (instead of "java.lang.String"). Since there are a lot of strings in method signatures, it could help writing less boiler-plate script-code. Here your example with the base-string:
Just of curiosity: will you also allow a callJavaStaticMethod() or getting of static object fields (e.g. Context.VIBRATOR_SERVICE)?
Thanks
Loris
That reflection APi seems really promissing! Love it already! Could I add a small request to it? Although it might seem weird at first, but I think it could simplify things if you introduced a base type "string" (instead of "java.lang.String"). Since there are a lot of strings in method signatures, it could help writing less boiler-plate script-code. Here your example with the base-string:
Code: Select all
vibrator = callJavaMethod(getContext(), "android.content.Context", "getSystemService(string)", "vibrator");
callJavaMethod(vibrator, "android.os.Vibrator", "vibrate(long)", 1000);
Thanks
Loris
Re: EAP version 1.31.0-dev
Hi again
Did you ever think of adding groovy support instead of creating you custom script language? You could add a couple of DSL extensions to access automagic things but make scripts be a full-fledged program. The reason I saying, is that at work, we mainly use java as our main programming language, but as soon as clients are allowed to interact, we let them do it through groovy scripts. It's the easiest for them to "write code" without being "too formal" about declarations
Loris
Did you ever think of adding groovy support instead of creating you custom script language? You could add a couple of DSL extensions to access automagic things but make scripts be a full-fledged program. The reason I saying, is that at work, we mainly use java as our main programming language, but as soon as clients are allowed to interact, we let them do it through groovy scripts. It's the easiest for them to "write code" without being "too formal" about declarations
Loris
Re: EAP version 1.31.0-dev
Hi Loris,
Automagic supports following java-functions in version 1.31:
callJavaStaticMethod
callJavaConstructor
callJavaMethod (for instance methods)
getJavaStaticField
setJavaStaticField
getJavaField (for instance fields)
setJavaField (for instance fields)
I was also thinking about supporting String directly instead of java.lang.String but I decided to go for the technically correct version since this has to work anyway and then later maybe add the shorthand version.
Adding support for Groovy or BeanShell could be a possibility, but I'm not sure if I want to go down that route since this would be a good thing to implement in a plugin. Not sure if ASE is still alive but it was very promising since it supported different languages: https://code.google.com/hosting/moved?p ... -scripting
Regards,
Martin
Automagic supports following java-functions in version 1.31:
callJavaStaticMethod
callJavaConstructor
callJavaMethod (for instance methods)
getJavaStaticField
setJavaStaticField
getJavaField (for instance fields)
setJavaField (for instance fields)
I was also thinking about supporting String directly instead of java.lang.String but I decided to go for the technically correct version since this has to work anyway and then later maybe add the shorthand version.
Adding support for Groovy or BeanShell could be a possibility, but I'm not sure if I want to go down that route since this would be a good thing to implement in a plugin. Not sure if ASE is still alive but it was very promising since it supported different languages: https://code.google.com/hosting/moved?p ... -scripting
Regards,
Martin
Re: EAP version 1.31.0-dev
Thanks for the clarification, Martin. With that in place, I can do "real" programming and not always bother you with CM feature requests . Just out of curiosity: How do you store global variables? Are they actual object references or are they marshalled/unmarshalled when accessed? The reason I'm asking is if I store am object created by callJavaConstructor in a global variable, would I be able to use it in another script? For example "globalPie = new java.math.BigDecimal('3.1415')" and later use it to do some arithmatic on that?
Re: EAP version 1.31.0-dev
Global variables actually are a regular in memory map (string->object) that holds the values so in theory you can assign almost everything to a global variable, however I would not recommend it since Automagic will try to store the global variables from time to time which does not work for all kind of objects. The script action shows a warning about global variables for exactly this reason when inserting a call to a java method.
The current implementation in Automagic will try to serialize values that are java.io.Serializable so things like BigDecimal should work OK. Storing non-serializable objects should log a warning message. The value in this case will be missing (set to null) when Automagic is started the next time since it was not capable to store the value.
The current implementation in Automagic will try to serialize values that are java.io.Serializable so things like BigDecimal should work OK. Storing non-serializable objects should log a warning message. The value in this case will be missing (set to null) when Automagic is started the next time since it was not capable to store the value.
Re: EAP version 1.31.0-dev
Thanks Martin for the clarifications. I can't wait to start writing some CM tweaks . You're the best!