IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

**Whiz-zarD** · 03.05.2013 20:37

Ich frage mich immer wieder, was du mit den Arrays hast.
Da der Name contactList schon verrät, dass es eine dynamisch wachsende Liste ist, wäre es auch angebracht die Liste auch als Liste zu behandeln und die Daten stattdessen in eine ArrayList zu packen

**Rusk** · 03.05.2013 22:39

Zitat von Whiz-zarD

Ich frage mich immer wieder, was du mit den Arrays hast.

Vielleicht wurden Listen noch gar nicht im Unterricht durchgenommen?

@ Engel der Furcht:
Ich würde dir auch wie Whiz-zarD empfehlen auf eine ArrayList umzusteigen, dann musst du dir keine Sorge wegen Größe, etc. machen. Außerdem stehen dir auch zusätzlich nützliche Methoden bereit, die die "Verwaltung" der Liste leichter machen. Falls du aber häufig Einfüge- oder Löschoperationen durchführst, würde ich zu einer LinkedList zurückgreifen, die sind nämlich performanter als ArrayLists.

**Engel der Furcht** · 03.05.2013 23:10

Zitat von Whiz-zarD

Ich frage mich immer wieder, was du mit den Arrays hast.
Da der Name contactList schon verrät, dass es eine dynamisch wachsende Liste ist, wäre es auch angebracht die Liste auch als Liste zu behandeln und die Daten stattdessen in eine ArrayList zu packen

Ich hab einfach keine Ahnung von diesen ArrayLists.
Der Name klingt als würden die nur eindimensional und nicht mehrdimensional sein :<

Hab das Ding jetz mit einem cast gelöst.

Code:

FileInputStream fis = new FileInputStream(contactFile);
      ObjectInputStream ois = new ObjectInputStream(fis);
      contactList =(String[][]) ois.readObject();

Ich werd mir das mal mit den ArrayLists mal durchlesen...

**Whiz-zarD** · 03.05.2013 23:12

Zitat von Deamonic

Vielleicht wurden Listen noch gar nicht im Unterricht durchgenommen?

Und genau das hasse ich am Informatikunterricht an Schulen, wenn die Lehrer keine Kompetenz aufweisen, dann sollen sie es gleich lassen. Den Schülern das Programmieren falsch beibringen kann nicht das Ziel der Übung sein.
Arrays verwendet man nur, wenn man zur Laufzeit exakt die Anzahl der Elemente kennt, und die Anzahl sich auch nicht mehr ändert. Eine Veränderung der Arraygröße ist immer sehr problematisch, da ein Array als ganzer Block im Speicher liegt. Bei einer Vergrößerung muss ein neues Array erzeugt, und das alte in das neue kopiert werden, was bei vielen Änderungen sehr inperformant wird. Es macht also kein Sinn, eine Adressverwaltung mittels eines Array zu implementieren, da man eben die Anzahl der Adressen nicht kennt, die gespeichert werden sollen. Nutzer A hat vielleicht nur 3 Adressen, aber Nutzer B möchte 30.000 Adressen speichern.

Ich schätze auch mal, dass die zweite Dimension des 2D-Arrays wohl die Daten des Kontaktes bereithält. Schon in den Anfängen der Informatik hat man erkannt, dass dies sehr bescheiden ist, und hat dafür ein Record/eine Struktur entwickelt, die die Daten ansprechender machen. In der objektorientierten Welt wäre dies einfach nur eine Klasse, die lediglich nur Getter- und Setter-Methoden für die Klassenvariablen bereitstellen. In der objektorientierten Welt nennt man sowas auch Geschäftsobjekt.

Code:

public class Contact
{
    private String firstname;
    private String lastname;
    ...

    public getFirstname()
    {
        return this.firstname;
    }
    
    public setFirstname(String firstname)
    {
        this.firstname = firstname;
    }

    ...
}

Dann hätte man anstatt String[][] ein LinkedList<Contact>. Und wer ganz schlau ist, kapselt LinkedList<Contact> in eine Klasse:

Code:

public class ContactList extends LinkedList<Contact>
{
    ...
}

