OnClick Methodenaufruf vs. OnClicklistener

[GonzoTM]

Hallo,

Ich bin noch relativ neu hier also nicht gleich hauen ....

Ich wollte mal fragen ob es einen großen Unterschied zwischen dem OnClicklistener und dem Methoden Aufruf in der XML datei gibt?

Außer das sie anders aussehen....Das die OnClick Methode erst ab Android 1.6 gibt hab ich schon rausgefunden...Ich frag mich eher ob sich das auf Performance oder Sicherheit auswirkt.

Denn prinzipiell finde ich den Methodenaufruf angenehmer und übersichtlicher zu programmieren.

Hoffe die Frage wurde nicht schon 20 mal gestellt habe sie in Google nämlich nur einmal auf Englisch gefunden und mein Englisch ist very bad

Ich kann mir zwar das meiste aus den Zeilen herrauslesen aber man übersieht da ja mal schnell was.

Schonmal vielen Dank an alle die sich die Zeit nehmen das hier zu lesen

Gruß

GonzoTM

 

[Zoopa]

Theoretisch ist die XML-Version etwas langsamer, weil da ein zusätzlicher Aufruf über Reflection stattfindet, siehe dieses Code-Beispiel. Ich denke aber nicht, dass das schlussendlich spürbar ist, es handelt sich vermutlich nur um einige Millisekunden.

Die "normale" Listener-Variante ist flexibler, weshalb ich nur diese verwende. Du kannst damit den Listener zum Beispiel in eine eigene Klasse auslagern, was bei der XML-Variante nicht geht. Dort wird die Methode immer an eine Activity gebunden (dabei muss man vielleicht noch aufpassen, wenn man mit Fragmenten arbeitet?).

 

[GonzoTM]

Ja ok, dass erklärt auch warum so viele den Listener benutzen und relativ wenige Beispiele mit der XML Methode im Netz unterwegs sind. Und ein Problem was ich schon mal hatte ....

Aber ich denke ich werde dann in Zukunft versuchen beides zu benutzen und was wir dann die wenigsten Probleme macht dann übernehmen.

Naja hat alles seine Vor- und Nachteile...ich finde halt die XML Variante ist schneller zu Tippen....

 

[markus.tullius]

Ein weiterer Grund, der gegen die xml - Methode spricht, ist die Wartbarkeit.

Bei der normalen Methode sieht man sofort, welcher View ein OnClickListener hat. Bei der anderen Methode muss man immer in der xml - Datei nachschauen. Besonders wenn mehrere an einem Projekt arbeitet, erleichtert es die Programmierung.

 

[GonzoTM]

Das ist doch wiederum nur ein Grund wenn man die Methoden nicht eindeutig beschriftet.

Bei dem listener hat man ja auch nur die id un ne zusätzliche variable. Wenn ich die Methode aber so eindeutig beschrifte wie die id kann man doch beides relativ genau unterscheiden....

Den unterschied zu den normalen Methoden erkennt man alleine am View...

Also ich merke schon abgesehen davon das der Listener einem mehr Freiheit lässt wie oben beschrieben ist es mehr Geschmackssache

 

[markus.tullius]

Und du glaubst wirklich, dass Du in zwei Jahren noch durch deinen Code steigst. Und genau weiß, wo alles im den xml - Dateien steht, und welche Beschriftung, was bedeutet.

Du wärst nicht der erste, der ein Programm neu schreibt, weil er sein Code nicht mehr versteht.

 

[GonzoTM]

Aber das hat doch nichts mit den unterschiedlichen Lösungswegen zu tun sondern mit dem Programmieren allgemein.

mal zwei kurze Beispiele:

Button button = (Button) findViewById(R.id.button1);
    button.setOnClickListener(new OnClickListener() {
       @Override

            public void onClick(View view) {
           Toast.makeText(MainActivity.this, "Button Clicked", Toast.LENGTH_SHORT).show();

            }
        });

oder:

public void Button1 (View view) {
Toast.makeText(MainActivity.this, "Button Clicked", Toast.LENGTH_SHORT).show();
}

Erkennt keiner mehr auch nach einem Monat schon.

Wenn man aber das ganze so aufbaut:

Button btToast = (Button) findViewById(R.id.bt_main_toast);
    btToast.setOnClickListener(new OnClickListener() {
       @Override

            public void onClick(View view) {
           Toast.makeText(MainActivity.this, "Button Clicked", Toast.LENGTH_SHORT).show();

            }
        });

oder:

public void BtMainToast (View view) {
Toast.makeText(MainActivity.this, "Button Clicked", Toast.LENGTH_SHORT).show();
}

Plus die Beschriftung die man immer machen sollte kommt es doch bei beiden auf das gleiche.

