I was looking at this question JavaFX show dialogue after thread task is completed, but my question is kind of the opposite. What is the best way to thread off after a filechooser or alert where you need some data back from the user?
Here's what I have now:
Platform.runLater(()->{
File file = fileChooser.showOpenDialog(root.getScene().getWindow());
if(file == null) {
return;
}
executorService.execute(()->{
//more code here which uses file
});
});
where executorService is an ExecutorService that was made earlier. I suppose I could just as easily use a Task or a Thread or anything else, but how it's threaded off doesn't matter, just that it's something that takes a while that I don't want to have happen on the Application thread because it would lock up the UI.
I know this isn't an mvce, but I hope it demonstrates the problem I'm having with threads inside Platform.runLater calls.
Here's an extreme example of how convoluted this kind of thing gets
#FXML
public void copyFiles(ActionEvent event){
//this method is on the application thread because a button or something started it
// so we thread off here
executorService.execute(()->{
// do some stuff
// ...
// get location to copy to from user
// must happen on the application thread!
Platform.runLater(()->{
File file = fileChooser.showOpenDialog(root.getScene().getWindow());
if(file == null) {
return;
}
executorService.execute(()->{
// more code here which uses file
// ...
// oh wait, some files have the same names!
// we need a user's confirmation before proceeding
Platform.runLater(()->{
Alert alert = new Alert(AlertType.CONFIRMATION, "Do you want to overwrite files with the same names?", ButtonType.OK, ButtonType.CANCEL);
Optional<ButtonType> choice = alert.showAndWait();
if(choice.isPresent && choice.get == ButtonType.OK){
// do something, but not on the application thread
executorService.execute(()->{
// do the last of the copying
// ...
});
}
});
});
});
});
}
If you need to do something on the UI thread that returns a result, create a FutureTask, submit it the UI thread, and then on the background thread wait for it to complete. This allows you to "flatten" the code.
You can also abstract Platform.runLater(...) as an Executor (after all, it is just something that executes Runnables), which can make it (perhaps) slightly cleaner.
By dividing up into smaller methods (and generally just using other standard programming techniques), you can make the code pretty clean.
Here's the basic idea (you'll need to add exception handling, or create a Callable (which can throw an exception) instead of a Runnable):
#FXML
public void copyFiles(ActionEvent event){
Executor uiExec = Platform::runLater ;
//this method is on the application thread because a button or something started it
// so we thread off here
Callable<Void> backgroundTask = () -> {
doFirstTimeConsumingThing();
FutureTask<File> getUserFile = new FutureTask<>(this::getUserFile) ;
uiExec.execute(getUserFile);
File file = getUserFile.get();
if (file == null) return null ;
doAnotherTimeConsumingThing(file);
FutureTask<Boolean> getUserConfirmation = new FutureTask<>(this::showConfirmation);
uiExec.execute(getUserConfirmation);
if (! getUserConfirmation.get()) return null ;
doMoreTimeConsumingStuff();
// etc...
return null ;
};
executorService.execute(backgroundTask);
}
private File getUserFile() {
return fileChooser.showOpenDialog(root.getScene().getWindow());
}
private Boolean getUserConfirmation() {
Alert alert = new Alert(AlertType.CONFIRMATION, "Do you want to overwrite files with the same names?", ButtonType.OK, ButtonType.CANCEL);
return alert.showAndWait()
.filter(ButtonType.OK::equals)
.isPresent();
}
private void doFirstTimeConsumingThing() {
// ...
}
private void doAnotherTimeConsumingThing(File file) {
// ....
}
private void doMoreTimeConsumingStuff() {
// ...
}
It seems your issue is needing information in the middle of a background task that can only be retrieved while on the JavaFX Application thread. The answer given by James_D works perfectly for this using FutureTask. I'd like to offer an alternative: CompletableFuture (added in Java 8).
public void copyFiles(ActionEvent event) {
executorService.execute(() -> {
// This uses CompletableFuture.supplyAsync(Supplier, Executor)
// need file from user
File file = CompletableFuture.supplyAsync(() -> {
// show FileChooser dialog and return result
}, Platform::runLater).join(); // runs on FX thread and waits for result
if (file == null) {
return;
}
// do some stuff
// ask for confirmation
boolean confirmed = CompletableFuture.supplyAsync(() -> {
// show alert and return result
}, Platform::runLater).join(); // again, runs on FX thread and waits for result
if (confirmed) {
// do more stuff
}
});
}
Both FutureTask and CompletableFuture will work for you. I prefer CompletableFuture because it it provides more options (if needed) and the join() method doesn't throw checked exceptions like get() does. However, CompletableFuture is a Future (just like FutureTask) and so you can still use get() with a CompletableFuture.
Related
I have the following code:
#FXML
private void test(){
textField.setText("Pending...");
boolean passed = doStuff();
if(passed){
textField.setText("OK");
} else {
textField.setText("Error");
}
}
And what I tries to achieve is that while the doStuff() do his stuff in a textField in the GUI there should be written "Pending..." and as soon as it finish it should change to "OK" / "Error".
I want that the GUI is blocked while doStuff is running so the user has to wait and can't click something else.
But what happens is that as soon as I start test it does the doStuff() but only updates the textField with "OK"/"Error" but I never see "Pending...".
I have the feeling that I have somehow update the GUI, but I'm not sure how it should be done.
Update:
What I tried is to move the doStuff in another Thread:
#FXML
private void test(){
textField.setText("Pending...");
Thread t = new Thread(){
public void run(){
boolean passed = doStuff();
if(passed){
textField.setText("OK");
} else {
textField.setText("Error");
}
}
};
t.start();
t.join();
}
It would works if i would remove the t.join(); command, but then the UI wouldn't be blocked. So I'm at a loss right now.
Thanks
You must never run long running tasks on the JavaFX Application Thread. Doing so will prevent said thread from doing any GUI related things which results in a frozen UI. This makes your user(s) sad. However, your attempt at putting the long running task on a background task is flawed. You call Thread.join which will block the calling thread until the target thread dies; this is effectively the same thing as just running the task on the calling thread.
For a quick fix to your example, you could do the following:
#FXML
private void test(){
textField.setText("Pending...");
Thread t = new Thread(){
#Override public void run(){
boolean passed = doStuff();
Platform.runLater(() -> {
if(passed){
textField.setText("OK");
} else {
textField.setText("Error");
}
});
}
};
t.start();
}
That will create a thread, start it, and let it run in the background while letting the JavaFX Application Thread continue doing what it needs to. Inside the background thread you must update the TextField inside a Platform.runLater(Runnable) call. This is needed because you must never update a live scene graph from a thread other than the JavaFX Application Thread; doing so will lead to undefined behavior. Also, you should look into “implements Runnable” vs “extends Thread” in Java. It's better, or at least more idiomatic, to do:
Thread t = new Thread(() -> { /* background code */ });
You could also use a javafx.concurrent.Task which may make it easier to communicate back to the JavaFX Application Thread. One option would be:
#FXML
private void test(){
textField.setText("Pending...");
Task<Boolean> task = new Task<>() {
#Override protected Boolean call() throws Exception {
return doStuff();
}
};
task.setOnSucceeded(event -> textField.setText(task.getValue() ? "Ok" : "Error"));
new Thread(task).start();
}
You could also bind the TextField to the message property of the Task and call updateMessage("Pending...") inside the call method. You could even provide more detailed messages if and when possible.
That said, creating and starting Threads yourself is not ideal and you should look into thread pooling (using something like an ExecutorService). You might also want to look into javafx.concurrent.Service for "reusing" Tasks.
For more information about JavaFX concurrency see Concurrency in JavaFX and read the documentation of the classes in javafx.concurrent. For the basics of multi-threading in Java see Lesson: Concurrency from The Java™ Tutorials.
Attached is the code snippet below. I am new to multi-threading. Attempted to do multi threading which sort of works. However, after I click the button the first time, the second time onwards would not "create the thread" and run my method anymore.
I have also experimented with implementing the Runnable interface, but it could not get my Anchorpane reference to load the snackbar and hence I used the task method instead. Appreciate your help!
#FXML
private AnchorPane anchorPane;
Thread thread;
#FXML
void onClickLoginButton(ActionEvent event) throws Exception {
thread = new Thread(task);
thread.start();
}
Task<Void> task = new Task<Void>() {
#Override
public Void call(){
//System.out.println("Thread running"+thread.getId());
try {
credential = login.login();
} catch (UnknownHostException u) {
Platform.runLater(() -> {
System.out.println("No wifi");
JFXSnackbar snackbar = new JFXSnackbar(anchorPane);
snackbar.show("Please check your internet connection", 3000);
//u.printStackTrace();
});
} catch (Exception e) {
//e.printStackTrace();
}
//System.out.println("Thread running"+thread.getId());
return null;
}
};
The reason why this runs only once has to do with how Task works in general
Per Task's documentation here: https://docs.oracle.com/javase/8/javafx/api/javafx/concurrent/Task.html
As with FutureTask, a Task is a one-shot class and cannot be reused.
See Service for a reusable Worker.
Thus, if you want to repeat the said process multiple times, using a Task is not a good choice. Check the recommended alternatives for workers and services in you want to achieve something like that.
I'm using SWT in a main GUI program. Within it, I create another thread to run some programs. However, if some errors are encountered in those processes, I want to report this to the user by making a message box appear. Because in SWT, only a single thread can perform GUI operations, I was having the program runner throw exceptions, so the GUI thread could deal with them. However, I am having problems because I create a new thread for the program runner (in order not to hold up the GUI thread, which will be continuously updating and refreshing some graphics), but as a result, the exceptions that take place are stuck as part of that thread, which can not create the error message box. Any suggestions on how to deal with this?
private void goButtonActionPerformed()
{
// create the program runner object
ProgramRunner PR = new ProgramRunner(); // real code passes in data to be used
try{
// check all necessary parameters are entered
boolean paramsOK = PR.checkParams();
if (paramsOK)
{
// all necessary information is available. Start Processing.
Thread t = new Thread() {
public void run()
{
try{
PR.runPrograms();
}
catch (IOException iox)
{
// This does not work to catch & display the exceptions
// which took place in PR.runPrograms(), because this
// thread is not allowed to perform GUI operations.
// However, I don't know how to pass this
// exception / error notification out of this thread.
MessageBox mb = new MessageBox(m_Shell, SWT.ICON_ERROR);
mb.setMessage(iox.getMessage());
mb.open();
}
}
};
t.start();
}
}
catch (IOException iox)
{
// this works to catch & display the exceptions which took place
// in PR.checkParams() because that is not a separate thread
MessageBox mb = new MessageBox(m_Shell, SWT.ICON_ERROR);
mb.setMessage(iox.getMessage());
mb.open();
}
Wrap catch logic inside a Display.getDefault().asyncExec to display error messages on UI thread:
Thread t = new Thread()
{
public void run()
{
try
{
PR.runProgram();
}
catch ( final IOException iox )
{
Display.getDefault().asyncExec( new Runnable()
{
public void run()
{
MessageBox mb = new MessageBox(m_Shell, SWT.ICON_ERROR);
mb.setMessage(iox.getMessage());
mb.open();
}
});
}
}
});
t.start();
the exceptions can be displayed in UI thread then.
You need to arrange that the UI code runs in the UI thread. You can do this using the asyncExec or syncExec methods of Display.
syncExec suspends the current thread until the UI code has been run. asyncExec does not suspend the thread and runs the UI code as soon as possible.
You can get the current display in any thread using Display.getDefault() so you might do something like:
Display.getDefault().asyncExec(() ->
{
if (m_Shell != null && !m_Shell.isDisposed()) {
MessageBox mb = new MessageBox(m_Shell, SWT.ICON_ERROR);
mb.setMessage(iox.getMessage());
mb.open();
}
});
I have used a Java 8 lambda expression for the Runnable here as it is shorter than the traditional method.
Since this code is being run asynchronously it is good practice to check that the shell is not null and has not been disposed.
I have an interface method which is supposed to return a Future object.
Future<Result> doSomething()
The implementation of this method shows some ui (javafx).
One of the ui elements has a listener, that needs to be called in order to receive the actual result, I need.
How do I achieve this?
Is there a better solution?
Here an example action I need to wait for:
// this is some framework method I cannot change
#Override
public Data execute(Data data) {
Future<Data> dataFuture = handler.doSomething(data);
// this should basically wait until the user clicked a button
return dataFuture.get();
}
// handler implementation
public Future<Data> doSomething(Data data) {
// the question is how to implement this part, to be able to
// return a future object
Button button = new Button("Wait until click");
// create thread that waits for the button click ?!????
// modify incoming data object when the button was clicked
// somehow create the Future object that's bound to the button click
return future;
}
This is what I want to achieve:
my method doSomething shows a new scene(ui) with a button on it
and returns immedeately the future object
future.get() waits until the user pressed the button
limitations: it has to be done with no extra library and on >=Java7
Use a javafx.concurrent.Task. It derives from FutureTask. There are extensive examples in the linked javadoc on Task usage.
Oracle also provide a tutorial which discusses Task usage:
Concurrency in JavaFX
I think this is what you want, but I may have understood the question, if so, please edit the question a bit to clarify requirements (perhaps with an mcve). The bit that makes me a little unsure is the part in your title "waiting for ui event?", I'm not quite sure what that means in this context.
This is a solution I was searching for. It's not very nice, since the Thread.sleep doesn't convince me.
but now you propably get an idea of what I want to achieve
// make sure this is not called on the ui thread
public Future<Data> doSomething(Data data) {
WaitingFuture future = new WaitingFuture(data);
Platform.runLater(() -> {
Button button = new Button("Wait until click");
button.setOnAction(future);
// show button on ui...
});
favouriteExecutorService.submit(future);
return future;
}
static class WaitingFuture extends Task<Data> implements EventHandler<ActionEvent> {
private Data data;
WaitingFuture(Data originalData) {
this.data = originalData;
}
private Data waitingData;
#Override
public void handle(ActionEvent event) {
waitingData = data.modify();
}
#Override
protected Data call() throws Exception {
while (waitingData == null) {
Thread.sleep(100);
}
return waitingData;
}
}
I'm writing an application that executes its file menu actions using SwingWorker. Every called method returns a boolean value that tells, whether the operation was successfully executed or not.
At the moment I'm using busy waiting for the result, like this:
public boolean executeOperation() {
final SwingWorker<Boolean, Void> worker = new SwingWorker<Boolean, Void>() {
#Override
protected Boolean doInBackground() throws Exception {
// ..
if (aborted) {
return false;
}
// ..
return true;
}
};
worker.execute();
// busy wait
while (!worker.isDone())
;
try {
return worker.get().booleanValue();
} catch (Exception e) {
// handle exceptions ..
return false;
}
}
Is there a less polling-intense way of solving this?
Using worker.get() directly wouldn't work, as it blocks the EDT, waiting for the task to finish - meaning even the dialogs I open from within the SwingWorker wouldn't get painted.
EDIT: If possible, I would like to avoid that the method (or the worker) to communicate their result asynchronously. I'm implementing several short methods (file -> open, new, close, save, save as, exit) that rely on each other (i. e. when the trying to exit, exit calls close, close might call save, save might call save as). Solving this asynchronously seems to make the code much more complicated.
The point of the SwingWorker is precisely to launch some task in the background and don't block the EDT. Either you want something synchronous, and the EDT will be blocked whatever you try, or you want something asynchronous, and the background task should update its status using the publish method of the SwingWorker.
You could display a blocking modal dialog with a progress bar while the task is running, and hide it once the task completes.
The alternative is to block for some time, hoping the task will be quick to finish, and then backup to an asynchronous way of doing. This can be done using the get method taking a timeout as argument.
You could use an asynchronous paradigm. Look at Observer / Observable and use the job to transfer the result back to the object which is currently doing the polling.
Using worker.get() directly wouldn't work, as it blocks the EDT, waiting for the task to finish - meaning even the dialogs I open from within the SwingWorker wouldn't get painted.
They don't with the current code either. Your busy wait blocks the EDT as much as calling worker.get() does - there is only one event dispatch thread, and the dialogs in the SwingWorker are just as blocked if that thread is spinning in a loop or awaiting a lock. The problem here is that if a method runs on the EDT, it simply can't return a value from an asynchronous operation (without hogging the EDT) to its caller.
The correct way to react to completed async processing is overriding the done() method in SwingWorker.
Also check out http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html for more info.
One way as mentioned by several folks above is to override the SwingWorker's done method. However if for some reason you want the post SwingWorker code outside of the SwingWorker and in the calling code, you can take advantage of SwingWorker's property change support. Simply add a PropertyChangeListener to the SwingWorker and listen for the state property which has a property name of "state". You can then extract the SwingWorker's state with its getState() method. When it is done it will return the DONE value of the SwingWorker.StateValue enum. For example (from an answer I've given in another thread here on SO):
if (turn == white) {
try {
final SwingWorker<Move, Void> mySwingWorker = new SwingWorker<Move, Void>() {
#Override
protected Move doInBackground() throws Exception {
Engine e = new Engine(); // Engine is implemented by runnable
e.start();
Move m = e.getBestMove(board);
return m;
}
};
mySwingWorker.addPropertyChangeListener(new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent evt) {
if (StateValue.DONE == mySwingWorker.getState()) {
try {
Move m = mySwingWorker.get();
// TODO: insert code to run on the EDT after move determined
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
}
}
});
mySwingWorker.execute();
} catch (Exception e) {
e.printStackTrace();
}
}
I ran into a similar problem when I wanted a function to return a value that would be calculated in a swing worker. I didn't want to simply get that thread to block the EDT. I also didn't want it to block. So I used a semaphore like this:
public boolean executeOperation() {
final Semaphore semaphore = new Semaphore(1);
semaphore.acquire(1); // surround by try catch...
final SwingWorker<Boolean, Void> worker = new SwingWorker<Boolean, Void>() {
#Override
protected Boolean doInBackground() throws Exception {
// ..
if (aborted) {
semaphore.release();
return false;
}
// ..
semaphore.release();
return true;
}
};
worker.execute();
try {
semaphore.tryAcquire(1, 600, TimeUnit.SECONDS); // awakes when released or when 10 minutes are up.
return worker.get().booleanValue(); // blocks here if the task doesn't finish in 10 minutes.
} catch (Exception e) {
// handle exceptions ..
return false;
}
}
I guess this is not ideal for all situations. But I thought it was an alternative approach that was very useful for me.