Dies wäre dann eine Liste von Geschäftsobjekten. Der Vorteil bei diesen Objekten ist nun, dass ich jeweils für die Kontakte, als auch für die Kontaktliste eigene Logik-Methoden implementieren kann, wie z.B. das Laden oder Speichern, und ContactList ist ansprechender als LinkedList<Contact>, weil es mich nun nicht mehr interessiert, wie die Kontaktliste implementiert ist. Sie ist einfach da und ich benutze sie.

Zitat von Engel der Furcht

Ich hab einfach keine Ahnung von diesen ArrayLists.
Der Name klingt als würden die nur eindimensional und nicht mehrdimensional sein :<

ArrayList<ArrayList<ArrayList<String>>>

Eine Drei-Dimensionale Liste mit Strings

Du kannst es auch beliebig weiterführen. hab doch keine Angst, damit zu experimentieren. Es gibt doch im Internet genug Tutorials, die Listen erklären.

**Rusk** · 03.05.2013 23:41

Zitat von Whiz-zarD

Eine Veränderung der Arraygröße ist immer sehr problematisch, da ein Array als ganzer Block im Speicher liegt. Bei einer Vergrößerung muss ein neues Array erzeugt, und das alte in das neue kopiert werden, was bei vielen Änderungen sehr inperformant wird. Es macht also kein Sinn, eine Adressverwaltung mittels eines Array zu implementieren, da man eben die Anzahl der Adressen nicht kennt, die gespeichert werden sollen. Nutzer A hat vielleicht nur 3 Adressen, aber Nutzer B möchte 30.000 Adressen speichern.

In diesem Fall würde ich gleich anstatt der ArrayList zu einer LinkedList greifen, da bei einer Löschung eines Elements in einer ArrayList die ganze hintere Liste um eine Position nach vorne gerückt werden muss. Und in deinem Fall mit den 30.000 Adressen ist das sicher nicht zu vernachlässigen.

EDIT: Oh, hab gerade gesehen, dass du eh eine LinkedList verwendest. ^^

**Whiz-zarD** · 03.05.2013 23:49

Zitat von Deamonic

EDIT: Oh, hab gerade gesehen, dass du eh eine LinkedList verwendest. ^^

Ja, da du schon recht hast, dass eine LinkedList besser wäre ^^

**Engel der Furcht** · 07.05.2013 19:24

Vielen Dank für eure Hilfe :>

Hab da noch ne Frage (ich fühl mich so n00by hier

)

Ich hab eine Klasse. In dieser Klasse wird ein Objekt einer anderen Klasse erzeugt.
Jetzt wird in diesem Objekt eine Methode aufgerufen und diese Methode soll aber in eine TextArea aus der ersten Klasse (also der Objekt-Erzeuger-Klasse) schreiben.
Geht das irgendwie? :>

**Whiz-zarD** · 07.05.2013 19:27

Ja.
Würde ich aber nicht machen, da dies gegen das Model-View-Controller-Prinzip verstößt.
Zeige doch mal konkret, was du vor hast.

**Engel der Furcht** · 07.05.2013 19:32

Woah, mein Lehrer hat sogar mal davon gefaselt

Er meinte, dass das für uns zu kompliziert sei, die einzelnen Dinge zu trennen.

**Whiz-zarD** · 07.05.2013 19:35

So kompliziert ist das gar nicht. Gerade in Sprachen, wie Java oder C# ist das recht einfach einzuhalten. In Sprachen, wie php sieht es schon wieder ein wenig anders aus, ist aber auch möglich.
Sag also konkret, was du vor hast, und ich könnte dir da auch weiterhelfen.

**Rusk** · 07.05.2013 19:36

Zitat von Engel der Furcht

Woah, mein Lehrer hat sogar mal davon gefaselt

Er meinte, dass das für uns zu kompliziert sei, die einzelnen Dinge zu trennen.

Er soll nicht nur davon faseln, sondern es euch auch beibringen.
Ob was kompliziert zu trennen oder nicht ist, hängt ganz von der Programmierweise ab und natürlich von der Sprache selbst.

EDIT: Whiz-zarD war schneller. ^^

**Engel der Furcht** · 07.05.2013 19:40