Es ist halt wirklich der Aufbau der Namen die man vergibt....ich hab mir halt von Anfang an angewöhnt "Art der View"+"Layout"+"Funktion"....somit sollte ich immer Anhand des Kürzels die Richtige stelle finden.

Nartürlich hast du auch irgendwo Recht das man bei dem Listener alles beisammen hat aber wenn die ID wirklich nicht mit System angelegt ist sucht man sich da in den XML Dateien auch den Wolf ....

 

[markus.tullius]

BtMainToast(View view) wäre so ein Grund. Eine groß geschriebene Methode, die nicht mit ein Verb anfängt.

Ein wirklich guter Weg, andere Programmierer in den Wahnsinn zu treiben.

Es gibt ein paar Regeln, wie man Code schreiben sollte. Man muss sich nicht daran halten, aber es erhöht die Lesbarkeit des Codes:

https://source.android.com/source/code-style.html

 

[Zoopa]

Mir geht es meistens um die Organisation von meinem Code. Ich find ehrlich gesagt auch die Inline-Listener nicht allzu schön. Statt

sendEmail.setOnClickListener(new OnClickListener() { ... })

habe ich lieber eine eigene Klasse für den Listener:

public class SendEmailListener implements OnClickListener { ... }

und dann in der Activity:

sendEmailButton.setOnClickListener(new SendEmailListener());

Wieso?

Weil der Code vom Listener meiner Meinung nach unabhängig von dieser einen Activity sein sollte, also will ich den Code nicht inline in genau dieser Activity haben.
Wenn ich den Listener auslagere, kann ich ihn an beliebigen Orten verwenden.

 

[GonzoTM]

@Zoopa: ja ok das verstehe ich...ist auch ne schöne Lösung. Damit nutzt du auch gleich den Vorteil des Listeners aus. Nur sowas sieht man in den Anfängen so gut wie gar nicht, deshalb war das, bis jetzt, mir auch neu.

@markus.tullius: Dann schreibt man halt das Bt halt klein oder setzt noch ein Verb davor, ein "click" zum Beispiel

Das war doch nur ein Beispiel^^...also entweder verstehen wir uns falsch oder du willst mich mit sehr seltsamen Argumenten einfach davon abbringen die XML Methode zu benutzen....

Was ich damit oben zeigen wollte es hat doch nichts mit dem Lösungsweg zu tun sondern viel mehr vom beschriften der Variablen und Methoden....der Compiler versteht alles (fast ) aber man selbst nach einer Zeit nicht mehr wie du ja schon oben angeprangert hast. Deshalb ist es ja so wichtig alles richtig zu beschriften und das ist in jeder Programmiersprache so.

Oder sehe ich das sooooo Falsch?

btw: In deinem Beispiel Link ist auch ein Methode ohne Verb und so super Allgemein func() .....

Aber ich gebe dir recht man sollte sich an manche allgemeinen Programmier Regeln halten, dass es auch ein anderer versteht.

Nimm es mir nicht böse aber ich sehe das Problem das du da siehst einfach nicht so.

 

[DieGoldeneMitte]

Nimm es mir nicht böse aber ich sehe das Problem das du da siehst einfach nicht so.

Dass Anfänger etwas nicht so sehen wie Erfahrene, ist normal. Sollte der Anfänger deshalb Empfehlungen in den Wind schlagen?

Das doofe an den XML-OnClickListenern ist, dass es sich nur um eine Sorte von Listenern handelt. Die anderen musst du ohnehin im Code mit deinen Views verbinden. Bei einer komplexeren Anwendung hättest du also zwei Stellen, wo du Aktion mit View verbindest. Das ist Schlecht.

@zoopa: Leider ist es mit der Reusability nicht weit her, da du in den Listenern meist auf die Instanzvariablen der Activity/des Fragments zugreifen musst/willst. Ich warte ja sehnsüchtig auf Lambdas als Listener

 

[markus.tullius]

Ich warte ja sehnsüchtig auf Lambdas als Listener

Dem kann ich mich nur anschließen.

@GonzoTM

1) Es geht mir hier nicht um die Machbarkeit. Das Problem sehe ich in der Wartbarkeit. Dein Listener befindet sich in an mindesten zwei Stellen im Code (bei verschieden Auflösungen /Orientierungen können es auch mehr Stellen sein). Jede Änderung (z.B Namensänderung) muss an mehreren Stellen durchgeführt werden. Da kann man sehr schnell etwas übersehen.
Ich durfte mal ein Projekt übernehmen, wo die Listener im den xml - Dateien definiert wurden. Da suche ich doch lieber Ostereier.

