[java] sockets uitlezen icm GUI *

[Verwijderd]

Ik heb de volgende vraag ( ben geen ervaren Java programmeur)

ik heb een main klasse
in die main klasse instantieer ik een frame met tekstvelden en knoppen.
de knoppen hebben een actionlistener.
als ik op de knop "connect" druk open ik een socket:

code:

    String hostje = hostInput.getText();
    link = new Socket(hostje, PORT);
    in = new BufferedReader(new InputStreamReader(
        link.getInputStream()));
    out = new PrintWriter(link.getOutputStream(),true);

zoals je ziet wordt de host uit een tekst veld gehaald.

als ik dit stukje in de main gooi en daar onder de volgende code:

code:

do{
response = in.readLine();
System.out.println(response);
}
while(!response.equals("QUIT")

dan werkt het wel. haal ik het connect stukje uit de main en voer ik dat pas uit als ik de "connect" knop indruk, maakt die wel verbinding, maar kan ik de response niet meer uitlezen...

wat moet ik hieraan doen?

[-FoX-]

Je probeert Socket-connecties te maken in samenwerking met een gui-implementatie.
Dit gaat fout omdat de gui nier verder afgehandeld wordt als de sockets hun werk doen.

Probeer eens met threads te werken, die de connectie verder afhandelen..

[Robtimus]

Wat -FOX- al zegt, gebruik threads voor het afhandelen. Je gebruikt nu de event dispatching thread, die de GUI beheert, voor het afhandelen van je taken. Die ene thread heeft dus geen tijd meer om zijn eigen werk, nml de GUI updaten, te doen.

Verder zou ik

Java:

do {
response = in.readLine();
System.out.println(response);
}
while (!response.equals("QUIT"))

veranderen in

Java:

response = in.readLine();
while (response != null && !response.equals("QUIT"))
{
    System.out.println(response);
    response = in.readLine();
}

of

Java:

do {
    response = in.readLine();
    System.out.println(response);
}
while (!"QUIT".equals(response))

Immers, wat als response null is omdat de verbinding wordt gesloten, om wat voor reden ook?
Zie je het subtiele verschil tussen jouw oplossing en mijn laatste? Als response null is zal in jouw code het een NullPointerException opleveren; omdat "QUIT" niet null is zal het dan in mijn code false opleveren.

[DarkSilence]

Ik heb na je beter gezegd wou want het is nooit gelukt een chat programma schrijven. Ik had toen gigantische problemen met de thread en de socket. Kan wel weer eens proberen weer een leuke uitdaging.

Ik had toen deze topic geopend [rml][ Java] Thread probleem*[/rml], misschien heb je er wat aan? Als je een werkend chat programma hebt ben ik wel benieuwd naar de sourcecode.

[Donderwolk]

Ik gebruik persoonlijk liever een flag, dat houdt de code wat netter en dus ook leesbaar.

Java:

String sMessage;
boolean bShouldRun = true;

while(  bShouldRun && ((sMessage=in.readLine()) != null)){
    if( !sMessage.equals("QUIT") ){
        System.out.println( sMessage );
    }
    else{
        bShouldRun = false;
    }
}

Wat ook nog kan is dat je gewoon een break; aanroept zodra je "QUIT" voor de kiezen krijgt.

[ Voor 26% gewijzigd door Donderwolk op 16-03-2004 17:03 ]

[Verwijderd]

Komt dus kortom op het volgende neer:

Java:

public class Gui extends JFrame{
//hier komt de gui en een eventlistener op de knop
}

en

Java:

public class Server extends Thread{
private String hostje;

//even verder uitwerken met een start-methode
//zodat hier naar de host geluisterd wordt

public void setHostje( String _hostje){
  this.hostje = _hostje;
}

Zo kun je in de gui van alles doen terwijl een andere thread bezig is met het luisteren naar de socket.
Je kunt eventueel in de gui weer een methode maken om een string daar te vullen vanuit je serverthread met de response, zodat je die op de gui kunt zetten ipv de System.out

Java:

//voorbeeldje om in de gui te implementeren

//gui...

public void setResponse(String _response) {
  textvak2.setText(_response);
}

zoiets dus

Zo kan je programma twee dingen tegelijk. En dat met maar één processor? Wauw, ok je schept het idee dat je twee dingen tegelijk doet. Wil je er zeker van zijn dat Windows niet halverwege een operatie opeens naar de andere thread gaat (omdat ze ooit beide van dezelfde gegevensklasse gebruik maken ofzo), moet je met serializable voorkomen dat het OS voor het afmaken van iets naar een andere thread springt, maar dat is misschien wat veel info voor nu.

Je kunt overigens wel beter zorgen dat zodra er een nieuwe connectie binnen komt in je serverThread, dat die weer voor die bepaalde host een nieuwe Thread aanmaakt. Zo heeft elke host een eigen thread om mee te communiceren. Dan kan de ServerThread weer gaan zitten wachten op een nieuw host, terwijl de host nu een eigen Host#Thread heeft. Kun je een multiuser-server maken, maar voor nu zou ik me eerst even richten op een singeluser server.

P.S. als je code=java tussen de tags zet i.p.v. gewoon code, krijg je mooie kleurtjes, hier op het tweakersforum dus (om je niet helemaal in de war te brengen)

edit-zoveel:
waarom dus in verschillende threads? Omdat je programma blijft hangen op:
response = in.readLine();
totdat hier iets binnen komt.
Wat je ook programmeert. Je wil niet dat het gaat hangen.

[ Voor 32% gewijzigd door Verwijderd op 16-03-2004 17:19 . Reden: bedacht me dat het nog efficiënter kon; stond ook een gruwelijke fout in en heb nog een keer of wat wat toegevoegd :) ]

[Verwijderd]

Bedankt voor de moeite, is nu gelukt met de threads!