Zitat von Whiz-zarD

So kompliziert ist das gar nicht. Gerade in Sprachen, wie Java oder C# ist das recht einfach einzuhalten. In Sprachen, wie php sieht es schon wieder ein wenig anders aus, ist aber auch möglich.
Sag also konkret, was du vor hast, und ich könnte dir da auch weiterhelfen.

Nunja, wie ich gesagt hab: Ich hab eine Klasse (die von Frame erbt), in dieser Klasse wird ein Objekt erzeugt. Dieses Objekt soll in eine TextArea aus der ersten Klasse schreiben.

**Whiz-zarD** · 07.05.2013 20:27

Direkt nach TextArea würde ich nicht schreiben, dann wäre die Instanz eines erzeugten Objektes abhängig von deiner Frame-Instanz, und genau das will das Model-View-Controller-Prinzip verhindern.
Klassen, die die Daten bereitstellen, sollen unabhängig von Klassen sein, die die Anzeige bereitstellen. Angenommen, du erzeugst eine Tabelle und willst sie sowohl in Tabellenform, als auch als Diagramm darstellen. Es wäre dann sehr unklug, wenn die Klasse, die die Tabelle (= Model) erzeugt, abhängig von der jeweiligen View ist.

Schreib die Methode so, dass sie dir die Informationen liefert, die du benötigst und gib diese Daten als Rückgabewert zurück.
Dann kannst du mit Hilfe dieser Daten den String zusammenbauen (in deiner Frame-Instanz), der in der TextArea angezeigt werden soll.

**Engel der Furcht** · 09.05.2013 21:53

Ich hab das ganze mit einem Interface gelöst.
UNd stehe gerade vor einem erneuten Problem:

Ich hab 'ne Klasse, in der ein Objekt erzeugt wird, das von Thread erbt.
In diesem Thread wartet ein Socket auf Empfang von Daten.
Ich kann den Thread nicht schließen/killen/terminieren/whatever.
Ich kann von der Oberklasse auch nicht auf das Socket zugreifen und es schließen.
Hier mal mein Programmcode:

Code:

package UDP;

import java.awt.*;
import java.awt.event.*;
import java.io.IOException;
import java.util.*;
import java.net.*;
import java.util.logging.Level;
import java.util.logging.Logger;

public class UDPTransceiver extends Frame implements ActionListener,
        ReceiverInterface
{

  private Label adressnumber;
  private TextArea history;
  private TextArea sendArea;
  private Panel centerPanel;
  private Button sendButton;
  private Receiver receiver;
  private InetAddress address;
  private byte[] data;
  public boolean receiverON = false;
  private DatagramSocket socket;
  private DatagramPacket packet;
  private String name;
  MenuBar mb;
  Menu logMenu;
  MenuItem openLog;

  public UDPTransceiver(String name, InetAddress address)
  {
    super(name);
    this.address = address;
    this.name = name;
    makeGUI();
    setSize(500, 500);
    sendButton.addActionListener(this);
    setVisible(true);

    addWindowListener(new WindowAdapter()
    {

      public void windowClosing(WindowEvent windowEvent)
      {
        if (receiverON)
        {
          receiver.status = false;
          System.out.println(receiver.status);
          receiver.socket.close();
          receiver.interrupt();
        }
        dispose();
      }
    });
    runReceiver();
  }

  private void makeGUI()
  {
    mb = new MenuBar();
    logMenu = new Menu("Log");
    openLog = new MenuItem("Logdatei öffnen");
    logMenu.add(openLog);
    mb.add(logMenu);
    setMenuBar(mb);
    adressnumber = new Label();
    history = new TextArea();
    sendArea = new TextArea();
    centerPanel = new Panel();
    sendButton = new Button("Senden");
    setLayout(new BorderLayout());

    centerPanel.setLayout(new GridLayout(2, 1));
    centerPanel.add(history);
    centerPanel.add(sendArea);
    add("North", adressnumber);
    add("Center", centerPanel);
    add("South", sendButton);
    history.setEditable(false);
  }

  public void actionPerformed(ActionEvent event)
  {
    if (event.getSource() == sendButton)
    {
      send();
    }
  }

  private void runReceiver()
  {
    receiverON = true;
    receiver = new Receiver(address, this);
  }

  private void send()
  {
    try
    {
      logMessage("Du - " + new GregorianCalendar().get(Calendar.HOUR_OF_DAY)
              + ":"
              + new GregorianCalendar().get(Calendar.MINUTE) + ":"
              + new GregorianCalendar().get(Calendar.SECOND) + ":\n "
              + sendArea.getText()
              + "\n");
      socket = new DatagramSocket();
      data = new byte[sendArea.getText().length()];
      data = sendArea.getText().getBytes();
      packet = new DatagramPacket(data, data.length, address, 4711);
      try
      {
        socket.send(packet);
      }
      catch (IOException ex)
      {
        System.out.println(ex);
      }
    }
    catch (SocketException ex)
    {
      System.out.println(ex);
    }
  }

  public void logMessage(String message, InetAddress receiveIp)
  {
    history.append(receiveIp + " - "
            + new GregorianCalendar().get(Calendar.HOUR_OF_DAY) + ":"
            + new GregorianCalendar().get(Calendar.MINUTE) + ":"
            + new GregorianCalendar().get(Calendar.SECOND) + ":\n" + message);
  }

  public void logMessage(String message)
  {
    history.append("\n" + message + "\n");
  }

  public static void main(String args[]) throws UnknownHostException
  {
    new UDPTransceiver("Lokal", InetAddress.getByName("localhost"));
  }
}