2) Als Programmierer arbeitet man häufiger mit anderen zusammen. Besonders wenn man in einer größeren Firma arbeitet. Spätestens wenn der andere Entwickler einen nicht versteht, wird es sehr lustig. Da kann die eigene Notation noch so gut sein, die Begeisterung auf der anderen Seite wird nicht sehr groß sein.
Bei Java und Android gibt es ein paar Gepflogenheiten, wie Code aussehen sollte. Z.B. Methoden werden kleingeschrieben, und fangen immer mit ein Verb an. Klassen werden groß geschrieben. usw.

Beim Android Open Source Project (AOSP) gelten folgende Regeln:
https://source.android.com/source/code-style.html

Da steckt viel Grips und Erfahrung vieler guter Entwickler drin.

 

[amfa]

Noch ein Argument gegen die XML Definition:

Da geht die Trennung zwischen Code und Layout (ein wenig) verloren.
Solange du alles selber machst ist das weniger ein Problem, aber sobald z.B. jemand anderes das Layout macht gibt es eher probleme, da dieser dann Wissen muss wie die Methode im Code heißt.

Andersrum ist es einfach, da die IDE bei den Ids der Elemente mit Autovervollständigung hilft.

Mit der XML hast wie gesagt eine zu große Verknüpfung zwischen Code und Layout meiner Meinung nach. Das gehört da einfach nicht hin

 

[ui_3k1]

Theoretisch ist die XML-Version etwas langsamer, weil da ein zusätzlicher Aufruf über Reflection stattfindet, siehe dieses Code-Beispiel. Ich denke aber nicht, dass das schlussendlich spürbar ist, es handelt sich vermutlich nur um einige Millisekunden.

Grundsätzlich stimme ich überein, aber wie verhält sich die Sache, wenn wir (unrealistisch) annehmen, dass ein Layout 1000 Buttons aufweist?
Wenn wir durch if-else die Abfrage durchführen, müsste der Performance-Verlust größer sein, als wenn wir die Abfrage durch switch-case (also optimiert) bestimmen. <- hier bin ich mir zu 99% sicher...
Bei der xml-Variante sollten die Referenzen schon zur Laufzeit in der R-Datei bekannt sein und der Code würde meiner Meinung nach schneller ausgeführt werden. <- stimmt diese Annahme?

Aber in der Praxis gefällt mir die "onClick-Variante" ebenfalls besser, da klarer strukturiert.

 

[JustinTime]

Da ich sowieso Butterknife benutze um die Views zu initialisieren nutze ich auch immer direkt die möglichkeit die onClicks einzurichten.

Das sieht dann so aus (aus dem Beispiel)

@OnClick(R.id.submit)
public void submit() {
  // TODO submit data to server...
}

find ich eigentlich ganz gut.

 

[Zoopa]

@zoopa: Leider ist es mit der Reusability nicht weit her, da du in den Listenern meist auf die Instanzvariablen der Activity/des Fragments zugreifen musst/willst

Wenn man das von Anfang an schön plant, designt und sich der Mehraufwand lohnt, kann man das schon so aufbauen, dass es klappt. Man kann die Schnittstellen zu den Activities ja mit Interfaces abstrahieren, damit der Listener nicht direkt den Aufbau der Activity kennen muss.
Aber es gibt natürlich genug Fälle, wo sich das nicht lohnt Ich verwende aber auch dann eigene Klassen für meine Listener, weil ich mir das so angewöhnt habe und ichs so übersichtlicher finde.

@ui_3k1: Da überfragst du mich Ich hatte bei der ursprünglichen Frage selbst nicht gewusst, wie das funktioniert. Dann habe ich beim recherchieren den verlinkten Stackoverflow-Beitrag gefunden. Ohne es genau zu wissen, verstehe ich den Beitrag so, dass es für jede Button-Instanz einen Mehraufwand gibt, selbst wenn alle denselben Listener hätten. Aber das ist nur ein unbelegtes Gefühl

 

[GonzoTM]

Dass Anfänger etwas nicht so sehen wie Erfahrene, ist normal. Sollte der Anfänger deshalb Empfehlungen in den Wind schlagen?

Sehe ich genau so, nur ich habe den Erfahrenen nicht direkt verstanden und habe das Problem nicht erkannt.

Deshalb hab ich den Thread ja überhaupt erst erstellt, weil ich wissen wollte was mehr Sinn macht.

Spätestens hier muss ich dann auch ein wenig einlenken

(bei verschieden Auflösungen /Orientierungen können es auch mehr Stellen sein)

denn schon sind es mehrere Stellen, was wirklich zur Verwirrung führen kann.

Beim Android Open Source Project (AOSP) gelten folgende Regeln:
https://source.android.com/source/code-style.html

Danke dir für die Ratschläge werde ich mir demnächst mal genauer durchlesen.