Ist Background-Threading in Java wirklich so schwer?

[Thallius]

Hi,

ich komme aus der OSX Ecke und wenn ich dort etwas mache, dass im Hintergrund ausgeführt werden muss weil es zu lange dauert, dieses aber gleichzeitig das UI verändern muss, dann geht das ungefähr so:

-void methodeXYirgendeinerKlasse()
{
    // Öffne ein Fenster (Meinetwegen ProgressIndikator)
    [self.performSelectorInBackground:@selector(backgroundMethode:) withObject:irgendeinObject];
}

-(void)backgroundMethode:(IrgendEinObject)irgendeinObject
{
    do
    {
        // mache halt irgendwas
        [self.performSelectorInMainThread:@selector(updateMainMethode:) withObject:irgendeinObject];
    }
    while()
    [self.performSelectorInMainThread:@selector(doneMainMethode:) withObject:irgendeinObject];
}

-(void)updateMainMaetohde:(IrgendeinObject)irgendeinObject
{
    // refreshen wir das ProgressBar
}

-(void)doneMainMaetohde:(IrgendeinObject)irgendeinObject
{
    // Schließen wir das Fenster und machen weiter mit unserem Programm....
}

Das ist alles.

Jetzt versuche ich gerade sowas profanes mit Swing hinzubekommen. Ich dachte ok, wird nicht so schwer sein. Aber Pustekuchen. Ich habe es erst mit einem einfach runnable mit einem Thread versucht und dann nach dem Thread.start() direkt einen Thread.join(), damit der Maintask schonmal darauf wartet das der Hintergrund Thread fertig wird. Dummerweise scheint er den Thread start aber wohl zu machen bevor das setVisible() von meinem ProgressPanel komplett ausgeführt wurde. Jedenfalls erscheint da ein leeres Frame auf dem Bildschirm. Ok, dann versuche ich es halt mit dem SwingUtilities und InvokeLater. Nun habe ich mein ProgressFrame aber dafür rennt mein Mainthread direkt durch und schließt das ProgressFrame direkt wieder....

Das kann doch nicht so kompliziert sein so etwas zu machen. Alle Tutorials dazu sind erschreckend unverständlich für mich. Wahrscheinlich weil ich einfach ganz anders denke oder finde ich einfach nicht das richtige?

Gruß

Claus

 

[Tobse]

Da wäre einmal die Klasse SwingWorker, das wäre best Practice. Ich mache es aber in fast allen Anwendungen so:

interface ProgressListener
{
     public void processStarted(int min, int max);
     public void processStateChanged(int value);
     public void processStateIncreased(); // wenn mehrere Threads arbeiten
     public void processFinished();
}

class ProgressFrame extends JFrame
{
    public void setMinimum(int min); // wird weitergegeben an eine JProgressBar
    public void setMaximum(int max); // wird auch weitergegen an eine JProgressBar
    public void processStateChanged(int value); // und auch hier an die JProgressBar
    public void setIndeterminate(boolean is); // und das auch an die JProgressBar
}

class DoSomething
{
    public void doSomething()
    {
        ProgressFrame pFrame = new ProgressFrame(Beschreibung, Titel, wird ETA angezeigt etc.);
        new Thread(new Runnable()
            public void run()
            {
                doSomething(new ProgressListener() { /* gibt alles ans Progress Frame weiter */ };
            }
        }).start();
    }
    private void doSomething(ProgressListener l)
    {
         l.processStarted(0, 100);
         // jeder arbeitsschritt/durchlauf
         l.processStateChanged(...);
         l.processFinished();
    }
}

ACHTUNG: Hier warted der Starter-Thread nicht darauf, dass der andere Thread fertig wird. Wenn der Starter-Thread nämlich nicht selbst ein extra neu erstellter ist blockiert das den EDT und somit ermöglicht nur ein regelmäßiges Thread.yield() im Hintergrund eine Anzeige in der GUI was aber WorstPractice wäre.

Auf diese weise kannst du ohne deinen Hintergrund-Code zu verändern theoretisch auch eine Fortschirtts-Angabe übers Netzwerk oder auf die Kommandozeile schicken. Die Klasse ProgressFrame kann dann auch aufgrund der Geschwindigkeit mit der sich der Status erhöht bei linear ablaufenden Vorgängen ziemlich präzise eine ETA eigenständig ausgeben.

Den Quellcode für die Klassen und ein Vollständiges Beispiel für singelthread / multithread background anwendungen kann ich dir per PM schicken.

 

[Thallius]

Danke,

ich habe es mit dem Worker gemacht aber das ganze Konstrukt finde ich total unsinnig. Da rufe ich im Worker eine Methode setProgress() auf die dann wiederum einen PropertyChange in meinem MainThread triggert. Wieviel komplizierter geht es denn noch?

Gruß

Claus

 

[Tobse]

Du siehst: Ich habe es änlich umgesetzt. Es geht darum den Arbeits-Code vom GUI-Code so gut wie möglich fern zu halten. Und Listener sind eine wunderbare Art, genau das zu tun.