Is das mit dem WindowAdapter eigentlich so richtig, ich kriege immer eine NullpointerException(der receiver existiert doch?)

Jedenfalls kann ich den Thread nicht schließen und habe irgendwie auch sonst keinen Zugriff auf Attribute etc.
Ich kann also receiver.socket.close() nicht anwenden und receiver.status kann ich auch nicht auf false setzen.
receiver.interrupt(), .stop() etc. kann ich auch nicht anwenden.

Als Test ist Sender/Empfängeraddresse auf Localhost gesetzt. "Senden" und "Empfangen" kann ich wohl und auch die ganze Zeit.

**Whiz-zarD** · 10.05.2013 09:46

Zitat von Engel der Furcht

Ich hab das ganze mit einem Interface gelöst.

Für so ein Problem sind Interfaces nicht gedacht.

Zitat von Engel der Furcht

UNd stehe gerade vor einem erneuten Problem:

Ich hab 'ne Klasse, in der ein Objekt erzeugt wird, das von Thread erbt.

Und hier wäre es nun schlauer, du machst dich mit dem Model-View-Controller-Prinzip vertraut.
Ein Fenster, dass ein Thread startet und auf UDP-Daten wartet ist ein absolutes No-Go.
Dies muss der Controller übernehmen und nicht die View, oder möchtest du in jedem Fenster die selben Methoden implementieren?

IdR wird hierfür ein eigener Thread gestartet, der rein nur fürs Empfangen der Daten zuständig ist. Fenster, die auf empfangene Daten reagieren wollen, registrieren sie sich dann mittels eines Listeners und der Thread gibt dann dem Fenster die nötigen Informationen. Beim Schließen des Fensters muss aber tunlichst darauf geachtet werden, dass sie sie wieder deregistrieren.

Zitat von Engel der Furcht

In diesem Thread wartet ein Socket auf Empfang von Daten.
Ich kann den Thread nicht schließen/killen/terminieren/whatever.
Ich kann von der Oberklasse auch nicht auf das Socket zugreifen und es schließen.

Threads sind sowieso sehr böse, wenn man nicht weiß, was man da tut. Als Einführung kannst du dir ja mal den Wiki-Artikel über das Philosophenproblem durchlesen.

Zitat von Engel der Furcht

Is das mit dem WindowAdapter eigentlich so richtig, ich kriege immer eine NullpointerException(der receiver existiert doch?)

Ich kann das hier nur überfliegen, aber der Thread wird ja auch erstmal gar nicht gestartet.
Die Methode windowClosing() erzeugst du ja in einer anonymen Unterklasse. Die Unterklasse hat aber einen anderen Namensraum, als deine Oberklasse, und deswegen ist für die Unterklasse reveicer gleich Null. Es gibt nun mehrere Wege:

