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.
Related
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".
I have a program which bruteforces an AES256 encryption, how would I pause the program when the computer goes into shutdown/or reboot and continue at the same point until the next boot of the system?
A sort of hibernate of the program.
I would agree with part 2 and 3 of #Thufir's answer, but regarding part 1 it assumes that you are running a GUI.
Instead of this I would add a shutdown hook into the JVM and write the state of my program at that point. You can do this using the following:
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
// your serialization code goes here
}
});
You asked three things here.
1- How can I check when the OS goes reboot/shutdown
Solution:
You can make an empty invisible window, and add WindowListener to it. It will receive windowClosing event on windows.
You can find an example HERE
2- How can I save the state of my BruteForce process and pause to start again when system goes up.
Solution:
Here is easy, you must serialize. These will save the state of your class/classes to deserialize when system goes UP again. You can study HERE
3- How know when startup the programm again when OS goes UP?
Solution:
You can put your program in initialization process of your OS. When it starts, you check if there is anything to deserialize and do it, restoring the process of the BruteForce.
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
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.