Qual è il modo corretto di implementare l'interfaccia di OnClickListener per molti pulsanti

10

La mia attività Android contiene più pulsanti che hanno tutti bisogno di un OnClickListener. Ho visto molti modi diversi per farlo, come ad esempio:

  • Implementazione dell'interfaccia nella classe di attività
  • Creazione di una classe separata che implementa l'interfaccia
  • Definizione di una classe interna anonima per ciascun pulsante.

Ho visto molti esempi di ciascun approccio. Tuttavia, non mi è chiaro perché un approccio sarebbe stato usato al posto di un altro. Le differenze tra questi approcci sono stilistiche o ci sono ragioni che rendono un approccio migliore?

    
posta slayton 22.09.2011 - 19:13
fonte

2 risposte

6

Come per molte cose, l'approccio corretto dipende da cosa stai provando a fare per il pulsante specifico e cos'altro stai facendo con l'attività.

Interfaccia implementazioni sulle classi di attività :
Questa è una buona opzione quando si ha solo un tipo di attività da eseguire quando viene chiamato questo listener. Un esempio di questo sarebbe un semplice modulo con un numero di campi e un pulsante di salvataggio. Preferisco non avere il mio listener degli eventi per controllare la fonte dell'evento al fine di decidere cosa effettivamente deve essere fatto. So che alcuni potrebbero dire che si tratta di una questione di stile, ma credo che non richiedendo all'ascoltatore di effettuare questo controllo, il codice sarà più semplice da seguire poiché saprai esattamente cosa viene chiamato per ogni evento.

Un'interfaccia implementa una classe diversa :
Come ho detto sopra, preferisco questa opzione per quando ho più elementi in grado di sparare allo stesso evento. Estendendo l'esempio precedente, aggiungiamo un pulsante chiaro che richiede anche un listener di clic. Crea un listener che preforma le azioni di salvataggio e uno che preforma le azioni chiare. Ogni listener viene aggiunto solo ai componenti che produrranno quell'azione.

Questa implementazione ha un ulteriore vantaggio che puoi utilizzare se ti interessa. Il vantaggio è che impedisce ad altre classi di attivare l'evento all'interno della classe di attività. Poiché il metodo dell'interfaccia deve essere pubblico, chiunque abbia un riferimento alla classe può attivare l'evento. Se si desidera un controllo a grana fine su chi può fare cosa nell'applicazione, una classe separata impedisce a chiunque abbia un riferimento all'attività di attivare il modulo da cancellare o salvare (o potenzialmente di infrangere il codice se il listener utilizza il codice sorgente, ma lo fa) non gestire input errati).

Un'interfaccia interna anonima implementa la classe :
Questo è solo un modo specifico per costruire la seconda opzione di usare una classe diversa come implementazione. Questa opzione può anche limitare ulteriormente chi ha accesso ad attivare l'evento poiché nessun altro può creare un'istanza della classe. Tuttavia, penso che il fattore più importante tra le due opzioni sia la quantità di lavoro svolto. Cancellare alcuni campi di testo è un'operazione semplice e diretta. Tuttavia, il processo di salvataggio di for può comportare un numero di attività: si sta convalidando l'input (cosa che si dovrebbe fare), scrivendo su un database per memorizzare i valori e attivando un'azione di salvataggio post. In questo caso, creare una classe separata con il proprio file fornirà una divisione più chiara tra il modulo di input e l'elaborazione dei dati. Questo a sua volta mantiene il codice del modulo invece di un file più grande con più classi interne annidate all'interno.

    
risposta data 22.09.2011 - 20:19
fonte
3

Un quarto modo consiste nell'impostare l'attributo onClick nel layout:

<Button android:onClick="clickHandlerForButtonX" />

che ha questo metodo corrispondente nell'attività:

public void clickHandlerForButtonX(View v) {
    //Handle Button X here
}
    
risposta data 22.09.2011 - 22:23
fonte

Leggi altre domande sui tag