OnClickListener für mehrere Buttons

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • OnClickListener für mehrere Buttons

    Hallo,

    ich habe mehrere Buttons in meiner App und zurzeit habe ich für alle Buttons (mitlerweile sind es ganze 15 Stück) nur einen OnClickListener, der mithilfe einer if-Abfrage herausfindet, welcher Button gedrückt wurde, woraufhin die gewünschte Aktion ausgeführt wird.
    Meine Frage ist, ob es nicht sinnvoller ist für jeden einzelnen Button einen eigenen OnClickListener zu implementieren? 8| :?:

    mfg
    MikeFry
  • Wenn sie alle was Anderes machen ist es sinnvoller, jedem seinen eigenen OnClickListener zu geben.
    Wenn sie alle dasselbe machen, ist es sinnvoller, ein und denselben OnClickListener zu benutzen.

    Wenn sie alle dasselbe mit anderen Werten machen (Beispielsweise diese dusseligen Soundboards), ist es sinnvoll, ein und denselben OnClickListener zu benutzen und den Buttons die Werte, die anders sind, mitzugeben.
    (Beispielsweise einen Standardbutton um einen String 'mediafile' erweitern und in der onClick eben diesen String auszulesen und an Hand dessen dann das Soundfile zu laden)
    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.

    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«
  • Da du mit if (wenn du es schon so machst, nimm vllt lieber switch case) arbeitest, gehe ich davon aus das die buttons jeweils unterschiedliche aktionen auslösen.
    In diesem fall solltest du wirklich auch verschiedene click listener benutzen. Natürlich geht beides, aber deine Variante ist programmatisch nicht so sauber.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Ben ()

  • Ist es nicht eher so das es am Programmierstil liegt? Als ich java gelernt habe, war es sozusagen normal "<Klasse> implements ActionListener" zu benutzen und den jeweiligen Elementen dann einfach .setActionListener(this); zu geben.
    mMn. hat das den Vorteil das man alle Actions zentral in einer Methode hat.

    Als ich dann irgendwann mit Android angefangen hab, mit Tutorials usw. war ich erst mal total verwirrt warum denn die Leute z.B. 5 Buttons direkt nacheinander mit separaten Listenern versehen haben :/ . Gehört anscheinend zum Programmierstil und nachdem ich mal, ich glaube sogar hier im Forum, nachgefragt habe konnte mir keiner wirklich sagen warum das so ist.

    Wären wir noch in den Zeiten als nach "Lines of Code" bezahlt wurde, würde ich verstehen warum es sich so entwickelt hat. :P

    Aber ich muss zugeben, das ich in Android auch eher die zweite Variante verwende, da man immer wieder mal ein Codeschnipsel aus dem Internet kopiert und es dort eben so gemacht wird 8)
    Ich benutze:
    Android Studio 1.0.1
    Build: AI-135.1641136
  • Den beschriebenen Beitrag finde ich gar nicht.

    Insofern versuche ich das hier zu erklären:
    Wenn Du <Klasse> implements ActionListener machst, dann leitest Du eine neue Klasse ab, Du nutzt also die Vererbung.
    Sagen wir, Du hast 9 unterschiedliche Buttons die das Gleiche tun. Dann kannst Du mit .setActionListener(this) jedem dieser Buttons Deine Klasse zuordnen und hast die Aktion an zentraler Stelle.

    Sagen wir, Du Du hast 9 unterschiedliche Buttons die unterschiedliche Dinge tun. Dann kannst Du mit .setActionListener(this) jedem dieser Buttons Deine Klasse zuordnen und hast die Aktion an zentraler Stelle. In diesem Fall musst Du die einzelnen Button irgendwie unterscheiden können.
    Oh, und ellenlange if Abfragen und switch Statements sind einerseits schwer zu lesen und andererseits schwer zu debuggen.

    Du kannst natürlich jedem der Buttons eigene Implementierungen eines ActionListener geben. .setActionListener(new ersteButtonActionListener())
    Damit legst Du für jede Aktion eine neue Klasse an.
    Die Variante .setActionListener(new ActionListener () { onAction() {} } ) zentralisiert das Ganze in eine einzige Klasse, so dass Du eben keine 9 einzelnen Dateien herumfliegen hast.
    Hier nutzt Du also nicht die Vererbung, sondern erstellst dynamisch konkrete Instanzen eines abstrakten Interface, die völlig unabhängig und losgelöst voneinander existieren.

    Tutorials sind ja kein Produktivcode. Da wird Dir nur gezeigt wie etwas grob funktioniert. Die Konzepte richtig anzuwenden musst Du schon selbst lernen.

    Die Frage, welche Variante man nimmt, hängt also immer davon ab, was genau man zu erreichen versucht.
    Dazu könnte es hilfreich sein, die Vor- und Nachteile zu kennen.

    Eigene Einzelklasse:
    Pro:
    • Kapselung
    • Zentraler Zugriff
    • Wiederverwendbar


    Contra:
    • Verleitet zur unübersichtlichen Verschachtelung bei Trennung der aufrufenden Objekte


    Eigene mehrere Klassen:
    Pro:
    • Wiederverwendbar


    Contra:
    • Bei starker funktionaler Ähnlichkeit mehrere Dateien zu pflegen


    Dynamisch erzeugte Objekte:
    Pro:
    • Schnell implementiert
    • Leicht zu testen


    Contra:
    • Schlecht wiederverwendbar
    • Verleitet bei ähnlicher Funktionalität zu doppeltem Code
    • Schwer zu lesen


    Man sieht also: Das beste Pro:Contra Verhältnis (3:1) hat die einzelne eigene Klasse.

    Bei den meisten UI Implementierungen tun die 9 Buttons auch alle das Gleiche – nur halt mit unterschiedlichen Werten.
    Alle spielen einen Sound ab – aber jeder einen Anderen. (SoundBoard)
    Alle öffnen einen neuen Screen – aber jeder einen Anderen (Button-Navigation)
    Alle tragen eine Ziffer in das Display ein – aber jeder eine Andere (Wähltasten, Taschenrechner, OnScreen Tastatur…)
    Alle navigieren zu einer Seite – aber jeder zu einer Anderen. (Browsertasten: Zurück/Reload/Nächste)

    Klar gibt es bei einigen UI unterschiedliche Aktivitäten pro Button, beispielsweise im Dateimanager Kopiere/Verschieben/Löschen.
    Da sollten das dann eine Klasse pro Listener werden.

    HTH :)
    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.

    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«
  • Marco Feltmann schrieb:

    Dynamisch erzeugte Objekte:Pro:


    Schnell implementiert

    Leicht zu testen


    Contra:


    Schlecht wiederverwendbar

    Verleitet bei ähnlicher Funktionalität zu doppeltem Code

    Schwer zu lesen
    Also ich finde das die einzelnen Listener Objekte genauso gut wiederverwendbar sind wie eine einzelne Klasse.
    Man ist wie deine überschrift schon sagt, mit dieser Variante einfach viel dynamischer. Außerdem ist es vom Programmierstil her einfach besser und die Listener befinden sich in der Regel immer in der dazugehörigen Layout Klasse.
  • ChampS schrieb:

    Also ich finde das die einzelnen Listener Objekte genauso gut wiederverwendbar sind wie eine einzelne Klasse.
    Dann erklär mir bitte mal, wie Du ein und denselben dynamisch generierten Listener drei unterschiedlichen Buttons zuweist.
    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.

    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«
  • Ich hab gerade die Android Syntax dafür nicht im Kopf, daher mach ichs mal an nem JavaFX Beispiel.
    Kein Gewähr für richtige Parameter oder Bezeichnungen, es ist eher Pseudocode, aber das Prinzip wird hoffentlich klar.

    private Button button = new Button();
    private Button button2 = new Button();

    private Eventhandler<ActionListener> listener = new Eventhandler<ActionListener>() {
    @Override
    public void handle(Event event) {
    HIER STEHT DEIN CODE
    }
    };

    button.setEventHandler(listener);
    button2.setEventHandler(listener);

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Ben ()

  • Damit legst Du eine Instanzvariable an. Ob die jetzt aus Deinem eingeschobenen Code kommt oder aus einer eigenen Datei ist ja egal.

    In einem anderen ListView wirst Du da allerdings nicht mehr ran kommen. ;)
    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.

    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«