Du benutzt in der Unterklasse ein qualifiziertes this. also anstatt receiver.socket.close(); schreibst du dann UDPTransceiver.this.receiver.socket.close();. Dann weiß die anonyme Unterklasse, dass es auf die umschließende Oberklasse zugreifen soll.
Du deklarierst receiver als statisch. Wohlmöglich sogar als final static.

Zitat von Engel der Furcht

Jedenfalls kann ich den Thread nicht schließen und habe irgendwie auch sonst keinen Zugriff auf Attribute etc.
Ich kann also receiver.socket.close() nicht anwenden und receiver.status kann ich auch nicht auf false setzen.
receiver.interrupt(), .stop() etc. kann ich auch nicht anwenden.

Um überstürzt einfach versuchen, irgendwelche Methoden aufzurufen, solltest du dich einfach mal kontrollieren, ob die Objekte überhaupt existieren. Wenn du eine Null-Pointer-Exception bekommst, dann heißt das schon, dass da schon irgendwas nicht existiert. Hast du dich eigentlich schon mal mit dem Debugger beschäftigt?

Zitat von Engel der Furcht

Als Test ist Sender/Empfängeraddresse auf Localhost gesetzt. "Senden" und "Empfangen" kann ich wohl und auch die ganze Zeit.

Das heißt also, du weißt es nicht? Bei Netzwerk-Programmierung ist es immer vom Vorteil, man hat einen Netzwerk-Sniffer ala WireShark zur Hand und schaut sich die Datenpakete an, die verschickt werden.

**Corti** · 10.05.2013 19:36

Mal ganz doof gefragt ( ich hab mit Java nie groß was gemacht ).

Was bringt es von Thread zu erben? Tut man das in Java so? Oder ist hier mit "Thread" was anderes gemeint als das was man von C# System.Threading.Thread bzw. C++ boost::thread kennt?

**Rusk** · 10.05.2013 20:16

Zitat von Corti

Mal ganz doof gefragt ( ich hab mit Java nie groß was gemacht ).

Was bringt es von Thread zu erben? Tut man das in Java so? Oder ist hier mit "Thread" was anderes gemeint als das was man von C# System.Threading.Thread bzw. C++ boost::thread kennt?

Ja, das tut man so in Java. Die Thread-Klasse implementiert nämlich das Interface Runnable, welche die Methode run() implementiert.

**Corti** · 10.05.2013 22:56

Ah stimmt, Java hat's ja nicht so mit Funktionszeigern/Delegaten/ähnlichen Konstrukten.

**R.D.** · 11.05.2013 14:04

Delegaten hat Java aber doch o.o Nur nicht nach Definition von C/C++. Man löst das dann halt über Interfaces oder so. Allerdings wünschte ich mir oft eine Methode direkt angeben zu können.

Man muss btw nicht von einem Thread erben. ein Thread Objekt stellt ein Runnable bereit allerdings kann man auch sein eigenes angeben (etwa im C'Tor). Man muss also nicht immer gleich vererben wenn man nur einen kurzen Task ausführen will.

@Topic
Ich arbeite gerade an WebAudio Kram für CrossCode. Ich glaube das ist die Beste Audio API die ich bisher hatte. Für Spiele ist es eben nicht nur wichtig einen Sound abzuspielen oder ein Musikstück (So wie das viele Engines eben tun, also für Spiele), sondern nutzt ein Graphen über den ein Sound/Musikstück bis zum "Destination"-Knoten wandert. dadurch ist es super einfach global volume oder effekte einzubauen. Stellt euch vor ihr habt einen Track der sich mit der Umgebung anpasst. Halt wie bei Zelda. Das ist mer API relativ einfach möglich. Man nimmt einfach die einzelnen Instrumente und spielt alles gleichzeitig ab, dann faded man zwischen den Instrumenten schön hin und her.

**Mivey** · 11.05.2013 15:05

@Web-Audio
Wird das außerhalb von Chrome schon unterstützt?

Thema: IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

Themen-Optionen

Anzeige

Berechtigungen