Autore Topic: Gestione dell'OnClickListener  (Letto 1223 volte)

Offline blackgin

  • Moderatore globale
  • Utente storico
  • *****
  • Post: 1387
  • Respect: +164
    • Google+
    • blackgins
    • blackginsoft
    • Mostra profilo
  • Dispositivo Android:
    Galaxy Nexus
  • Sistema operativo:
    Mac OSX 10.8
Gestione dell'OnClickListener
« il: 12 Ottobre 2010, 20:51:31 CEST »
0
Vorrei capire se come sto facendo é giusto. Al momento l'app é strutturata cosí:

Codice (Java): [Seleziona]
public class MatchAdd extends Activity implements OnClickListener //implemento il listener
final Button saveMatch = (Button) findViewById(R.id.saveMatch); //inizializzo la view nell'oncreate
saveMatch.setOnClickListener(MatchAdd.this); //setto il listener nell'oncreate
e poi implemento gestisco i click cosí:
Codice (Java): [Seleziona]
    @Override
    public void onClick(View v) {
        switch(v.getId()){
            case R.id.saveMatch: saveMatch(); break;
        }
    }

Si puó rendere più essenziale? Ho l'impressione che sia ridondante
Postate il LogCat LogCat LogCat LogCat LogCat

Offline Ricky`

  • Amministratore
  • Utente storico
  • *****
  • Post: 3489
  • Respect: +506
    • Github
    • Google+
    • rciovati
    • Mostra profilo
Re:Gestione dell'OnClickListener
« Risposta #1 il: 12 Ottobre 2010, 21:02:40 CEST »
0
Mi sembra già ridotto al minimo.
Altre modifiche ne diminuirebbero solo la leggibilità.

Offline MarcoDuff

  • Moderatore globale
  • Utente storico
  • *****
  • Post: 1073
  • Respect: +202
    • Google+
    • marcoduff
    • Mostra profilo
    • MarcoDuff's Blog
  • Dispositivo Android:
    Samsung Galaxy Nexus
  • Play Store ID:
    MarcoDuff
  • Sistema operativo:
    Windows 7
Re:Gestione dell'OnClickListener
« Risposta #2 il: 13 Ottobre 2010, 09:43:09 CEST »
0
Il problema è un'altro: quale è il tuo scopo e cosa intendi con essenziale?

Performance? Allora conviene usare i tipi anonimi
Leggibile? Allora va bene quello che hai scritto
Modulare? Allora conviene creare una classe Listener a parte

 :-P

Offline Ricky`

  • Amministratore
  • Utente storico
  • *****
  • Post: 3489
  • Respect: +506
    • Github
    • Google+
    • rciovati
    • Mostra profilo
Re:Gestione dell'OnClickListener
« Risposta #3 il: 13 Ottobre 2010, 10:46:00 CEST »
0
Il problema è un'altro: quale è il tuo scopo e cosa intendi con essenziale?

Performance? Allora conviene usare i tipi anonimi
Leggibile? Allora va bene quello che hai scritto
Modulare? Allora conviene creare una classe Listener a parte

 :-P

Sinceramente credo che abbia poco senso creare una classe a parte. Primo perchè devi gestire il passaggio di eventuali View che devi andare a modificare e secondo perchè generalmente i listener sono talmente specializzati che in generale non sono riusabili.
Come mai dici che usare l'approccio con tipi anonimi è più performante?

Offline MarcoDuff

  • Moderatore globale
  • Utente storico
  • *****
  • Post: 1073
  • Respect: +202
    • Google+
    • marcoduff
    • Mostra profilo
    • MarcoDuff's Blog
  • Dispositivo Android:
    Samsung Galaxy Nexus
  • Play Store ID:
    MarcoDuff
  • Sistema operativo:
    Windows 7
Re:Gestione dell'OnClickListener
« Risposta #4 il: 13 Ottobre 2010, 11:10:08 CEST »
0
La creazione della classe a parte lo impone il pattern MVC. L'activity tecnicamente appartiene al gruppo View mentre il listener al gruppo Controller. Hai ragione nel dire che sono specializzati, infatti la casse a parte va inserita come inner class della classe View. Un poco come suggerisce il pattern MVC per le Swing di java con le classi Listener dentro le classi JPanel.

