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

La mia attività Android contiene più pulsanti che richiedono tutti un OnClickListener. Ho visto molti modi diversi per farlo come:

• Implementazione dell'interfaccia in 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 ogni approccio. Tuttavia, non mi è chiaro il motivo per cui un approccio dovrebbe essere utilizzato anziché un altro. Le differenze tra questi approcci sono stilistiche o ci sono ragioni che rendono migliore un approccio?

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

La classe di attività implementa l'interfaccia :
questa è una buona opzione quando hai un solo 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 che il mio listener di eventi non controlli l'origine dell'evento per decidere cosa deve essere effettivamente fatto. So che alcuni potrebbero dire che è una cosa di stile, ma credo che non richiedendo all'ascoltatore di fare questo controllo renda il codice più facile da seguire poiché saprai esattamente cosa viene chiamato per ogni evento.

Un'interfaccia di classe diversa implementa :
Come ho detto sopra, preferisco questa opzione per quando ho più elementi che possono attivare lo stesso evento. Estendendo l'esempio sopra, aggiungiamo un pulsante chiaro che richiede anche un listener di clic. Crea un ascoltatore che preformi le azioni di salvataggio e uno che preformi 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 propria classe di attività. Poiché il metodo di interfaccia deve essere pubblico, chiunque abbia un riferimento alla classe può attivare l'evento. Se si desidera un controllo accurato su chi può fare cosa nell'applicazione, una classe separata impedisce a chiunque abbia un riferimento all'attività di attivare o cancellare il modulo (o potenzialmente di rompere il codice se l'ascoltatore utilizza l'origine, ma lo fa non gestire input errati).

Un'anonima classe interna implementa l'interfaccia :
Questo è davvero 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 per 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 una serie di attività è la convalida dell'input (cosa che si dovrebbe fare), la scrittura in un database per memorizzare i valori e l'attivazione di alcune azioni post-salvataggio. 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 anziché un file più grande con più classi interne nidificate all'interno.

Un quarto modo è 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
}