Design choices...

[Anza Power]

Hello, I'm new to developing GUI apps in Java (though been using regular Java for years) I've taught myself Swing and I get the gist of it but I have a few questions about general design choices:

1. I want to make a program where the GUI app has a Start button, when the user presses it the main thread starts doing an animation, what is the best way to do this?
   My solution was to have the main thread stuck in an endless loop waiting on a key object, when the button is pressed it calls the notify method of the key, like so:
   
   

   while(true){
         keyObject.wait();
         doTheAnimation();
   }
   
   //The button's action listener method:
   void ActionPerformed(ActionEvent e){
        keyObject.notify()
   }

   Is this how everyone does it?
2. Is Thread.sleep() the best method to use for doing animations?
3. If I wanted to make a game in swing, I'd make the main thread be the main game-flow thread which in an endless loop sleeps for some small time and refreshes the game state by doing what each character needs to do, and there is a PipedInputStream for the main player's controls, whenever a keyboard button is pressed the event dispatcher thread puts the button in the PipedStream and when the main thread is refreshing it checks if there's a signal in the stream and if there is does the appropriate action for the player...
   
   Is this the norm or is there a more optimal way?

Thanks in advanced...:)

[KevinWorkman]

1- Why would you not just do:

void actionPerformed(ActionEvent e){
     doTheAnimation();
}

2- It really depends. For simple animations, I would just use a Swing Timer.

3- Again, I would use a Swing Timer, at least at first.

[Anza Power]

^ For 1, the animation involves alot of Thread.sleep() calls so it needs to be in it's own thread and not on the event dispatching thread...

Thanks for the answers on 2 and 3, but also about the key input method (for one thread to put the key commands in a PipedStream and the running thread to read them from there) is that a bad idea?

[KevinWorkman]

Why does your animation involve any calls to Thread.sleep? What I would do is create a Timer that fires however often you want your FPS to be (20-30 fps is probably reasonable), each time calling a step function. That step function updates whatever it needs to update and tells your animation JComponent to repaint.

Your step function can update the animation based on which step it's on, instead of using Thread.sleep. It can also update whatever it needs to based on booleans (such as upArrowPressed), which you set in keyPressed and keyReleased functions of a KeyListener, instead of the model you were describing.

From there, if you want to do more complicated logic or animation, you can move to using multiple threads. But for most "simple" games, a Swing Timer will work just fine.

[Norm]

void actionPerformed(ActionEvent e){
    Thread t  = new Thread(new Runnable() {
      public void run() {
           doTheAnimation();  // do on own thread
      }
    });
    t.start();
}

[Anza Power]

^ That won't do because it will create a new thread each time the start button is pressed...

Why does your animation involve any calls to Thread.sleep? What I would do is create a Timer that fires however often you want your FPS to be (20-30 fps is probably reasonable), each time calling a step function. That step function updates whatever it needs to update and tells your animation JComponent to repaint.

Your step function can update the animation based on which step it's on, instead of using Thread.sleep. It can also update whatever it needs to based on booleans (such as upArrowPressed), which you set in keyPressed and keyReleased functions of a KeyListener, instead of the model you were describing.

From there, if you want to do more complicated logic or animation, you can move to using multiple threads. But for most "simple" games, a Swing Timer will work just fine.

Thanks for the info, I guess I'll need to look into those timers then...

Thanks again...

[Norm]

You could disable the "Start" button if you do NOT want another thread to be started. It all depends on how you have designed your app and how you want it to run.