I'm trying to start firefox form a Java program, so far i know how to do that with option as well. But i'm interested in send a specific argument so a javascript add-on could obtain it.
For example, i use the command Runtime.getRuntime().exec("/usr/bin/firefox") to start firefox, my goal is to use something like Runtime.getRuntime().exec("/usr/bin/firefox 12345"), where 12345 is my argument and obtain it via a simple add-on.
Is this possible at all? is there another method/way to pass an argument to an add-on on firefox start?
Thanks in advance.
Start firefox with a url that contains your argument.
Use it as Runtime.getRuntime().exec(new String[] {"/usr/bin/firefox", "12345"})
Can't tell you how to get that argument in your Firefox add-on. Maybe modifying your question if that's what you're mainly asking?
I think your functionality would break the security model of firefox. but there are commands that you can use, http://www.binaryturf.com/lesser-firefox-command-line-options/
In first thank you all for your answers, all of you help me to get this work done. After some more research and thinking of some security issues, i end up using the Java process builder adding an environment variable with the value i want:
//Initiates the process i'm about to start.
ProcessBuilder pb = new ProcessBuilder(args);
//Gets the system environment.
Map<String, String> env = pb.environment();
//Register VAR with value Value as an evironment variable in this process context
env.put("VAR", "Value");
//Stats the process initiated in the 1st line.
pb.start();
So with this i can run an application and have environment variables on it's context, now i just want to access them in my JavaScript add-on, simply with this:
var env = Components.classes["#mozilla.org/process/environment;1"].getService(Components.interfaces.nsiEnvironment);
var X = env.get('VAR');
where X will have the value in the environment variable VAR (previous defined in the Java code);
Related
I am launching a JNLP java application from a native client app (i.e. not a browser). When the JNLP finishes it's task, I need it to return a string to the calling app? How can I do this? Is it possible to return a value to a calling app - or do I need to have the calling app listen on a port and have the JNLP app write the value to that port through sockets?
Answering my own question!
I write to stdout from the child process (the JNLP)
The parent launches the child process
Process::Start
Read stdout from Parent
string ret = process.StandardOutput.ReadToEnd();
Process::WaitForExit();
Anyone sees any problem in this?
I like your idea to use sockets and think this is could be an easy solution.
It is not possible to get return values from a WebStart-application. Just see the help message from
javaws --help
There is no return-code available. (Sorry)
Have you thougth on a temporary file instead of the sockets?
It's a bit old but as fas as i know this is the exiting options to intercommunicate two process link.
I think the easiest way to solve your problem is use rmi, or jmx if you can, or just a simple socket
If the all-permissions element is specified, you could try to set an environment variable which you can read from your C# application.
Set environment variable in Java:
System.getenv().put("returnValue", "yourValue");
Read environment variable in C#:
ProcessStartInfo p = new ProcessStartInfo("start ....");
....
string returnValue = p.EnvironmentVariables["returnValue"];
I'm currently testing an application using Appium on an android device (appium version: 1.2.4.1, java-client: 2.1.0). I'm using the following code to send some text in a textField:
driver.findElement(By.name("Name")).sendKeys("My Name");
and it works fine just it takes it too long to actually send the text on the textbox (usually 7 seconds). I was wondering does anybody know another way to send text on a textField that takes less?
Thanks!
I solved this issue by using adb to send text instead of appium!It is really fast!
try {
textElement.click();
new ProcessBuilder(new String[]{"adb", "-s", "YOURDEVICEUUID", "shell", "input", "text", "YOURTEXTASINPUT"})
.redirectErrorStream(true)
.start();
} catch (IOException e) {
e.printStackTrace();
}
Same way you may use this for Click,clear,install,uninstall etc.. there may be some need to sleep thread for sync issues but it is only 50ms which is too less than 5 seconds which appium takes!
You may use DDMLIB to make this adb call instead of ProcessBuilder!
Try :
driver.findElement(By.name("Name")).Click();
driver.Keyboard.SendKeys("My Name");
This should run faster then your method.
This capabilities helped me to reduce the time of inputs on Android
desiredCapabilities.setCapability("ignoreUnimportantViews", true);
desiredCapabilities.setCapability("disableAndroidWatchers", true);
You can find more here https://appium.io/docs/en/writing-running-appium/caps/#android-only
Experiencing slow automation on Appium is common because Appium is based on a client/server architecture. Network issues can influence the performance of a test (unless you are running your test in the same machine where Appium is installed).
I can tell you that I have also experienced problems with slow tests on Appium. It usually happens on simulators/emulators by the way.
Send keys as part of a UX scenario
If your test needs to send keys as part of a User Experience scenario, then SendKeys is your only option. This method does not simply set a value in a textbox, it actually behaves like a user pressing keys and sending keys to a textbox.
If this is what you need, then you need to understand what is happening a network level because this is what your problem is about. Also consider that this method can be slow on its own sometimes (this is my experience).
Setting a text is not important for the UX scenario being tested
In case the step of setting a textbox's value is not a core part of your automation for the specific test being considered, you an always do achieve this by means of ExecuteScript which lets you execute a Javascript code in your app. I am assuming you are automating the WebView context.
int result = driver.executeScript("
try {
var el = document.getElementById('<your-txtbox-id-here>');
el.value = '<your-text-here>';
return 0;
} catch {
return 1;
}
");
Java does not support multiline strings so the previous is a prettyprint of the following:
int result = driver.executeScript("try{var el = document.getElementById('<your-txtbox-id-here>');el.value = '<your-text-here>';return 0;}catch{return 1;}");
This method will return 0 in case the string was successfully set, otherwise 1. It should be faster because the driver will not send each key separately but execute the script in an anonymous function and get back its return value.
Try to add the following capabilities inorder to have appium keyboard(and not the physical keyboard)
capabilities.setCapability("resetKeyboard", true);
capabilities.setCapability("unicodeKeyboard", true);
Replace sendKeys with the setValue method available in later versions of appium:
driver.findElement(By.name("Name")).setValue("My Name");
It is much faster in my experience.
For new commer, in the Appium version 1.9~, both method executeJavaScript() & setValue() works so good, and you can consider to use it.
// use js
executeJavaScript("$('#" + fieldId + "').val(testData);
// use setValue
$(By.id(fieldId)).setValue(testData);
I improved the speed of my test (written in Python) using:
driver.set_value(myElement, "My Name")
instead of:
webElement.send_keys("My Name")
If you are using Java, it will be something similar to:
driver.setValue(driver.findElement(By.name("Name")), "My Name")
Another approach could be with adb... (This is the fastest one but you have to use another thing besides appium)
//1st - Click at your WebElement
driver.click(driver.findElement(By.name("Name")))
//2nd - Using adb send your text
//adb shell input text "My Name"
adb shell input keyboard text "My Name"
I'm trying to create a simple argument parser using commons-cli and I can't seem to figure out how to create the following options:
java ... com.my.path.to.MyClass producer
java ... com.my.path.to.MyClass consumer -j 8
The first argument to my program should be either producer or consumer, defining the mode which my program will run in. If it's in consumer mode, I'd like to have a -j argument which defines how many threads to service with.
Here's what I've got so far:
Options options = new Options();
options.addOption("mode", false, "Things.");
HelpFormatter formatter = new HelpFormatter();
formatter.printHelp("startup.sh", options);
When I print out these options, the mode parameter shows up as -mode.
In Python's argparse, I'd just do the following:
parser = argparse.ArgumentParser()
parser.add_argument('mode', choices=('producer', 'consumer'), required=True)
parser.print_help()
This does exactly what I'm looking for. How can I do this in commons-cli?
What I've done for things like this is to have separate Options for each class. In your main, check the first argument to decide which list to pass to the parser. FWIW, I don't consider it "hack" solution.
JCommander is the answer. commons-cli doesn't seem to support these options.
picocli is now included in Groovy 2.5.x. It has built-in support for subcommands.
enix12enix has written a standalone sikuli server to remotely initiate sikuli scripts. I have the server running and I'm now trying to pass values along with the url. I imagine it will look something like this :
http://server:9000/test.do?script=/yourscript&argv[1]=arg1value
Everything before the & works properly as it stands. I know the answer is somewhere in the java found here:
https://github.com/enix12enix/sikuliserver/blob/master/java/src/org/sikuli/SikuliScriptParamProcessor.java
As there is a function called extractparameters. Can anyone help figure out the syntax for the url?
Thanks a lot,
Jacob
According to the pattern that's used to check if the name of the params are correct, you should send the params with this format: argv## (1-99). So instead of sending argv[1] in the url you should be argv1.
Thanks Jair, I figured out how to reference this within the Sikuli script as well. I imagine that those familiar with Java / Python / Jython are already aware of this, but I am just a noob setting up a remote Sikuli server.
Parameters can be passed through the url as follows:
http://server:9000/test.do?script=/yourScriptName.sikuli&argv1=value1&argv2=value2
and so on, through argv99.
Normally, while running a script from the command line (--args value1 value2) , you would reference the argument within the Sikuli script like this:
import sys
var1 = sys.argv[1]
var2 = sys.argv[2]
While working with the java side of things, the reference is a little different:
import java
var1 = java.lang.System.getProperty('argv1')
var2 = java.lang.System.getProperty('argv2')
And so on.
I am using JNA to use user32.dll and kernel32.dll . I have the sample code which can give me the handle if i specify the title of the process.
hWnd = User32.FindWindowA(null, "Call of Duty®: Modern Warfare® 3 Multiplayer");
I really don't want to search for the process handle by the Title . Is there any method which takes the exe name? Like this:
hWnd = User32.FindWindowByExecutable ( "iw5mp.exe" );
So that, it will return 0 if this process is not running otherwise the handle.
Also, the thing is when using JNA, eclipse obviously can't auto suggest the methods present in User32 or Kernel32 dll. So, what do you do in such cases. Just google the probable method ?
With Java 9, thanks to JEP 102, it will be possible to obtain a handle of the process given an executable name, with the new ProcessHandle interface:
Optional<ProcessHandle> findByExactCommand(String command) {
return ProcessHandle.allProcesses().filter(process -> {
Optional<String> cmd = process.info().command();
return cmd.isPresent() && cmd.get().equals(command);
}).findFirst();
}
Literally answering question in title, ignoring JNA aspects, but reading comments it seems that was OP was after:
I don't think there is anything like Process.GetProcesses in java
Well, now there is ;)
String passed to FindWindow() as a second parameter is NOT title of the process. It is title of some window instead. And value returned by FindWindow() is (surprise!) handle of the window, not process handle.
If title of window you want to find may change i suggest you search window by their class name (first argument of FindWindow) leaving second argument null.
Class of windows application window may be determined by Microsoft Spy++ or similar software.