I am making a javafx application that simulates a robot vacuum.
I want it to be automated so it would vacuum the environment by itself.
I need to insert a delay so a human can see the steps the vacuum is taking as it traverses the environment.
So far all the delay methods I have tested crash my program if they are inside a while loop.
If I put it outside the while and just click a button for the next step, everything works fine.
It also works fine if I set the delay to really short time, like 1 ms.
Any ideas of why this is happening?
Any application that executes a set of instructions for a while (is busy) and cannot respond to user input or system events is "seen" by Windows as "not responding" and when you try to interact with a "not responding" program, Windows will tell you it crashed.
The problem, you see, is that you try to delay interface updates with a while loop, and that makes your program execute something for a while and while is busy executing your loop it cannot respond to system or user events.
If you want to make delayed updates, use multithreading. Your while loop is blocking the main thread which is also responsible for rendering and taking any input, so you cannot block this thread. Create another thread and share state (eg. use observer pattern). And then you can execute TimeUnit's sleep() in this helper thread and it won't make your app "crash".
Related
I am implementing an Interpreter for a moderately simple Pascal/BASIC-like programming language, in Android. I have finished the parser, so programs get recognized, loaded in memory and ready to execute. The language is procedural, emulating command line input/output and obviously not event-driven like Java in Android.
A sample program may look like this:
FOR i FROM 1 TO 10
READ Name
PRINT "User ", i, " name: ", Name
END_LOOP
Being relatively new to Android, I did not know that Android dialogs are asynchronous, and thus cannot interrupt execution, as explained in dozens of similar questions. (1), (2), (3), (4)
So, I initially thought I would implement READ commands by showing a modal Dialog. Executing code that involves reading input from the user, would require waiting for it to finish before moving on to the next line of code. But this should not be done with a dialog, as mentioned in the above posts.
I figured out that the most "appropriate" way would be to "save" the execution state of the whole program, stop execution and then start executing by loading the last state, when user inputs something from the Dialog. But this seems impossible, and way too much hassle for such a simple task. Is there an easier way?
Any suggestions are welcome.
I did not know that Android dialogs are asynchronous, and thus cannot interrupt execution, as explained in dozens of similar questions
All Android UI is asynchronous.
I initially thought I would implement READ commands by showing a modal Dialog.
There is nothing intrinsically wrong with this. However, READ would need to suspend execution of your interpreter until the user has completed the dialog.
Is there an easier way?
Off the cuff...
Step #1: Run your interpreter on a background thread.
Step #2: Have your READ code invoke your dialog on the main application thread, then block on a Semaphore to block your background thread.
Step #3: Have your dialog code get the results of the user input over to your interpreter by some means, then release the Semaphore when the dialog goes away.
Step #4: Your interpreter code continues.
I programmed myself a little helper-tool. It got a little GUI with the buttons "Run" and "Stop". If I press "Run" the program executes a loop that continuously does something (http requests - every hour a few ones).
But now I have the problem that, when I press "Run", the button stays pressed and the program/GUI waits for the process to end. In this time I can't close the Window or press the "Stop"-button. And because the process is running forever, I am never able to end it - of course I can end the process in task-manager.
Is there a way to bypass this problem?
I look forward for a helpful answer ;-)
Without code one can only speculate, but you are most likely running everything on the same thread, meaning that the method which handles the button press also launches these requests.
The problem with this approach is that everything is done on the Event Dispatching Thread, which is the thread which handles events and other UI operations. Any lengthy operations on this thread will make your UI non responsive.
To solve this problem, you will need to have your Run event handler launch threads which do all the work. This will leave the EDT free to handle user interactions.
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.
I am using Crouton as alternative to native android toasts. I have to display 5-6 croutons one after the another and then call System.exit(0) to exit my app.
The problem is, I see first crouton for 1-2 seconds and the app just exits! The rest croutons aren't displayed at all. This is because when the code is being executed the undisplayed croutons are added to queue. And when it comes to System.exit(0) it exits the app without displaying those queued croutons. I have tried searching for solution for this and came across a solution in which I have to create a new thread, then sleep it for time = sum of durations of necessary croutons and then call System.exit in that thread. But then if I have more or less croutons in another situation then that becomes useless.
So can anyone think of a solution?
Why do you have to quit the app?
In general, in Android, applications should not quit, and show not provide a way for the user to quit them. Quitting an app is handled by the system when the user navigates away from it and goes back to the home screen.
If your application must quit (for example, because of an unexpected condition it can't deal with) and you want to make sure the user sees the information, then the best approach would be to use an AlertDialog to display the information.
So, long story short: revise your UI... if you're sure that this is the right way to do it, then simply don't call System.exit(0). Just show the toasts and then stick around. Eventually the system will decide to quit your app when memory is needed.
I am a Java newbie and an Android newbie too. I am working on a game and trying to understand the exact nature of events in Java and Android. I have a few questions to help understand the correct way to do event handling in my app.
Its a network game and so I need to check if the user made a move or not to update the view. Also I need to prompt the user to make a move if he takes too long. For this I have two threads -
Timer thread expires every 10 seconds and calls updateview if needed or prompts user to make a move.
Event thread gets created when user clicks on the screen to make a move or clicks on menu etc.
Is this the correct approach? These two can be fired at any time.
Here are the issues I see with this -
What happens when one thread gets run when the other one is active.
Which thread has precedence if both are started at the same time.
Do events in the timer thread get queued up?
If so can I pick which one in the queue to use?
Can I cancel events in the queue? For e.g. if I have 2 updateview events lined up in the queue I only have to call it once.
Thanks for any inputs.
P
I would suggest reading up on Android AsyncTask.
Consider that you can implement a timer WiTHOUT using a thread. Use a single Handler switching on what and send a postMessageDelayed(what 0,milliseconds) to the handler say every one second. You could set a counter variable to zero and check the flag every one second in the what 0 handler, incrementing the counter by one. If the value is >= ten, post a message and reset the variable to zero. If the user selects an action, reset the instance variable to zero.
A time consuming action can be run in a separate thread that messages the handler, perhaps using what 1, on completion. Or you could run a time consuming action in a separate asyncTask.
JAL