Ciao,
per un progetto universitario stò studiando Android che di fatto è Java e vorrei un chiarimento sull'uso delle classi innestate anonime di Java e del loro utilizzo.
Stavo studiando questo esempio che semplicemente gestisce 2 bottoni assegnandogli un listener con tale tecnica, ecco quì il codice (molto commentato):
Praticamente sulla guida che stò leggendo dice che questa tecnica di gestione fà risparmiare linee di codice e tempo rispetto a quella che consiste di far implementare alla classe attività le interfacce dei listener e che praticamente in questo caso si crea e si registra allo stesso tempo il gestore dell'evento di click e che poi ci pensa il compilatore a separare la classe anonima innestata su di un apposito file .classcodice:package mieapplicazioni.test;
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.Toast;
public class TestActivity extends Activity {
// Richiamato non appena l'attività viene creata
@Override
public void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState); // Invoca il costruttore del supertipo
// Parte personale del metodo:
setContentView(R.layout.main); // Setta il layout prendendolo in /res/layout/main.xml
/* Richiama i bottoni: il metodo findViewById() ricerca nel layout caricato un componente
* avente l'ID specificato come argomento. A questo punto il bottone può essere caricato
* e manipolato */
Button bottone01 = (Button) findViewById(R.id.bottone01);
Button bottone02 = (Button) findViewById(R.id.bottone02);
bottone01.setOnClickListener(new OnClickListener(){ // Aggiungo un gestore d'eventto al bottone
@Override
public void onClick(View v) {
clickSuBottone01();
}
});
bottone02.setOnClickListener(new OnClickListener(){ // Aggiungo un gestore d'eventto al bottone
@Override
public void onClick(View v) {
clickSuBottone02();
}
});
}
// Gestisce l'evento del click sul bottone 1 stampando un messaggio
private void clickSuBottone01(){
Toast toast = Toast.makeText(this, "Hai cliccato il bottone 1!", Toast.LENGTH_SHORT);
toast.show();
}
// Gestisce l'evento del click sul bottone 2 stampando un messaggio
private void clickSuBottone02(){
Toast toast = Toast.makeText(this, "Hai cliccato il bottone 2!", Toast.LENGTH_SHORT);
toast.show();
}
}
Slo che non capisco esattamente cosa stà facendo...di fatto dov'è che stò usando queste benedette classi anonime innestate nel mio codice?
Grazie
Andrea
[Java/Android] Chiarimento su Classi innestate anonime di Java per fare event listene
Visualizzazione stampabile
-
05-09-10, 18:23AndreaNobili[Java/Android] Chiarimento su Classi innestate anonime di Java per fare event listene
-
05-09-10, 20:30sprik
Mah, si risparmi codice ma, a mio parere, brutto da vedere ed a livello ingegneristico ne avrei da ridire molto...
Il modo migliore, sempre a mio parere, è fare classi a parte per i vari listener (da qui classi anonime?). -
05-09-10, 21:04AndreaNobili
eh infatti sulle dispense del mio professore prima fà come dici te, crea una classe per ogni listener facendogli implementare la relativa interfaccia e poi le usa nelle attività mi pare...
Poi però fà vedere quest'altro modo per risparmiare codice e dice che è quello maggiormente usato e consigliato...fatto stà che non l'ho capito a fondo (se mi puoi dare qualche info magari te ne sarei grato...) a me francamente fà un po' cagare perchè mi pare molto poco leggibile... -
05-09-10, 21:13sprik
esattamente, è poco leggibile...principalmente quando si parla di programmazione ad oggetti non si risparmia mai codice su questo. Solo che la lagnusia mangia sempre le mani a tutti.
Listener su classi separate permettono una migliore revisione del codice, oddìo ti dovresti muovere su più file, ma vabbè...sempre più leggibile...
Come incapsulamento...uhm...qui bisogna vedere che ti risponderebbe il prof sulla validità delle due opzioni, io preferirei sempre la mia. -
05-09-10, 22:35AndreaNobiliOk...ma mi puoi spiegare brevemente cosa sono queste classi innestate anonime e dove starebbe la classe innestata nel mio codice che non ce l'ho troppo chiara questa cosa?Quote:
Originariamente inviato da sprik
Grazie
Andrea -
05-09-10, 23:12sprik
le classi innestate anonime sono classi definite all'interno di un metodo o di un corpo di una classe stessa. sono anonime appunto perchè non hanno un nome:
Qui il gestore che aggiungi (il listener) è una classe anonima in quanto non specifichi l'identificatore della classe ma ne fai una breve descrizione.
Questo tipo di classi sono utilizzate spesso per questo genere di cose ma con gestore piccoli, se devi fare molte operazioni è consigliabile fare la classe a parte in modo da dividere il codice e semplificare la lettura dello stesso. -
06-09-10, 00:56AndreaNobili
Ti ringrazio,
ora è tutto molto chiaro...beh credo che opterò per il metodo classico della classe separata che implementa l'apposita interfaccia del gestore...ora che ho capito di cosa si trattano confermo la mia antipatia verso tale metodo...
Grazie
Andrea -
06-09-10, 01:00sprik
ahahah, eh si...se ci metti un bel po' di codice diventa veramente inguardabile, anche se metti poi metodi appositi è sempre brutto a livello professionale...meglio la classe a parte.
-
10-09-10, 14:29Demolitions
Scusate la "niubbezza" della domanda, ma non possiamo implementare onClickListener nella classe TestActivity e gestire l'evento onClick direttamente da quella?
qualcosa tipo:
codice:package mieapplicazioni.test;
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.Toast;
public class TestActivity extends Activity implements onClickListener{
// Richiamato non appena l'attività viene creata
@Override
public void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState); // Invoca il costruttore del supertipo
// Parte personale del metodo:
setContentView(R.layout.main); // Setta il layout prendendolo in /res/layout/main.xml
/* Richiama i bottoni: il metodo findViewById() ricerca nel layout caricato un componente
* avente l'ID specificato come argomento. A questo punto il bottone può essere caricato
* e manipolato */
Button bottone01 = (Button) findViewById(R.id.bottone01);
Button bottone02 = (Button) findViewById(R.id.bottone02);
bottone01.setOnClickListener(this);
bottone02.setOnClickListener(this);
}
// Gestisce il click su entrambi i bottoni
public void onClick(View v) {
// Qua ci va una decisione su chi ha generato l'evento, in Java usavo if(e.getSource() instanceof BOTTONE) && (e.getSource().getName().equals(NOMEBOTTONE))
// clickSuBottone01(); o clickSuBottone02();
}
// Gestisce l'evento del click sul bottone 1 stampando un messaggio
private void clickSuBottone01(){
Toast toast = Toast.makeText(this, "Hai cliccato il bottone 1!", Toast.LENGTH_SHORT);
toast.show();
}
// Gestisce l'evento del click sul bottone 2 stampando un messaggio
private void clickSuBottone02(){
Toast toast = Toast.makeText(this, "Hai cliccato il bottone 2!", Toast.LENGTH_SHORT);
toast.show();
}
}
-
10-09-10, 15:44sprik
per quanto mi ricordi, si
-
10-09-10, 16:27CymonMh, sono uno che fa classi nuove (rigorosamente in file separati) anche solo per ridefinire il nome di un metodo che non ha la camel notation giusta ;) però ammetto che il modo "classico" di fare i listener instanziandoli direttamente nella set alla fine non l'ho mai trovato così terribile.Quote:
Originariamente inviato da sprik
Sarà che "tradizionalmente" si fa così e anche gli esempi del secolo scorso fanno così :D, ma non mi sembra così brutto. Più che altro vale il fatto che è difficile poter effettivamente riciclare un listener tra più chiamate e spesso il codice non è molto significativo, trattandosi spesso di "ponti" verso altro.
A questo punto trovo più elegante la soluzione di Demolitions... -
10-09-10, 16:31sprik
non mi piacciono i "ponti", sarà perchè ancora quello sullo stretto non ce l'hanno voluto costruire e non lo faranno mai...XD
A parte gli scherzi, si è vero, alla fine richiami altri metodi e risolvi tutto però esteticamente non mi piace. Ovviamente quest'ultima affermazione è da ritenersi strettamente personale. -
10-09-10, 17:22or3
in esempi cosi piccoli le classi anonime (che comunque inquinano la leggibilita) ci possono anche stare, come regola per queste "sporcature" di solito uso "il tutto deve pero restare entro una sola schermata del mio editor" in modo da avere il tutto sott'occhio
casi come questo li trovi appunto in esempi "didattici", difficilmente in una qualsiasi app dovrai solo mostrare un toast
sempre meglio classi separate: ti garantisci la riusabilita, ti faciliti le eventuali modifiche postume e soprattutto non ti maledirai quando andrai a riaprire quel codice 1 anno dopo che l'hai scritto, sicuramente e' piu leggibile.
Per quanto riguarda le prestazioni, sinceramente non so, anche considerando il caso pessimo (a meno che tu non stia facendo un sistema real-time, ma non credo su un cell :D ) penso che coi processori di oggi ci si possa anche permettere di sciupare qualche microsecondo.