L'approccio con i tipi anonimi è più performante perché non hai la necessità di tenere in memoria un riferimento diretto alla classe. Ovviamente vale fino ad un certo punto: nel caso di molte classe anonime simili conviene creare una classe fisica che gestisce tutto. Al solito, la verità sta sempre nel mezzo!

Offline Ricky`

  • Amministratore
  • Utente storico
  • *****
  • Post: 3489
  • Respect: +506
    • Github
    • Google+
    • rciovati
    • Mostra profilo
Re:Gestione dell'OnClickListener
« Risposta #5 il: 13 Ottobre 2010, 11:24:05 CEST »
0
La creazione della classe a parte lo impone il pattern MVC. L'activity tecnicamente appartiene al gruppo View mentre il listener al gruppo Controller. Hai ragione nel dire che sono specializzati, infatti la casse a parte va inserita come inner class della classe View. Un poco come suggerisce il pattern MVC per le Swing di java con le classi Listener dentro le classi JPanel.

L'approccio con i tipi anonimi è più performante perché non hai la necessità di tenere in memoria un riferimento diretto alla classe. Ovviamente vale fino ad un certo punto: nel caso di molte classe anonime simili conviene creare una classe fisica che gestisce tutto. Al solito, la verità sta sempre nel mezzo!

Quindi siamo concordi nel dire che creare inner class non porta particolari benefici (ovviamente nel caso il listener non sia riutilizzabile) rispetto a creare dei tipi anonimi. Se non in leggibilità nel caso quest'ultimi siano lunghetti :P

Offline MarcoDuff

  • Moderatore globale
  • Utente storico
  • *****
  • Post: 1073
  • Respect: +202
    • Google+
    • marcoduff
    • Mostra profilo
    • MarcoDuff's Blog
  • Dispositivo Android:
    Samsung Galaxy Nexus
  • Play Store ID:
    MarcoDuff
  • Sistema operativo:
    Windows 7
Re:Gestione dell'OnClickListener
« Risposta #6 il: 13 Ottobre 2010, 11:36:52 CEST »
0
Si, confermo.

Aggiungo solo una cosa: cercare la performance in un programma è da pazzi e andrebbe evitato, anche nel caso di applicazioni mobile!  :-o

Mi spiego meglio.
La prima stesura di un programma deve concentrarsi su creare una buona architettura. Rendere il programma modulare e scalabile è il primo obiettivo da ricercare. Solo dopo aver completato il programma e solo dopo averlo testato bisogna fare dei test prestazionali ottimizzando i vari moduli.

Il motivo è semplice: molto spesso ottimizzare significa rendere un programma meno leggibile. Un programma poco leggibile è più difficile da mantenere. Se ci si rende conto che un algoritmo (o peggio un intero processo) è errato (non sotto il punto di vista prestazionale ma logico) bisogna sostituirlo. Una cosa è sostituire un algoritmo (o modulo o processo) in un ambiente strutturato bene, un'altra è farlo in un ambiente caotico e poco leggibile.

Ovvio, questo non significa essere autorizzati a scrivere codice mentre si è ubriachi!

Morale: meglio avere un software più lento ma dove per applicare una patch si perdono 5 minuti che non avere una scheggia dove per applicare una patch si perdono mesi. Il primo resta in vita, il secondo muore.

Offline Ricky`

  • Amministratore
  • Utente storico
  • *****
  • Post: 3489
  • Respect: +506
    • Github
    • Google+
    • rciovati
    • Mostra profilo
Re:Gestione dell'OnClickListener
« Risposta #7 il: 13 Ottobre 2010, 12:02:03 CEST »
0
La prima stesura di un programma deve concentrarsi su creare una buona architettura. Rendere il programma modulare e scalabile è il primo obiettivo da ricercare. Solo dopo aver completato il programma e solo dopo averlo testato bisogna fare dei test prestazionali ottimizzando i vari moduli.

La modularizzazione esce automaticamente da una buona progettazione dell'applicazione che si vuole sviluppare. E' ovvio che modularizzare "a spanne" porta più danni che benefici.

Morale: Progettare bene quello che si vuola fare, con un particolare focus all'estendibilità del tutto.

PS: Ovviamente la modularizzazione e l'astrazione deve essere fatta in modo ponderato e ragionato, senza eccessi.