I have a jframe with "search button", when the user clicks it, a function will be called to search through several databases for the specified search criterion. What I want is to have a "wait/loading message" to appear while the function is searching, and disappears once the function is done executing. I searched for similar ideas and all of them are using thread programming. Can someone insight me if it is possible to use threads on my situation and if there are any other options?
thank you
You should perform the search in a background thread, and notify the UI using for example invokeLater.
You can find more informations and an example here http://www.javamex.com/tutorials/threads/invokelater.shtml
You could do the search process on the UI thread, but since it apearantly takes long to complete, the GUI would freeze. So for a fluid using expirience i would reccomend doing the search in another thread. Mulit-Thread programming is not as difficult as you might think.
See this tutorial
Related
I'm using Text to Speech on my app. After the google woman speak, a dailog box must be opened. The issue is: the dialog box open during the speech of the woman. So that's why I want to put a delay between the end of voice and the opening of the dailog box. I saw in several tutorials something about timesleep, handle, looper, thread and AsyncTask and I have a question: To my situation, what's the best way to aplicate? Thanks in advance.
In your case, I think AsyncTask will work best because of two reasons.
The women speaking part seems like it is a CPU-heavy process, thus it should be handled in a separate thread other than the UI Thread.
You can put your dialog on OnPostExecute() call and that call will trigger after the AsyncTask is done.
Hope it helps! Have fun.
I understand that in Java there are classes such as Swing worker that are meant to to be used for things that take long to process so the EDT (Event Dispatch Thread) is not blocked. But why not?
I have an application and every user action being taken should be a blocking action. So in cases like that, is there a reason why I shouldnt run on the EDT thread?
For example. If the user clicks on an item that loads and process spreadsheet. Then I dont want the user to go to the next step before the processing is done. Shouldnt I do that on the EDT to ensure the "sequence" of the events.
What am I missing?
You would be simply contradicting very basic/common design ideas of Java GUI applications.
If you want your user to "wait", then for example, you can put up modal windows, that simply don't allow him to click any button anywhere else. Doing that ... would still allow other elements in your GUI to be updated (for example if you have some "status bar" somewhere).
In other words: yes, it is pretty easy to just do anything on the EDT, and it might be tempting as "the simple design"; but chances are, that at some point you will regret this deviation of "java standards/best practices". And if that would happen ... then you are in a position that will require massive amounts of changes to get out of it.
Finally, never forget about the wtf-code-quality-metric; and accept that misusing the EDT in this way will guarantee you many WTFs in reviews.
The problem is that blocking the EDT would also block any UI updates, hence your UI might look unresponsive. You'd normally use a modal dialog in that case which makes the UI only accept further user input after the process is finished. As an example, doing that would allow you to display some indeterminate progress bar (i.e. a "working" animation) - i.e. the user doesn't get the feeling the application doesn't respond anymore.
There are other options besides a modal dialog though (e.g. using the glass pane etc.), have a look here for an example: Creating a nice "LOADING..." animation
It is considered good practice to have your UI be able to cater for user actions. In your case, for long tasks, usually a Cancel button is added so that the user can cancel the action should they deem it necessary.
You could do everything on the EDT, but I would recommend against it. Some people tend to consider a (completely) unresponsive UI as a sign that the application died.
Having some sort of UI component showing the user that a (lengthy) operation is in progress is, in my opinion, the way to go.
I have a GUI(JFrame), with two Buttons and 1 Panel to show the result. One Button is to start the algorithm, one for stopping it. By pressing start, a method is called and it starts running. The runtime of this method varies from couple of seconds to 2-3 minutes, depending on the input.
The problem I have hereby is, by pressing the start-button, the GUI gets completely locked. I cannot press any button till the algorithm terminates. It would be great to be able to stop the algorithm and to visualize parts of the solution after a certain amound of time.
I checked every single line of the Frame, there is nothing that disables it.
//If needed I can provide code, but its pretty long and just some hints and reasons for the problem would be great and I try to fix it by myself.
thanks in advance.
Don't put long-running tasks on the EDT, or the Event Dispatching Thread. Use threading or a SwingWorker instead. Hopefully that's enough google keywords to get you started. :)
It sounds like your algorithm is running in the same thread as the UI components. You probably want to read up on Concurrency and Concurrency in Swing to better understand how to create threads, monitor execution, integrating these concepts with a Swing-based user interface, and so forth. At a very high level, you are going to need to somehow spawn a new thread when your algorithm starts and observe it for intermediate state changes to update the UI. You only want user interface related code running in the event dispatch thread.
This is mostly a theoretical question. The example below is what made me think of it, but it may not be the best example. Please assume that the reason's below are concrete, and can't for the moment be worked around.
The Program I have been running has an optional Debug frame that is created on the program startup, and it made visible by the user pressing buttons/keyboard shortcut.
My issue is that as I have lengthy processes on the EDT, if it is hanging for some reason or fails I'd like to see straight away, and not wait for that thread to end running, to update the Debug Log Frame.
My solution would be to have two separate EDT for two separate GUIs that are updated by a separate thread.
Is this possible, or am I not able to do so? I haven't found any online resourcethat would show me how to. I know that EDTs should be single threaded, but if I keep the threads disentangled, can I have two? Please?
The answer is simple: No you cannot have 2 EDTs, that is not possible.
But you are not stuck with a frozen GUI, you have some options available.
First and foremost, two important rules:
Never do lengthy calculations in the EDT. Ever.
Never manipulate Swing components from outside the EDT. Ever.
Breaking the first rule will result in your GUI being frozen and no events of any sort being processed during that time. This includes updates to the GUI you want to do during the calculations which will not appear until after the calculations are done.
The latter is often ignored which will go by unnoticed most of the time, but it can - and will - bite you in the ass and then most of the time it is a huge pita to go back and fix it. So do it the correct way from the start. What can happen? Components can suddenly display in a broken state, they may appear white, or the whole application can freeze because there is a deadlock between the EDT and your other threads (been there, done that). Adhere to the Oracle Swing Threading Policy!
So, how to avoid doing lengthy calculations on the EDT after for example the user pressed a button? Options:
use a SwingWorker. Advantage: Has a done() method you can use which is automatically executed in the EDT once the worker is done. Also implements the Future interface and can therefore be used to return a result.
you can just create your own Runnable and do the calculations in there.
use any other way Java provides for parallel execution.
Ok, and how to avoid ever manipulating GUI from outside the EDT?
call SwingUtilities.invokeLater() and execute Swing manipulations in there.
use the SwingWorkers done() method as described above.
If you follow these two rules, your Swing GUI will be in a much better shape and you can focus more on your application development rather than Swing issues.
I have just found the code to a small WAV player.
It works well but when clicking the "Pause" and "Stop" buttons there's like a 2 seconds delay which makes the app look really unprofessional. I have no idea what is causing this but I'd really like to have it fixed, could anyone inspect the code and tell me where it comes from? Thanks!
I wrote this sample for a time and don't remember very well.
In my opinion the latency comes mainly from the update frame functions. In the class VisualPlayer, UI are update by a timer which pick up the current values from the thread. It's not very efficient but faster for write this sample.
The best way to update UI is implementing a Runnable class and call it with SwingUtilities.invokeLater().
Also have you try to reduce read buffer size ?