Und wenn das schon kompliziert ist: schau dir mal an wie die Listener für einen JButton oder eine JTable mit ihrem Eltern-Frame o.ä. zusammenabreiten. Da wirds dann richtig spaßig.

 

[turtle]

Da rufe ich im Worker eine Methode setProgress() auf die dann wiederum einen PropertyChange in meinem MainThread triggert

Das liest sich kompliziert, aber alle GUI-Frameworks sind single-threaded. Also muss ein Background-Thread "irgendwie" dem GUI-Thread sagen, das es neu zeichnen soll. (Was wäre denn dein Alternativ-Vorschlag?)

Und da sind Listener eine gute Möglichkeit Background- und GUI-Thread, wie Tobse richtig anmerkte, zu entkoppeln.

Zum Thema SwingWorker habe ich übrigens mal einen Blog geschrieben den du hier findest.

 

[Thallius]

Das liest sich kompliziert, aber alle GUI-Frameworks sind single-threaded. Also muss ein Background-Thread "irgendwie" dem GUI-Thread sagen, das es neu zeichnen soll. (Was wäre denn dein Alternativ-Vorschlag?)

Und da sind Listener eine gute Möglichkeit Background- und GUI-Thread, wie Tobse richtig anmerkte, zu entkoppeln.

Zum Thema SwingWorker habe ich übrigens mal einen Blog geschrieben den du hier findest.

Ich habe mich jetzt über den PropertyChangeListener genauer informiert. Jetzt verstehe ich das Ganze schon besser. Was ich s*****e finde ist, dass das alles im private Teil des Workers gekapselt ist, so dass man ja als Anfängern gar nicht verstehen kann was da eigentlich passiert. Entweder man nimmt das so hin (was einfach nicht mein Ding ist, ich will verstehen was ich programmiere) oder man muss sich das Ganze an zig anderen Stellen zusammen suchen, wie das ungefähr funktioniert. Zumal die gazen Tutorials einem da auch nicht helfen, weil es denen anscheinend auch egal ist warum es funktioniert. Hauptsache es geht.


Danke

Claus

 

[turtle]

PropertyChangeListener genauer informiert. Jetzt verstehe ich das Ganze schon besser. Was ich s*****e finde ist, dass das alles im private Teil des Workers gekapselt ist,

Bahnhof???:L
Welcher PropertyChangeListener und insbesondere welcher Worker?

Vielleicht postest du mal etwas mehr Code?

 

[Thallius]

So, sorry hatte die letzen Tage einfach zu viel zu tun um mich weiter darum zu kümmern.

So sieht es im Moment aus aber hier wartet der Mainthread natürlich nicht bis der Background Thread fertig ist.

	          public class getLicenseThread implements Runnable 
	 {
		  protected MainFrame frame;
		  public getLicenseThread(MainFrame frame) 
		  {
			  this.frame = frame;
		  }
		
		  @Override
		  public void run() 
		  {
		  }
	 }
	 
	 public void renewLicense(MainFrame frame, final String salt)
	 {
		 getLicenseThread pt=new getLicenseThread(frame) 
		 {
			 @Override
			 public void run() 
			 {

				final GetLicenseProgressPanel progressPanel=new GetLicenseProgressPanel();
    	                        ProgressWorker pw = new ProgressWorker(frame, progressPanel, salt);
	                pw.addPropertyChangeListener(new PropertyChangeListener() 
	                {
	                	@Override
	                    public void propertyChange(PropertyChangeEvent evt) 
	                    {
	                		String name = evt.getPropertyName();
	                		if (name.equals("progress")) 
	                		{
	                			int progress =  (Integer) evt.getNewValue(); // Hier den Wert angeben
	                			progressPanel.progressBar.setValue(progress);
	                			frame.repaint();
	                        }	
	                        else if (name.equals("state")) 
	                        {
	                        	SwingWorker.StateValue state = (SwingWorker.StateValue) evt.getNewValue();
	                            switch (state) 
	                            {
	                            	default:
	                             		break;
	                             	case DONE:
	                             		progressPanel.setVisible(false);
	                                    return;
	                            }
	                        }
	                    }
	                });
	                pw.execute();		
			 }
		 };
		 EventQueue.invokeLater(pt);
	 }
	 
	 public class ProgressWorker extends SwingWorker<Object, Object> 
	 {
		 private GetLicenseProgressPanel panel;
		 private MainFrame frame;
		 private String salt;
		 
		 public ProgressWorker(MainFrame frame,GetLicenseProgressPanel panel, String salt)
		 {
			 this.panel=panel;
			 this.frame=frame;
			 this.salt=salt;
		 }
		 
		 @Override
		 protected Object doInBackground() throws Exception 
		 {
                         // hier wird die eigentlich aktion ausgeführt
			 return null;
		 }
		 
		 public void updateProgress(int index)
		 {
			 setProgress(index);
		 }
	 }

Was muss ich nun in diesem Code machen, damit der Main Thread erst weiter läuft wenn Worker sagt Done?

Gruß

Claus