Perché i pulsanti hanno listener di azioni e comandi non in LWUIT?

Question

C'è qualche motivo per cui in LWUIT un pulsante può avere il proprio ActionListener (tramite button.addActionListener) mentre un comando non lo fa?

È l'unico modo per avere un listener per un comando specifico è aggiungere un ActionListener a un modulo e controllare l'ascoltatore per il quale comando è venuto l'evento come di seguito?

public void startApp() { 
    Display.init(this); 
    f = new Form("Mixed Record"); 
    exit = new Command("Exit"); 
    start = new Command("Start"); 
    Button button = new Button("Button"); 

    f.addCommand(exit); 
    f.addCommand(start); 
    f.addCommand(delete); 
    f.addComponent(button); 

    f.addCommandListener(new ActionListener() { 

     public void actionPerformed(ActionEvent ae) { 
      if (ae.getCommand().equals(exit)) { 
       //Do Exit command code 
      } else if (ae.getCommand().equals(start)) { 
       //Do Start command code 
      } 
     } 
    }); 

    button.addActionListener(new ActionListener() { 

     public void actionPerformed(ActionEvent ae) { 
      //Do button code 
     } 
    }); 

    f.show(); 
} 

Answer 1

Beh, non posso dirvi esattamente il motivo per cui le persone che hanno scritto LWUIT fatto che la decisione, ma ci sono diversi motivi per cui ha senso.

Quando un modulo contiene diversi comandi, questi vengono raggruppati in un menu. Ogni volta che l'utente si espande, quindi comprime il menu, viene eseguito un massimo di un comando. In quanto tali, i comandi sono concettualmente più legati tra loro rispetto ai pulsanti, soprattutto perché non è raro riusare le sottoclassi di Button da una forma all'altra.

Potrebbe anche esserci stata una preoccupazione nel rendere l'API del modulo LWUIT simile al modulo LCDUI nella specifica MIDP.

Mi piace anche che il codice mostra una conseguenza positiva della decisione:

Hai già 2 classi interne anonime (le sottoclassi ActionListener) nel codice. Se ogni comando avesse il proprio ActionListener, probabilmente avresti scritto 3 classi interne senza nome. Gli sviluppatori tendono a farlo molto anche se, quando hai passato un po 'più di tempo a esaminare le tracce di codice dello stack che contengono più classi interne senza nome, ti renderai conto che è una cattiva pratica avere più di una in ogni classe chiamata.